17 ms·

Password Managers: Under the Hood of Secrets Management

350 points by thenaturalist 8y ago

iambateman 8y ago
> "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.
- SlowRobotAhead 8y ago
  >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!
  - yinyang_in 8y ago
    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. Yes i use a password manager.
    - WorldMaker 8y ago
      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.
- seppin 8y ago
  > Otherwise, pick any damn password manager and focus on something else. People make the same mistake at the gym. "Which workout plan should I use?" Any plan. Any of them.
  - iamkroot 8y ago
    I've always said that the best workout plan is the one that you'll actually do.
mediocrejoker 8y ago
Why did they evaluate 1Password v4 instead of v7?
- velcrovan 8y ago
  If you read the whole thing, they evaluated both, and found that v7 is actually far worse than v4.
  - mediocrejoker 8y ago
    Yes sorry I replied without reading the entire paper. Would be good to see some responses from the companies. edit: looks like AgileBits has already responded https://discussions.agilebits.com/discussion/comment/493044/#Comment_493044 https://discussions.agilebits.com/discussion/comment/493044/...
    - deleted 8y ago
      [deleted]
- Too 8y ago
  4 is the last version with fully offline vault that doesn't tie you to their cloud subscription service.
peterwwillis 8y ago
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.
Ajedi32 8y ago
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.
- dontbenebby 8y ago
  >The other findings about sensitive information remaining in memory even _after_ the password managers are locked are concerning however. Sounds like a reasonable countermeasure is to quit the manager when not in use. After all, I'd need to enter my password if I was "unlocking" or restarting the app either way. (At least in my manager)
megakid 8y ago
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.
- selectodude 8y ago
  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.
whelchel 8y ago
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.
- peterwwillis 8y ago
  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.
  - petee 8y ago
    And if something crashes and dumps memory, you're right back to the answer being "no", your passwords are no longer protected on disk
  - UnFleshedOne 8y ago
    Why is having _all_ password being unencrypted available to _all_ processes running under the same user context considered an esoteric attack? Basically we are one browser exploit away from using ad-networks to steal all your passwords (from 1Password7).
    - peterwwillis 8y ago
      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.
everdev 8y ago
> 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?
- nkrisc 8y ago
  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.
- Ajedi32 8y ago
  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.
- donaldknuth123 8y ago
  >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? Well obviously, but is it actually reasonable to expect your average person to not only have that kind of password discipline but then actually remember a dozen of them that they often use?
- dontbenebby 8y ago
  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.
nickjj 8y ago
I really like the pass manager (CLI): https://www.passwordstore.org/ https://www.passwordstore.org/ 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.
- folkhack 8y ago
  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 =)
  - tanderson92 8y ago
    This is why pass-tomb was invented.
    - folkhack 8y ago
      Excellent - thanks for the heads up =) Will be looking into this to replace a KeePass DB!
  - nickjj 8y ago
    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/ https://xkcd.com/1200/
pier25 8y ago
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. Is this a mistake or am I missing something?
- TheDong 8y ago
  > requires "100,100" iterations to brute force 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. [0]: https://en.wikipedia.org/wiki/Key_stretching https://en.wikipedia.org/wiki/Key_stretching [1]: https://support.logmeininc.com/lastpass/help/about-password-iterations-lp030027 https://support.logmeininc.com/lastpass/help/about-password-...
  - pier25 8y ago
    Thanks for the explanation
- jsutton 8y ago
  5000 iterations (of PBKDF2) was the original default, and last year it was increased to 100,100 iterations to keep up with hardware capabilities.
thecopy 8y ago
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?
- Ajedi32 8y ago
  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.
  - SlowRobotAhead 8y ago
    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?
- SlowRobotAhead 8y ago
  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?
  - johnmarcus 8y ago
