The threat model used for this assessment pretty much never happens in reality. If you're arbitrarily reading memory using software, then you can also install a keylogger or steal clipboard contents, which the authors themselves concede no password managers can protect against. So what's really being evaluated is how well password managers can withstand physical attacks (DMA/coldboot), which isn't a concern for 99.999% of people. Furthermore, if your attackers had physical access, they could very well install a physical keylogger to steal your passwords, bypassing your password manager's countermeasures entirely.
Except for the case where they entire password DB can be decrypted and read (in the case of 1Password 7, at least). Sure, a keylogger could eventually get all of the passwords I use on the regular, but it couldn't get literally every password I have and in a nice, neat format along with where the passwords are used.
Reading the current password from memory = keylogger, I'm not worried about that. Reading every password I have or have ever had, including (I assume) encrypted notes and such? = keylogger on steroids.
>Sure, a keylogger could eventually get all of the passwords I use on the regular, but it couldn't get literally every password I have and in a nice, neat format along with where the passwords are used.
But passwords aren't just about you, they're about the server they're also stored on too. Without a password manager, how do you propose remembering unique fully random passwords for dozens to hundreds of services over the course of decades? And they must still be easy enough to enter that most people will actually use it. And also be trivial to change at will, for when (not if) the password database is compromised. And in fact you directly bring up the problem of that being worse for services you use extremely infrequently. So if you use it frequently the keylogger gains it anyway, and if you don't use it frequently then what's your usable system again? Also, are not the most important things you want taken the least also the ones that tend to be used the most frequently? And with access to your email and in fact all communication services used on that system you don't see how an attacker wouldn't just be able to "I forgot my password" for many if not most services?
>Reading the current password from memory = keylogger, I'm not worried about that.
You're not worried about your system being rooted? I'd say you have an awfully different set of priorities when it comes to security then most of the world even beyond HN.
> how do you propose remembering unique fully random passwords for dozens to hundreds of services over the course of decades?
not fully random, but:
make up an algorithm that uses pieces of data that you know you can derive from some superficialities of anything you need a password for plus some some obfuscation function and some other data that you can derive or remember that is not related to the thing you need a password for.
e.g: the name of the site and the month you signed up in leet speek, rot-5'd and alternating letters, interspersed with symbols at some period related to a rhythm you like.
doing this gives you relatively strong passwords that you can reliably recreate while not needing to memorize them, that do not have an obvious pattern to them even if looking at them in mass, that have a very low chance of collision. you can remember a fairly complex recipe pretty easily ;)
depending on where your passwords are and what they're for, this might be preferable than storing them in one app that can compromise every password you have.
either way, someone only needs your important pw once. use multi-auth.
What you're basically describing is no-sync password managers[1], with all of its disadvantages (password changes/rotation, username storage, etc) but also with security by obscurity instead of a proven KDF.
[1] I'm not sure what they're called exactly, but basically all you do is enter a password and it generates your password using your password + site + KDF.
correct, the point of doing something like what i'm describing is to have a system for keeping / creating N unique passwords stored only in your head, in a way that provides an acceptable amount of strength, avoids disclosing all of your passwords if one is compromised, and doesn't require you to be a savant of long-random-string memorization.
there are plenty of things that this isn't an appropriate approach for, and fwiw I wouldn't tell someone it would be a good strategy for all their passwords.
it can be useful when you have a set of longer lived passwords that you need to care about guaranteeing that the entire set can't be snarfed without holding you at gunpoint.
for the example above, you could chunk-rotate, change the rot-degree you use as obfuscation or have other variants of your algorithm.
there's a point somewhere a bit faster than monthly-expiration where I would consider using a store and random gen in situations where i would otherwise not. really depends on you, what it's for, and what risks you need to care about the most.
> And in fact you directly bring up the problem of that being worse for services you use extremely infrequently. So if you use it frequently the keylogger gains it anyway, and if you don't use it frequently then what's your usable system again? Also, are not the most important things you want taken the least also the ones that tend to be used the most frequently?
I don’t login to my online banking from my computer very often, nor do I login to government / tax services frequently. I’d be pretty upset if the credentials for these things (especially in the case of some banks, the second password required to perform any kind of transfer operation) got compromised simply because my entire password database got dumped from machine memory without having been used.
A notebook and pencil in your desk drawer solves this problem reasonably well if you're patient. In some ways that is more secure than having all the passwords stored where an attacker can grab them from the comfort of their living room.
You wait 'til you get home? Personally, I use 1Password, but I have a friend who swears by the notebook approach. He also caries a feature phone and uses a desktop computer, which makes it a lot more practical.
What are you doing to do if your home burns down? If it's an emergency and you can't wait until you get home? If industrial espionage efforts involve stealing a notebook from your home?
There's no such thing as a multiple SPOF; that's called a multiple point of failure, which is a good thing.
Security is a battle of convenience. If your threat model is state actors, then it may well be worth the inconvenience to have your data secured in several different locations, running Tails OS on everything, scrapping your smartphone, and so on.
> that's called a multiple point of failure, which is a good thing.
Totally leaving aside the argument you were in - multiple single points of failure are bad, and very different than the opposite of a single point of failure.
Having a SPOF means one thing will take you down. Having multiple SPOF means any one of those can take you down. Lack of any SPOF means no one thing will take you down, it will require multiple problems. 3 distinct options.
Only with additional work, if the attacker also extracts your password file. That's something I'd like some resistance against anyway, so malware can't simply do that and potentially decrypt it a few years down the line.
This of cause doesn't help against a resourceful and highly targeted attack, but that's less of a concern for me than some malware toolbox adding support for common password managers.
Also, on Windows, KeePass at least offers the option to always ask for the master password only in the same secure desktop that UAC and login/logout use. (I don't know why this isn't the default behavior, other than maybe cross-platform compat, but it is not the default. First thing I turn on for fresh installs.) That at least helps mitigate against most software keyloggers / remote automation hack attempts. (Leading the threat concerns back to rootkits and physical hardware access.)
Is that different? "Eventually get all of your passwords" sounds just as bad to me, especially since only some passwords are worth anything and my email password can be used to reset all other passwords.
The malware just waits until you use one of these passwords? The threat model of "I have these crazy essential passwords that I literally never use" is worthless. It costs the malware author nothing to wait.
Even if an adversary has access to a machine, there is a difference if they can choose when/where to exploit/steal something, or if they have to wait for an action. If the adversary cant get persistence, a simple reboot of the machine might get them evicted and the keylogger is gone. That's just a simple example but it shows that things are more nuanced.
Apple for instance has efforts so that even root can't just debug arbitrary processes or unlock keychains of other users without them agreeing to it or disabling SIP.
It's about raising the bar and removing degrees of freedom for an adversary, so it becomes more dfficult. In the end of course systems can always be exploitable (given enough resources are allocated in breaking in).
Consider this. I am in a coffee shop. Someone walks by and grabs my machine. This is a huge annoyance, need to replace and setup a new machine vs. (with my password manager getting hacked) my life is basically over because as far as anyone is concerned the thief is more me than I am. Depending on who took it, I might as well move to the forest and live in a mud hut because I am never going to be able to clean this up.
This actually happened to someone at my company. But their passwords weren't compromised. If they were, I can't even imagine, the guys who took the machine were really trying to do whatever they could to ruin him and the company.
The problem is 200 passwords being compromised, including my emails which are used to reset everything else. I can't fix it faster than the thief can wreck my digital life, and everything is digital now. I couldn't even start until I somehow convince my email provider who I am and to change the password for me.
If this ever happens, best plan would probably be to change your email password immediately, banks next, and freeze your credit as soon as possible.
Or the password recovery for lost 2fa is secret questions (this is so awful,but see it often). And chances are those secret questions/answers might also be in the vault
Exactly. Attacker is already in God Mode. Doesn't need to be probing password managers. The report has some value in testing a claim about how well secrets were hidden in or scrubbed from memory. Not like advertised...
Ill also add that mitigating stuff like this was an early, easy use of separation kernels. They put the secret-protecting components, like disk encryption and VPN, in dedicated partitions outside Linux VMs. That worked well.
yup. if the report is meant to be other than marketing, they would have done well to have an outside review before publishing. i don't see any acknowledgements section so i assume that didn't happen.
this is basically soft marketing of the skills they bring to the table. realistic/practical threat modeling not being one of them.
Yeah, just as a thought exerise I took a look at my DB.
The high value things (bank, email, web hosting accounts) all have 2FA enabled.
The lower value ones, I can easily recover from a breach by simply resetting the PW via my email.
The only real threat I see is if you're storing passwords to things like encrypted containers (Veracrypt, TrueCrypt etc) but as you pointed out if they'd had something running on your system you're hosed either way.
Don’t you also store the 2FA recovery codes in the PW manager though? I haven’t found any other good method for this other than printing them out but that comes with its own issues obviously.
Do you think having a separate database (with the key stored in a safe place) might be a happy medium between "keep them in a safe" and "keep them in the same locked container as the passowords"?
Or do you think that having both DBs on the same (possibly compromised) machine is too much risk?
Seems like a good approach, if you use asymmetric encryption. Keep the private key in a safe place, and the public on the machine; then you can store new codes (by encrypting them with the public key) without having to access the safe place.
> Seems like a good approach, if you use asymmetric encryption. Keep the private key in a safe place, and the public on the machine; then you can store new codes (by encrypting them with the public key) without having to access the safe place.
Interesting idea. I had just been picturing a second keepass db with a different passphrase (or use a usb key with a keyfile kept offsite) but I like yours too.
(I'm also trying to brainstorm solutions scalable to non-experts so "&Ok fire up the CLI, we're doing GPG*" might work for me, but not everyone in my org :) )
This is why I refuse to upgrade from 1Password 4. Or switch to another product.
I haven't found anything that I can self-host and allows me to have multiple "vaults". And I refuse to keep all my 2FA codes and recovery codes in the same place as the passwords, since that completely defeats the point.
When I asked 1Password about it, their response was that the functionality wouldn't be coming back in 7 because it wasn't a supported configuration -- it's called 1Password so users should only ever be remembering one password!
If Keepass's entire UX wasn't hot garbage it would be perfect. But here we are.
I use this as well as 1Password. I'd describe the UX generally as being 'hot garbage' compared to 1Password. The difference in polish is night and day.
That said, based on this report, the security model is significantly better, so the decision becomes do I care more about usability/being pretty, or security.
The never-ending trade-of between security and usability continues...
> When I asked 1Password about it, their response was that the functionality wouldn't be coming back in 7 because it wasn't a supported configuration -- it's called 1Password so users should only ever be remembering one password!
What functionality has gone from 7 and isn't coming back? Multiple vaults with distinct master passwords and not requiring their cloud backing?
You can set up multiple vaults, but it seems to store the master password for the additional vaults within the first, after the first time you unlock the additional vaults. So, effectively, it's a single vault -- access to the one gets you access to all.
you might want to check out Enpass. Multiple vaults and mobile clients are a premium feature, but the desktop app is free and fully local with self-hosted sync options. I'm not affiliated, but have been a happy user for a couple of years.
I love 2FA for high value services, but I worry about adversaries getting access via social engineering ("I lost my key fob, and I'm on vacation please help!")
What if someone steals your laptop and decides to see if they can get any sensitive info off of it before they wipe it and sell it?
Probably not a common scenario right now, but if this threat goes unfixed for a long time and tools become available to automate the attack I could see it becoming a problem.
>What if someone steals your laptop and decides to see if they can get any sensitive info off of it before they wipe it and sell it?
That's what full disk encryption and (eventually) hardware security chips and the like are for. It's not a threat model that has anything to do with password managers.
>Probably not a common scenario right now
It never can be, that's the point. Physical attacks simply do not scale like purely online attacks do, let alone attacks on centralized single points (ie., a central password database).
>but if this threat goes unfixed for a long time and tools become available to automate the attack I could see it becoming a problem.
What? What tools "automate" stealing your notebook?? And also breaking through whatever physical security it has, like TPM or Apple's T-series chips or even just plain soldered on storage/memory/everything? The latter make repairs more of a PITA but they also make physical attacks significantly more difficult, even stuff like cooling memory and swapping (and encrypted memory based around tamper resistant security chips is a potential thing too).
> That's what full disk encryption and (eventually) hardware security chips and the like are for.
That only helps if you assume the laptop is fully powered off when it is stolen. If it's on or merely in "sleep" mode, disk encryption doesn't help.
> It never can be
What can never be? Laptops being stolen? A threat doesn't necessarily need to scale to be a problem as long as the gain from individual compromises is sufficient to make it worthwhile.
> What tools "automate" stealing your notebook?
The stealing doesn't need to be automated, just the attack on the password manager itself. A program anyone can download and run on a stolen laptop to extract the password database would be sufficient.
>That only helps if you assume the laptop is fully powered off when it is stolen. If it's on or merely in "sleep" mode, disk encryption doesn't help.
First, I said FDE and hardware security chips like Apple's T2 and mentioned stuff being soldered on and HSM backed encrypted memory. Yes, simple FDE and standard PCs can be subject to physical memory swaps and the like, but that becomes vastly more complicated and difficult with devices that use significant hardware security. This is no different then a modern iPhone, where merely having physical possession, even with the phone not powered off, doesn't mean it's trivial to access the data.
Second, you're engaging in the security fallacy of inventing theoretical attacks without considering economic cost or whether they pass the weakest point test in the threat model. The sort of scenario you've come up with is not that simple and not the sort of thing some random crook is likely to do, which is how this thread was started. But if you're dealing with a targeted physical attack by an actor with significant expertise and resources, there are far more trivial weaker points to go for. For example, they could just stick a pinhole camera looking down at your desk (or anywhere else you frequent with your notebook) and just record your password and avoid the whole mess. None of this has anything to do with password managers.
>What can never be?
Try reading the conversation? I responded to "Probably not a common scenario right now", which implies that it could someday become a common scenario. Ie., an attack that could be scalable. But physical end point attacks are inherently not scalable, just like anything else that requires actual boots on the ground. Resource cost is the framework of all security.
>The stealing doesn't need to be automated, just the attack on the password manager itself. A program anyone can download and run on a stolen laptop to extract the password database would be sufficient.
If the stealing isn't automated then it's not scalable and it's an entirely different scenario. And this makes zero sense anyway. You can't just download and run anything on a stolen quality notebook without breaking it's physical security first, which is increasingly non-trivial. The password manager database has absolutely nothing to do with any of this.
You're speaking as if HSM encrypted memory and strong hardware security are standard on all laptops these days. They aren't. Lockscreens can often be bypassed, especially if you have physical access. [1][2]
All it takes is for the _exploit_ to be automated (not the actual act of stealing laptops) such that any random person off the street can do it. Then a targeted attack is no longer necessary; crimes of opportunity become the larger threat.
I think for any FDE, including FileVault, the disk encryption helps but there are many more potential avenues for attack if the system was not off when stolen. Those avenues include remote exploits on anything listening for incoming network traffic on the Mac and DMA attacks through Thunderbolt. I don't know what the current status is of exploits through physical ports on a Mac but they have existed in the past.
It's not just Mac users, I mentioned this issue in a meeting with an Apple sales engineer last month and he acted like you don't need to turn off a Mac to make it safer (he's not a security engineer so I don't really expect him to know how un/safe a running system with FileVault is). It may well be that the current OS and/or T2 chip makes it very, very hard to access the boot volume of a running Mac without a user's login but there's still a network exploit risk.
Plug in an Ethernet adapter or wake the computer around unencrypted WiFi (or encrypted WiFi but with a broadly shared password) with the same name as one the computer has used. In addition to direct attacks on anything listening for incoming network connections, I believe applications will keep running and using the network while the screen saver lock is enabled; it may be possible to inject an exploit in a server response to a request from a browser, an email client, etc. though the broad use of encryption at the application transport level makes that much less likely.
> What? What tools "automate" stealing your notebook??
Not the parent but I assume they meant a tool that traditional laptop thieves with little technical sophistication can use to easily extract valuable data from a machine after they have stolen it.
Is that a threat vector that is actually being used? Apple for sure has to worry about, but I don't think petty criminals would have the know-how to fence data even if they get it.
Even for many 2FA devices however, root access on the accessing machine can allow for hot online attacks. Not all tokens include some kind of system independent operator intention mechanism, ie., you must touch the token or input a PIN or biometrics on the token itself for each action. Many instead have the PIN inputted via the connected system. The token does protect the private keys themselves of course, so a remote attacker can't take them and then utilize them independently later, nor prevent the operator from removing the token or whatever. But with root, and while the token is in the system, attackers who had already taken the secondary auth (trivial with that level of system access) would be able to silently use it for anything the operator could. And even for tokens that do require an independent physical operator presence and decision indicator, root would still open up a lot of paths for social engineering (ex, wait for them to want to perform a real 2FA action, intercept it insert the attacker's own, then show an "error try again", then allow it to proceed so it looks like a brief blip which many users will ignore).
Basically even pretty good 2FA systems aren't at all full defenses if an attacker has root. They can help in very important ways to minimize the potential damage, to make recovery easier (since private keys are never compromised), to aid discovery/auditing, etc. But it's hard to avoid there having to be some trust in the client at the end of the day. And it's often a lot better to decentralize trust into client devices rather then something that can be centrally compromised. It's much harder for attackers.
Password Managers are no different, their raison d'etre is essentially trying to move the trust foundation more to clients. Client trust is a req though and any "compromise" that depends on controlling the client is uninteresting. They're basically a hack recreating PKI badly, but in a world where the technical foundations for a proper one didn't develop it's a good bandaid.
Basically using an entirely separate device to authorize your access. 2FA devices still connect to the computer requesting access, I liked the idea that your phone act as the gatekeeper without ever touching your computer.
Problem is: It's a phone. Apple has done much but I wouldn't trust it either.
I would argue that while memory read vulnerabilities are not normally commonly known, that does not begin to mean they don't exist. Look at any number of stories where vulns have escaped detection (or reporting) for 10, 20, even 30 years!
> "First and foremost, password managers are a good thing. All password managers we have examined add value to the security posture of secrets management"
This is the point for 99.9% of people. If you're at risk of having someone attack you and your digital life in a targeted way, perhaps consider evaluating the security implications of each password manager.
Otherwise, pick any damn password manager and focus on something else.
>Otherwise, pick any damn password manager and focus on something else.
Absolutely! For me, choices narrowed down to needing something cloud portable, 2FA, not needed another service like Dropbox just to access it, IOS integration, easy to share passwords with auto-update and revocation. But yea... just use something!
I always prefer if it's via Dropbox or some other sync provider, so that my data is safe. For example dropbox, they are into storage and their speciality is in storage, safety of data. Password manager app can be good in app making part but storage with them always scares me and I think their speciality is in app making.
What do you think about it, just want to understand your perspective nothing else.
Plus, there are so many options in "dumb but varying spectrum of secure file sync" (Dropbox, OneDrive, GDrive, Resilio Sync, scp, rsync, xcopy, robocopy, USB sticks, floppy disks, etc and so on) that it is easier to adapt your storage model as your threat model changes. Though you should never entirely rely on security through obscurity, depending on your threat model, there may be no way for an untargeted attacker to even know which storage service you are using given so many possible choices.
Interesting, so their augment is essentially that the memory-safety provided by the use of a memory-managed language is more valuable to them from a security standpoint than the memory scrubbing capabilities afforded by a lower-level language?
I think that's a fair characterization of their response, yeah.
As someone in that thread pointed out, I would say that the onus should be on the OS SDK to provide memory management primitives specifically for the purpose of security that can be zeroed out after use.
They also point out that the threat profile is someone who can read your system memory when 1P is locked (serious compromise already), but is unable to read it when it's unlocked (otherwise why bother reading it when locked), which is a pretty small set of use cases.
> They also point out that the threat profile is someone who can read your system memory when 1P is locked (serious compromise already), but is unable to read it when it's unlocked
I can think of at least one situation where that would be the threat profile: someone steals your laptop.
Not a super common scenario, but not exactly unheard of either.
1- User uses the laptop and logs into 1P successfully then locks it.
2- Hacker steals the laptop and uses it without a reboot.
3- Hacker hacks the windows/mac os password to logon.
4- Hacker dumps process memory for 1P.
For me, they would have to steal it while I'm actively using it. When I go away from my desk, I enable the screensaver which A) requires my Mac login password to unlock and B) locks 1Password, requiring the master password to unlock.
In 1Password 6, the Prefrences > Security settings include Auto-lock: on sleep, when screen saver is activated, when main window is closed, when fast user switching, when computer is idle for X minutes. I use all but "when main window is closed." It's much less of a nuisance since I started using Touch ID to unlock 1Password.
I haven't looked into them in a while but there is 3rd party software than can automatically enable a system's screen saver when a particular Bluetooth device is out of range (e.g. a smartphone, a smartwatch, etc.) which would help even more.
The problem is that with this attack it doesn't matter if 1Password is locked or not, the attacker can just extract your master password from memory. The computer itself being locked is a bigger obstacle.
Reposting my comment from the previous submission:
From a Washington Post article on this study: "LastPass had me speak with its top technical executive -- but it also got [lead researcher] Bednarek banned on Bugcrowd, the site for researchers to report flaws, because he disclosed the bug to me."
Very interesting results. I'm not sure I agree that it's necessary to keep password information out of memory in an unlocked password database, since an attacker could always just extract the decryption keys from memory and use those to decrypt the database on disk to get the same information.
The other findings about sensitive information remaining in memory even _after_ the password managers are locked are concerning however. It'd be great if the article included a link to the CVEs or bug tracker issues for these vulnerabilities so we could keep track of whether or not they've been fixed.
I don't care if the password manager is secure against local attacks, because the average user will still be vulnerable without extensive security policies. Sure, there's the "anything is better than nothing" argument, but if we're just throwing darts at the wall, deciding which dart board is nicer isn't going to affect your score.
If you can read local memory, you can probably write to (at least other) memory, and then it's a short hop to content injection and session hijacking. Erasing key material from memory or preventing its misuse then only seems useful against cold boot attacks.
It stays encrypted at rest on your machine protected by GPG keys and when you want to access a password you can choose to copy it to your clipboard for 45 seconds or print it to stdout.
No subscription services, and everything stays local on your machine, but you can easily sync it to other devices using whatever file syncing service you want since it's just encrypted files on disk.
This was brought up last time - but even having something like the path "./Banking/bankofamerica.com" visible on the filesystem is a disclosure of sensitive information, even if the password is encrypted at-rest. Otherwise I love the idea of *nix based philosophy for password management =)
The path does leak some information but in that case the bad actor would also need to know the username along with the password (both of which would be encrypted).
But you have to ask yourself. Who are you protecting against here? Are people browsing around your laptop / workstation without you monitoring what they're doing?
If someone has your machine without your consent, then you're pretty much screwed because 99.99999% of people will leave themselves logged into things like gmail which requires no password to access it once the machine is powered on. It's basically this xkcd scenario: https://xkcd.com/1200/
> Are people browsing around your laptop / workstation without you monitoring what they're doing?
Nope - but the industry that I work in constantly assumes "bad actors" are present. Although it's not perfect - everything is 2FA, all disks on laptops encrypted, there are strict rules in dealing with secrets/sensitive information, etc. My main concern is if someone were able to do a rip of my home directory.
Trust me - there's a TON of room for improvement, but doing some general protection against someone with "shell" access is something I'm in the practice of... it's the same reason I carefully manage what ends up in my .zsh_history or .bash_history =)
> If someone has your machine without your consent, then you're pretty much screwed
Agreed. Encrypt the disk (I trust LUKS), lock your machine when not in-use, ensure it shuts itself down if a password is "fat-fingered" more than twice, use solid passwords with good complexity, use 2FA when you can/should, etc.
YubiKey is at least supported, but only because it also functions as a pgp smartcard. You can load you pgp private keys on the yubikey and then all decryption will only be done on the Yubikey itself.
Yeah, I just tried googling again. I think last time I indexed too heavily on if pass supported this, now I see I just need to setup openpgp. That sounds promising. Thanks!
I wonder if password managers should consider running under a higher privileged account (eg administrator). This would prevent lower privileged processes (eg your typical drive-by malware) from being able to get a handle to read memory without also using a privilege escalation technique.
That's exactly how I have KeePass configured on Windows 10. I've set my keyfile (additional entropy for the encrypted password DB, combined with master password) access to only allow the Admin account. Then, I set keepass.exe to always run as Admin, which of course prompts the UAC whenever it is launched.
This actually accomplishes a few things:
* The keyfile is safe from processes launched using the standard user account (i.e. non-elevated). Malware accidentally launched by 'me' can't read it.
* Keepass.exe is running in the admin process space, which protects its memory from processes running in non-elevated space.
* Launching admin-space Keepass, and seeing the UAC prompt, Microsoft includes information about how the exe is signed -- which Keepass is -- that allows me to verify every time that I'm not launching a bogus keepass.exe.
* The password database file is still in user-land, so it can be synced with standard cloud sync tools. It is worthless without the keyfile though, even if my master pass ever slipped.
It's not foolproof because the malware could also hook your browser and sniff your passwords from there. It's better than nothing though (instead of getting all your passwords they only get whatever you've entered).
I just moved from LastPass to 1Password7, and this sentence will make me consider moving back:
> Surprisingly, we found that it is less secure in the running state compared to 1Password4. 1Password7 decrypted all individual passwords in our test database as soon as it is unlocked and caches them in memory, unlike 1Password4 which kept only one entry at a time in memory. Compounding this, we found that 1Password7 scrubs neither the individual passwords, the master password, nor the secret key (an extra field introduced in 1Password6 that combines with the master password to derive the encryption key) from memory when transitioning from unlocked to locked.
That is unacceptable, what type of developers do they have?
They also address that in their response. It stems from the fact that they use memory-managed programming environments, so they don't have that level of control over memory.
That's a pretty extraordinary claim, considering that securing native code is highly nontrivial and increases the attack surface of an application significantly.
The 1password devs specifically say that the Windows team has been playing around with Rust. So they at least seem to be looking into it and treating it as a real possibility.
I don't imagine anything will come from it for a while however.
If you're going to hold that against them, LastPass is just as bad:
> During a workflow to derive the decryption key, the master password is leaked into a string buffer in memory and never scrubbed, even when LastPass is placed into a locked state.
Not that storing a masterpass as sting is acceptable - nor that I readily believe that statement entirely. But why would you be using any of these without 2FA?
If it’s an interesting annecodte to you, I moved myself an 5 people in my company from 1Pass v4 to LastPass, no complaints from anyone and the iPhone integration is unbeatable.
Altogether I’ve moved 100 people to LastPass and some of those users have been not-exactly-power-users, yet, zero complaints from 100 people. A year later almost every single one is still using and the downstream effect of children/friends/kids is surely in the hundreds. They owe me a shirt or something really!
LastPass isn’t perfect but it’s pretty great for the price. What made you switch to 1P v7?
Are the people using LastPass commenting on how nice the interface is, or are they just not saying anything at all?
I have to use both LastPass (enterprise) and 1Password 7 (personal). The experience is pretty incomparable: the LastPass user interface and browser extension are abysmal, whereas 1Password is very enjoyable. On the most recent version of Chrome, the LastPass extension is slower, less intuitive and less organized than the 1Password extension. 1Password also has more features and a fast desktop application for macOS.
Note that I'm not saying LastPass doesn't work. It works...but it's an incredible pain for me to use every day at work after using 1Password at home. I think the design sucks, to put it bluntly.
I've had a few questions about interface, but for the most part it's intuitive and I've had very few questions even from older people. Not hearing anything is a good sign.
I've had none of the UI issues you have (Firefox, Safari) and have heard none from any user. Weird!
Did they do an overhaul recently? Maybe people are remembering an older version.
I had to use LastPass at work, maybe 2 years ago, and I can confirm, it may have had the worst user interface (both in terms of aesthetics and usability) of any webpage I've ever had to use. I simply couldn't believe any self-respecting developer shipped that.
I've been using lastpass for 8+ years and had a previous employer move their password management to lastpass as well (they are still using it from what I hear). I've been nothing but supportive of them from the get go.
But I have to say I'm starting to get a little disappointed.
While security/functionality are the number one priority, I feel like once you get those figured out you can at least try to work on the UI a little bit. I don't think that aspect has changed since I started using it and if anything it's been getting worse. I now have multiple pet peeves with it:
1. Firefox now sometimes complains about the lastpass addon slowing pages down (sounds like they don't care much to maintain their FF addon)
2. I can't turn off the login field icons while lastpass is logged out so those are always present in login forms (until I login and it reads my addon settings to turn them off) - this is probably an addon bug but see above.
3. I think the default security settings when you install the plugin are too permissive, probably in an attempt to increase uptake (which is a big no-no to me)
4. Lately it's taken multiple back and forths when emailing support because they just can't be bothered to read the initial request. I end up repeating myself a number of times before they stop responding with some canned response that doesn't apply to my support request.
I'm probably done renewing. I've been using keepassx for things like banking and trying out bitwarden for the less consequential stuff.
Sorry - this turned into a rant.
As an admin, laspass is anything but great. Having to create a shared folder for every user and group is ridiculous. I will switch to 1Password teams soon most likely, although bitwarden is the new hotness these days.
oh, that's a really good idea. I should put all my apps and logins in a single folder and then share them all with everyone in the company. security shmurity!
> Using CryptProtectMemory and CryptUnprotectMemory for password encryption is not secure because the data exists as plaintext in memory before it is encrypted and at any time the caller decrypts it for use.
In order to benefit from CryptProtectMemory you have to carefully lifecycle strings in and out of secure storage as needed; this wouldn't mitigate some of the issues presented in the article.
C# has a core class to safely lifecycle protected strings. The decryption key is only resident in kernel memory, so a dump of the user process when protected theoretically cannot read the protected string contents. (Of course, this doesn't prevent against a cold boot attack unless the keys are escrowed in a TPM.)
Keepass does have coutermeasures against clipboard sniffing (auto-type instead of copying to clipboard) and keyloggers (Two-Channel Auto-Type Obfuscation).
These are effective against non-specialized attack software.
Any computer program is going to have data in RAM. It's up to something else to protect that. (This is why ARM machines have that encrypted RAM, this is why real security software runs in some sort of tamper-proof area, etc. This paper shows the general "whatever" attitude that general-purpose computers adopt towards attacks where someone has physical or root access.)
Can anyone comment on how concerning this is? It doesn’t seem good. I was considering updating from 1Password4 to 7 and biting the bullet on the subscription model. Based on this case study it seems 7 is a security regression trade for UX improvements. Now, I’m considering Keepass or at least waiting to hear some responses from providers involved.
It's not a concern. As an average user your only consideration is "Do they keep my passwords safe on the disk?", and the answer is "yes" for all of them.
If you work for the NSA and cover yourself with a tinfoil blanket to enter your passwords, just lock and close the password manager completely after you've used it to login to a service, and you're all good.
I don't think it's an "esoteric" attack, it's just that the cost-benefit of locking things down a tiny bit more isn't significant. We're always one browser exploit away from malware that can do whatever it wants.
Ok, so say the malware couldn't access all your passwords immediately. It's just going to sit on your computer and collect them (and existing sessions) as you use them, or force you to re-auth and then collect them. And if it's highly prized info, the malware will eventually get updated with a privesc to go around the user context. This is what malware has been doing for years, and nobody notices until exfiltrated passwords start getting used.
By the time I go through all my passwords at least once, browsers and OS will release multiple rounds of patches and potentially fix the exploit in question. This is still preferable to uploading whole database...
I think the cost-benefit differs. If the whole database is leaked, you just rotate everything. Only the stuff that has been used (which tipped you to it being leaked) has a real impact. Nobody's going to compromise every single account you have all at the same time, unless they're specifically targeting you, in which case they're going to get everything anyway. So on balance, it doesn't matter if some random malware gets 1 of your passwords or all of them. The real-world impact is about the same: limited. The cost of worrying about the extra security outweighs the benefit.
Another way to go would be tiers of password managers. Even if all of their unlocked integrity sucks, you can have one manager that keeps your most sensitive accounts, and another manager for the rest. You rarely unlock the sensitive one, and after you log in, you unlock it and exit it. Now you have much better opsec with very little additional cost.
Imagine a malware ad, using zero day browser exploit that is designed to dump 1password db at scale and upload it for further processing. As an attacker you can run this for a while (while exploit is valid) and then compromise thousands of bank accounts you have collected. As many as your scripts support.
Well yes, right now that is true. Without filesystem access, without long term persistence, just process memory access, a compromised browser can dump whole db from 1password7 at once. You only need seconds of time.
If only recently accessed passwords were unencrypted, only those would be available.
If there's malware that can read your memory on your machine, they could also just intercept the paste buffer. Basically, this is a rather esoteric attack that if someone was in a position to perform, they could also do much simpler ones.
Keep using a password manager. Write down your 2FA codes separate in a safe place. (I recommend everyone own a safe deposit box)
What I don’t see this paper focus on is security offered by the OS. Historically and commonly, for “normal people” apps, we’ve only been able to rely on one kind of compartmentalisation: memory is not readable between apps. However, any file the user has access to is fair game for any app. This is a Bad Time for any password manager, or really any app (think e.g. about your email cache in a thunderbird profile, or Firefox session tokens which can be siphoned , etc).
For ages, on Unix this could be solved with users and daemonisation. Later came SELinux which is criminally underused.
In the popular OS market, for a while there was flocker, on OSX. It used event hooks in the kernel to allow fine grained control over filesystem access, locking certain dirs down to certain apps. The app was bought by some enterprise offering (f-secure) and taken offline. The creator (Jonathan Zdziarski) was then hired by Apple. Recently, similar features have been rolled out by Apple natively for OSX. Try reading your iMail or calendar cache using the terminal: you’ll get an iOS-like pop up window asking you if this app has permission to your mail, or contacts. This is a step in the right direction.
All that’s left is for Apple to allow the user (or app developers) to specify such locks ourselves. This was already possible with flocker, but unfortunately that’s nowhere to be found, anymore. Perhaps it’s possible for apps delivered through the App Store? This would solve the problem that a password manager offers any process access to your full (encrypted) password DB, which is a pretty serious problem (makes the master password too valuable!).
Given the direction things are moving in, and the hire of Jonathan, I’m very hopeful this will eventually arrive. It would be a tremendous win for security on OSX. This everything-goes mentality of FS access has been a pet peeve of mine for over a decade. :) and, tbh, I think it’s a much more relevant attack vector than some process “reading memory”.
It doesn't help that many of these password managers are written in high-level languages (some are Electron based, ffs!) where you have zero control over the actual allocation (and subsequent clearing) of bits. The best you can do is overwrite the memory and hope that the framework/runtime/GC does the right thing.
For .NET, there is SecureString class [1] which provides reasonable protection against stealing secrets from memory. Not many password managers (if any) use .NET, though.
I had a client who required me to use LastPass because he didn't want me to see the the actual password. I was wondering how that was even possible, maybe some kind of magic I didn't know about. Turns out it's trivial to get the passwords using a browser's built-in inspector.
clipboard sniffing?
I remember years ago, there's some tools that you install and it will automatically encrypt all the clipboard content to prevent sniffing.
Nowadays, a password manager can't even do that?
* might not be straightforward as it install some DLL inject stuff
In the iterations it says that LastPass requires "100,100" iterations to brute force in non running state, but in the image table at the end with colors it says "5K" for LastPass.
That phrase doesn't really capture what iterations means there. How you said it makes it sound like you only have to try 100k computations to brute force a valid answer, which is certainly not true.
It's talking about key stretching / key derivation [0].
That is not 100100 iterations to brute force it, that is 100100 iterations of PBKDF2-SHA256 applied to the password you type in as the master password.
It does look like the tables are not identical. However, since lastpass's docs [1] say it's 100100 (and configurable), I'd say that's likely the accurate default value.
I just migrated from LastPass to 1Password7, happier with the GUI/interfaces but I hope they fix these issues up to at least make it harder to extract the passwords when in a locked state.
One thing that is nice about 1Password going to a subscription model is that they have to work for your business every month or every year. In the comment they made, they talked about looking into a transition to Rust, which has better memory security capabilities.
These evaluations all happened on Windows, which is notoriously bad at protecting memory from snooping by other processes.
Does anyone know how well MacOS versions of all the password managers would have fared? I suspect the JavaScript based password managers like LastPass would fare similarly, but it would be interesting to see if 1Password has better security on MacOS than Windows.
> Windows, which is notoriously bad at protecting memory from snooping by other processes
Whaaat? I'm going to call citation needed here. Afaik there is not significant difference in the memory protection model between any of the mainstream OSes
Bitwarden. It's open source, even the server side, which allows you to set up something like lastpass without depending on someone else's servers, not that you need to; you can totally use Bitwardens' default setup. I'm an open source proponent, so it's a no brainier for me to support them as a paying customer, given the quality of the product and knowing that they're releasing most of their work under an open source license.
I'd love to host my own Bitwarden, but it seems kinda odd that they've locked in on MSSql, even for self hosting. I really don't need yet another DMBS to maintain and secure.
If i ever find the courage to run Docker in production, i will probably give it a try.
I use https://www.passwordstore.org/ and love it. It's a lot more manual than lastpass or 1password but all I care about is keeping my devices synced, being in full control of my data, and not having to pay anything.
It's so good. It's incredibly simple and fast (it's just a script which works as a front end to git and GPG); it's very well documented and there are only a few commands you need; devices are sync'd by way of git; it's got a heap of add-ons, including an OTP generator. There's even a great iOS app, PassForiOS, which also handles OTP 2FA (the only downside to the app is that you have to clone from an existing pass repository, but that's not a big deal unless you don't have a computer or you were planning on starting to build your password database on your phone). Never used it on Windows or Android so I can't say what it's like there, but if you're on macOS, a combination of GPG Suite, pass, and the default Terminal make password management easy.
edit: there's the unfortunate fact that the names of files in which passwords are stored are in plaintext, since it's all ordinary files and directories. pass-tomb is supposed to be a good way of encrypting your .password-store directory, but I don't think this is compatible with the iOS app. Still, not a serious problem for my use case anyway, and a solution is available if I'd be willing to forego the iOS app.
I'm surprised there's not more discussion of passwordstore in this thread. In light of the parent article, I want to point out one of it's killer features (from my perspective). As it's built on top of PGP, you can move your private key to a PGP smart card and then decryption operations are done entirely on the smart card. Your private key never leaves the card. If you're using a Yubikey as the smart card, there's also a feature where you have to touch the card to approve of any operation (even when already unlocked by entering the smart card's password).
"The idea behind Authorizer is, to use old smartphones as a hardware password manager only. To avoid manual typing of long and complex passwords everytime you need them, Authorizer pretends to be an USB keyboard (e.g. over an USB On-The-Go adapter). With a button press inside the App, it will automatically enters the password for you on your pc, laptop, tablet or main smartphone."
Keepass, or its XC incarnation, does not charge monthly fees. It also incidentally fares best in the summary comparison table in Figure 21 in the article, although as others have pointed out that does not really mean much.
> First and foremost, password managers are a good thing. All password managers we have examined add value to the security posture of secrets management, and as Troy Hunt, an active security researcher once wrote, “Password managers don’t have to be perfect, they just have to be better than not having one”
I would assume that a pseudo-random moderately strong password per site stored in your brain would be more secure than a random strong password that's stored electronically and vulnerable to attack, but maybe not?
I have 50+ entries in my password manager. Even if I use passphrases, I couldn't remember them all.
There's no such thing as perfect security, and IMO a good middle ground is memorizing a long, strong passphrase to unlock a password manager full of random PWs for individual sites.
I guess you could write them down instead, but personally I'm much more worried about someone stealing a physical notebook than getting malicious software onto my computer.
(For example, what happens when you cross a border and an enterprising young border officer photographs the contents of your passwords notebook? This would be perfectly legal in most countries.)
I would assume if that were the case they can intercept the password from the paste buffer anyways.
Your threat assessment is backwards. Someone needs physical access to your computer area to steal your notebook. Anyone anywhere on the globe can make a reasonably trivial attempt to get malicious software on your computer.
At any given time, the number of people who can attack your notebook is... maybe five. The number of people who can attack your computer at any given time is seven billion.
(Also, there are trivial things you can do to make a paper notebook even better. Write the passwords consistently slightly wrong, according to a rule that you only know in your head, or have a common part of all of your passwords only you know, and then use the notebook for uniqueness.)
50+, that sounds nice. I have 300+ and they are all 20 char random except where dumb sites required special rules like 14 char max.
Asking someone to brain more than 5 good passwords is entirely pointless. We just aren’t wired for that.
I’ll agree that secure paper is best for security, but not many people understand what “secure” is. A notebook on your desk isn’t, in a safe is. If I need to log in to AWS at the supermarket, that notebook does me no good.
>I’ll agree that secure paper is best for security, but not many people understand what “secure” is. A notebook on your desk isn’t, in a safe is. If I need to log in to AWS at the supermarket, that notebook does me no good.
I agree, what is "good enough" security depends on your threat model. For example, for an older adult who previously used one dictionary word on every site, a small notebook with a list of PWs in a locked desk drawer is a big step forward.
I like to tell people to treat passwords they have written down like they would a hundred dollar bill. (You keep it on your person, or lock it up when not in use).
>I like to tell people to treat passwords they have written down like they would a hundred dollar bill. (You keep it on your person, or lock it up when not in use).
Does that system fall apart if you need to securely and remotely share a password with your mom? Because that is the standard of usability I've been considering.
You want to call my mom and read her an 18 char password? I'll give you her number, let me know how it goes!
So I think it should be obvious when I say my mom, that's a user I have no control over, I can't yell at, I want to make sure there are no mistakes, and that she can't mess anything up on her end like writing it on a sticky note... If you haven't figured out, mom is the worst possible case for a user.
You're getting lost in the details. It should be SIMPLE to securely share credentials or codes or details with someone, and that can't be done if a piece of paper is your system.
The only way I can realistically operate without a password manager while keeping a unique password per account would be to reset my password every single time I use an account. Which would be... very tedious.
For important things you can use the Munroe method and randomly choose several words from an appropriately large dictionary. The result has the advantage of being much easier to memorize as it lends itself to mnemonic techniques.
The method has detractors who would argue that the word choice wouldn't be random enough, but that's because they employ a strawman who insists on either choosing their own words or using only words they are familiar with. If you actually pull words randomly from a really big dictionary, it has plenty of entropy. Having some obscure words in your passphrase only make it even more memorable anyway.
For unimportant things, like your HN account, who cares.
No, I can't remember that for more than maybe 1 -2 sites that I use every day. I got more than two financial accounts and two emails. Totally infeasible. That not even taking stupid password requirements into account (15 chars max or some shit)
Storing it in your brain is likely better. Unfortunately I can't remember a pseudo-random moderately strong password per site for as many sites as I use, I am just a lowly human.
Depending on what you mean by pseudo-random, you may be correct. Most people can't remember very many random passwords however, which makes that an untenable alternative.
Password managers are universally terrible, but until security experts stop telling people to use them, everyone's going to dump their sensitive passwords into incredibly poor apps written to put all your access in one place secured by one single password.
A lot of password advice today is bad. You only should be making valuable passwords (those that control sensitive data or access) unique. Forum accounts do not need that level of security and you waste cognitive power by doing so.
Banks, email accounts, and a handful of others are the only ones worth truly securing. And passphrases can be incredibly easy to remember, unlike passwords.
How is it more secure to have a passphrase in your head? If an attacker is in a position to exploit your password manager in the way described in this paper, they are in a position to sniff your bank password as soon as you type it
> You only should be making valuable passwords (those that control sensitive data or access) unique.
I have access on a forum where if I log out it asks shows me my sessions, including my IP address. My IP address is PII. I have my e-mail address hidden on this forum as well. My e-mail address is PII.
I have ordered something on AliExpress. My physical address can be found by logging in to my account. I actually have multiple addresses on my eBay account where some can save me some costs due to being in a different country.
And if anyone logs in to my account on AliExpress, they'd be able to log in on that other forum or eBay as well if it weren't for a password manager.
My password manager allows me to make a passphrase, btw. The terrible thing about a passphrase is it takes long to type it, and a typo takes even longer. I prefer a YubiKey plus a decent PIN though it doesn't work very well against a hostile government.
> Forum accounts do not need that level of security
Though it's also in the platform's best interest to defend itself from weak passwords because there are usually a lot more defenses against fresh accounts than existing accounts that get taken over. We're seeing websites becoming more and more proactive here like rejecting passwords that appear on haveibeenpwned.
Also, I recognize your username from your extreme stance against password managers in the past and you seem to make the mistake of not acknowledging trade-offs. I think it weakens your point, especially when talking about end-user security where 90%+ of people are reusing passwords, not debating whether they should use a password manager or roll their own physical password pad scheme.
If you reject current password managers, can you envision a digital solution that would satisfy you?
>Banks, email accounts, and a handful of others are the only ones worth truly securing. And passphrases can be incredibly easy to remember, unlike passwords.
You could also use one long passphrase for your password manager that even a state level adversary probably can't crack:
