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.
> "First and foremost, password managers are a good thing. All password managers we have examined add value to the security posture of secrets management"<p>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.<p>Otherwise, pick any damn password manager and focus on something else.
Here is the response from 1Password: <a href="https://discussions.agilebits.com/discussion/comment/493044/#Comment_493044" rel="nofollow">https://discussions.agilebits.com/discussion/comment/493044/...</a>
Reposting my comment from the previous submission:<p>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."<p><a href="https://www.washingtonpost.com/technology/2019/02/19/password-managers-have-security-flaw-you-should-still-use-one/" rel="nofollow">https://www.washingtonpost.com/technology/2019/02/19/passwor...</a><p>More from CyberScoop:<p><a href="https://www.cyberscoop.com/bugcrowd-adrian-bednarek-lastpass/" rel="nofollow">https://www.cyberscoop.com/bugcrowd-adrian-bednarek-lastpass...</a>
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.<p>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.<p>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.
I really like the pass manager (CLI): <a href="https://www.passwordstore.org/" rel="nofollow">https://www.passwordstore.org/</a><p>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.<p>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.
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.
I just moved from LastPass to 1Password7, and this sentence will make me consider moving back:<p>> 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.<p>That is unacceptable, what type of developers do they have?
So why don't these tools use CryptProtectMemory to protect the memory: <a href="https://docs.microsoft.com/en-us/windows/desktop/api/dpapi/nf-dpapi-cryptprotectmemory" rel="nofollow">https://docs.microsoft.com/en-us/windows/desktop/api/dpapi/n...</a> ?
Keepass does have coutermeasures against clipboard sniffing (auto-type instead of copying to clipboard) and keyloggers (Two-Channel Auto-Type Obfuscation).<p>These are effective against non-specialized attack software.<p><a href="https://keepass.info/help/v2/autotype_obfuscation.html" rel="nofollow">https://keepass.info/help/v2/autotype_obfuscation.html</a>
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.
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).<p>For ages, on Unix this could be solved with users and daemonisation. Later came SELinux which is criminally underused.<p>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.<p>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!).<p>Given the direction things are moving in, and the hire of Jonathan, I’m very hopeful this will eventually arrive. It would be a <i>tremendous</i> 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”.<p><a href="https://techcrunch.com/2017/04/06/f-secure-buys-little-flocker-to-upgrade-its-mac-security-play/" rel="nofollow">https://techcrunch.com/2017/04/06/f-secure-buys-little-flock...</a>
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.
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.<p>Nowadays, a password manager can't even do that?<p>* 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.<p>Is this a mistake or am I missing something?
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.
These evaluations all happened on Windows, which is notoriously bad at protecting memory from snooping by other processes.<p>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.
How much does this apply to secret managers like [Hashicorp Vault](<a href="https://vaultproject.io" rel="nofollow">https://vaultproject.io</a>)? I get it it's more than "just" a password manager.
Are there any decent password managers that do not charge monthly fees?<p>I don't mind paying to buy a good tool but the Saas model is getting out of hand.
> 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”<p>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?