pier25 8y ago
Here is the response from 1Password: https://discussions.agilebits.com/discussion/comment/493044/#Comment_493044 https://discussions.agilebits.com/discussion/comment/493044/...
- Ajedi32 8y ago
  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?
  - mediocrejoker 8y ago
    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.
    - Ajedi32 8y ago
      > 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.
      - huzaif 8y ago
        That makes it kind of an edge case: 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.
gruez 8y ago
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.
- SlowRobotAhead 8y ago
  In the case of 2FA devices, a keylogger won’t get you much on a remote machine. I think the more obvious path is that if you have memory access, just wait for the decrypted contents to be exposed.
  - blitmap 8y ago
    - I am no security person myself. - I always liked this idea: https://krypt.co/ https://krypt.co/ 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.
  - xoa 8y ago
    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.
SloopJon 8y ago
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." https://www.washingtonpost.com/technology/2019/02/19/password-managers-have-security-flaw-you-should-still-use-one/ https://www.washingtonpost.com/technology/2019/02/19/passwor... More from CyberScoop: https://www.cyberscoop.com/bugcrowd-adrian-bednarek-lastpass/ https://www.cyberscoop.com/bugcrowd-adrian-bednarek-lastpass...
asdz 8y ago
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
jrockway 8y ago
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.)
- phishfi 8y ago
  Can't a password manager use the TPM to encrypt/decrypt the passwords in real time, a la Windows Hello?
  - loeg 8y ago
    It seems like a TPM would be a good way for the OS to implement CryptProtectMemory.
r1ch 8y ago
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.
- gruez 8y ago
  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).
- briHass 8y ago
  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.
calibas 8y ago
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.
entity345 8y ago
Are there any decent password managers that do not charge monthly fees? I don't mind paying to buy a good tool but the Saas model is getting out of hand.
- steve19 8y ago
  Bitwarden
- 7v3x3n3sem9vv 8y ago
  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.
  - 8fingerlouie 8y ago
    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.
- zokier 8y ago
  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.
- qudat 8y ago
  I use https://www.passwordstore.org/ 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.
  - 8y ago
hsnewman 8y ago
So why don't these tools use CryptProtectMemory to protect the memory: https://docs.microsoft.com/en-us/windows/desktop/api/dpapi/nf-dpapi-cryptprotectmemory https://docs.microsoft.com/en-us/windows/desktop/api/dpapi/n... ?
- Someone1234 8y ago
  Your own article tells you why: > 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.
  - loeg 8y ago
    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.) https://referencesource.microsoft.com/#mscorlib/system/security/securestring.cs https://referencesource.microsoft.com/#mscorlib/system/secur...
gabriel34 8y ago
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. https://keepass.info/help/v2/autotype_obfuscation.html https://keepass.info/help/v2/autotype_obfuscation.html
illumin8 8y ago
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.
- bndw 8y ago
  MacOS isn't much better. I just tried it myself using fridump[0] and was able to see plaintext secrets when dumping memory. But as pointed out above, if someone has access to dump your machine's memory then you've got bigger fish to fry. [0] https://github.com/Nightbringer21/fridump https://github.com/Nightbringer21/fridump
- zokier 8y ago
  > 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
ashton314 8y ago
How much does this apply to secret managers like [Hashicorp Vault](https://vaultproject.io https://vaultproject.io)? I get it it's more than "just" a password manager.
nothrabannosir 8y ago
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”. https://techcrunch.com/2017/04/06/f-secure-buys-little-flocker-to-upgrade-its-mac-security-play/ https://techcrunch.com/2017/04/06/f-secure-buys-little-flock...
ComputerGuru 8y ago
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.
- magnat 8y ago
  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. [1] https://docs.microsoft.com/en-gb/dotnet/api/system.security.securestring?view=netframework-4.7.2 https://docs.microsoft.com/en-gb/dotnet/api/system.security....
  - Someone1234 8y ago
    Here's the source code if anyone is interested in how it works: https://referencesource.microsoft.com/#mscorlib/system/security/securestring.cs https://referencesource.microsoft.com/#mscorlib/system/secur...
NoblePublius 8y ago
I use Dashlane. Am I dumb? Lastpass looks better.

350 points by thenaturalist 8y ago

> "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.

SlowRobotAhead 8y ago
>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!
- yinyang_in 8y ago
  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. Yes i use a password manager.
  - WorldMaker 8y ago
    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.
seppin 8y ago
> Otherwise, pick any damn password manager and focus on something else. People make the same mistake at the gym. "Which workout plan should I use?" Any plan. Any of them.
- iamkroot 8y ago
  I've always said that the best workout plan is the one that you'll actually do.

mediocrejoker 8y ago

Why did they evaluate 1Password v4 instead of v7?

velcrovan 8y ago
If you read the whole thing, they evaluated both, and found that v7 is actually far worse than v4.
- mediocrejoker 8y ago
  Yes sorry I replied without reading the entire paper. Would be good to see some responses from the companies. edit: looks like AgileBits has already responded https://discussions.agilebits.com/discussion/comment/493044/#Comment_493044 https://discussions.agilebits.com/discussion/comment/493044/...
  - deleted 8y ago
    [deleted]
Too 8y ago
4 is the last version with fully offline vault that doesn't tie you to their cloud subscription service.

peterwwillis 8y ago

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.

Ajedi32 8y ago

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.

dontbenebby 8y ago
>The other findings about sensitive information remaining in memory even _after_ the password managers are locked are concerning however. Sounds like a reasonable countermeasure is to quit the manager when not in use. After all, I'd need to enter my password if I was "unlocking" or restarting the app either way. (At least in my manager)

megakid 8y ago

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.

selectodude 8y ago
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.

whelchel 8y ago

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.

peterwwillis 8y ago
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.
- petee 8y ago
  And if something crashes and dumps memory, you're right back to the answer being "no", your passwords are no longer protected on disk
- UnFleshedOne 8y ago
  Why is having _all_ password being unencrypted available to _all_ processes running under the same user context considered an esoteric attack? Basically we are one browser exploit away from using ad-networks to steal all your passwords (from 1Password7).
  - peterwwillis 8y ago
    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.

everdev 8y ago

> 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?

nkrisc 8y ago
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.
Ajedi32 8y ago
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.
donaldknuth123 8y ago
>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? Well obviously, but is it actually reasonable to expect your average person to not only have that kind of password discipline but then actually remember a dozen of them that they often use?
dontbenebby 8y ago
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.

nickjj 8y ago

I really like the pass manager (CLI): https://www.passwordstore.org/ https://www.passwordstore.org/ 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.

folkhack 8y ago
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 =)
- tanderson92 8y ago
  This is why pass-tomb was invented.
  - folkhack 8y ago
    Excellent - thanks for the heads up =) Will be looking into this to replace a KeePass DB!
- nickjj 8y ago
  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/ https://xkcd.com/1200/

pier25 8y ago

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. Is this a mistake or am I missing something?

TheDong 8y ago
> requires "100,100" iterations to brute force 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. [0]: https://en.wikipedia.org/wiki/Key_stretching https://en.wikipedia.org/wiki/Key_stretching [1]: https://support.logmeininc.com/lastpass/help/about-password-iterations-lp030027 https://support.logmeininc.com/lastpass/help/about-password-...
- pier25 8y ago
  Thanks for the explanation
jsutton 8y ago
5000 iterations (of PBKDF2) was the original default, and last year it was increased to 100,100 iterations to keep up with hardware capabilities.

thecopy 8y ago

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?

Ajedi32 8y ago
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.
- SlowRobotAhead 8y ago
  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?
SlowRobotAhead 8y ago
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?
- johnmarcus 8y ago

pier25 8y ago

Here is the response from 1Password: https://discussions.agilebits.com/discussion/comment/493044/#Comment_493044 https://discussions.agilebits.com/discussion/comment/493044/...

Ajedi32 8y ago
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?
- mediocrejoker 8y ago
  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.
  - Ajedi32 8y ago
    > 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.
    - huzaif 8y ago
      That makes it kind of an edge case: 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.

gruez 8y ago

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.

SlowRobotAhead 8y ago
In the case of 2FA devices, a keylogger won’t get you much on a remote machine. I think the more obvious path is that if you have memory access, just wait for the decrypted contents to be exposed.
- blitmap 8y ago
  - I am no security person myself. - I always liked this idea: https://krypt.co/ https://krypt.co/ 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.
- xoa 8y ago
  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.

SloopJon 8y ago

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." https://www.washingtonpost.com/technology/2019/02/19/password-managers-have-security-flaw-you-should-still-use-one/ https://www.washingtonpost.com/technology/2019/02/19/passwor... More from CyberScoop: https://www.cyberscoop.com/bugcrowd-adrian-bednarek-lastpass/ https://www.cyberscoop.com/bugcrowd-adrian-bednarek-lastpass...

asdz 8y ago

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

jrockway 8y ago

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.)

phishfi 8y ago
Can't a password manager use the TPM to encrypt/decrypt the passwords in real time, a la Windows Hello?
- loeg 8y ago
  It seems like a TPM would be a good way for the OS to implement CryptProtectMemory.

r1ch 8y ago

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.

gruez 8y ago
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).
briHass 8y ago
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.

calibas 8y ago

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.

entity345 8y ago

Are there any decent password managers that do not charge monthly fees? I don't mind paying to buy a good tool but the Saas model is getting out of hand.

steve19 8y ago
Bitwarden
7v3x3n3sem9vv 8y ago
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.
- 8fingerlouie 8y ago
  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.
zokier 8y ago
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.
qudat 8y ago
I use https://www.passwordstore.org/ 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.
- 8y ago

hsnewman 8y ago

So why don't these tools use CryptProtectMemory to protect the memory: https://docs.microsoft.com/en-us/windows/desktop/api/dpapi/nf-dpapi-cryptprotectmemory https://docs.microsoft.com/en-us/windows/desktop/api/dpapi/n... ?

Someone1234 8y ago
Your own article tells you why: > 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.
- loeg 8y ago
  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.) https://referencesource.microsoft.com/#mscorlib/system/security/securestring.cs https://referencesource.microsoft.com/#mscorlib/system/secur...

gabriel34 8y ago

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. https://keepass.info/help/v2/autotype_obfuscation.html https://keepass.info/help/v2/autotype_obfuscation.html

illumin8 8y ago

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.

bndw 8y ago
MacOS isn't much better. I just tried it myself using fridump[0] and was able to see plaintext secrets when dumping memory. But as pointed out above, if someone has access to dump your machine's memory then you've got bigger fish to fry. [0] https://github.com/Nightbringer21/fridump https://github.com/Nightbringer21/fridump
zokier 8y ago
> 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

ashton314 8y ago

How much does this apply to secret managers like [Hashicorp Vault](https://vaultproject.io https://vaultproject.io)? I get it it's more than "just" a password manager.

nothrabannosir 8y ago

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”. https://techcrunch.com/2017/04/06/f-secure-buys-little-flocker-to-upgrade-its-mac-security-play/ https://techcrunch.com/2017/04/06/f-secure-buys-little-flock...

ComputerGuru 8y ago

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.

magnat 8y ago
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. [1] https://docs.microsoft.com/en-gb/dotnet/api/system.security.securestring?view=netframework-4.7.2 https://docs.microsoft.com/en-gb/dotnet/api/system.security....
- Someone1234 8y ago
  Here's the source code if anyone is interested in how it works: https://referencesource.microsoft.com/#mscorlib/system/security/securestring.cs https://referencesource.microsoft.com/#mscorlib/system/secur...

NoblePublius 8y ago

I use Dashlane. Am I dumb? Lastpass looks better.