7 ms·

Why traditional password managers are flawed

55 points by w8rbt 9y ago

patrickmn 9y ago
Related discussion: https://news.ycombinator.com/item?id=14587357 https://news.ycombinator.com/item?id=14587357
xenph 9y ago
Is it just me, or would the suggested C++ usage leak the all the credentials to the history buffer?
- jhasse 9y ago
  I think you're right. Quite a big flaw.
ketralnis 9y ago
Despite the inflammatory title, these kinds of password "managers" that are stateless and rely instead on a hash system come up quite frequently but they never have an answer for some basic problems that plague real-life accounts and passwords. * Requirements of character sets used on different services. One upper case, two special characters, and 18 octothorps required. * Differing rotation schedules. ___ Bank forces me to rotate every 6 months but _____ Work account forces me to rotate every 12 * Similarly, the ability to rotate a password after a breach of it or of a service There are some other features of password managers (that I like to have but aren't deal breakers) that aren't supportable statelessly: * A way to store the username you used, or even a way to look up "do I have an account on ____ service?" so you can know if it needs rotating after a breach of the site * A way to list all known accounts, so that they can be rotated after a breach of the master DB (or master "sentence" in this case) or even just periodically Solving any one of these problems requires a secure place to store state, but once you have a secure place to store state you can just store the passwords themselves. I'd recommend very strongly against a system like this because it strongly discourages proper rotation hygiene
- harryf 9y ago
  Your first two points should be pretty easy to implement with this stateless approach. The second two points could be do-able if you're willing to let the tool dictate choices for you (e.g. choice of username). The last - OK probably not.
- wfunction 9y ago
  > A way to list all known accounts (I'll call this "discoverability" or "browsability".) I'm gonna go farther and say that the entire notion of discoverability is undervalued in a whole range of scenarios, not just here. Many of us programmers are so used to the notion of "you should already know X in order to do Y" that we completely ignore how detrimental and unusable it is for mortals. At the risk of going off-topic, another example is the fundamental difference between a GUI and a CLI... the poor user who's just trying to learn how to use the computer can always click a menu or right-click an empty window to see most things that can possibly be done (there's only so many buttons on a mouse), but good luck having them discover what they can do with their keyboard. e.g. there's a command called "apropos foo" but how the hell is the user supposed to know about it? On a GUI you just click the Help menu (it's already there) and look at the contents. And even the help system can't know about every command. People have to read manuals and remember a ton of things before they can use CLI tools, in contrast with GUI tools which they can discover as they go. (Obligatory note: I'm not saying they can always substitute for each other, or that even one is always better... e.g. it's obviously much harder to automate GUI tasks. Just drawing a comparison here because I think there is a larger point to be made.) Another (off-topic) example is the difference between opt-out and opt-in systems for practically anything. In practice (maybe not in theory), people have to know what to opt out of in order to have any chance of being successful at it, but they are generally allowed to discover what they can opt into. Of course this is usually due to misaligned incentives, but the point is that knowing a-priori what to do can be a crux of what makes something practical vs. impractical for consumer usage.
  - sokoloff 9y ago
    > good luck having them discover what they can do with their keyboard. e.g. there's a command called "apropos foo" but how the hell is the user supposed to know about it? This is one of the prime drivers behind stackoverflow (and related)'s success. I'm amazed at the number of times I run into a "how to get equipment X to behave in fashion Y" and find a cookbook recipe of exactly (or more than half of) what I need to do. It's my own personal reminder that the world is a big place with lots of people not all that different from myself.
kennydude 9y ago
> Use the same sentence everywhere. Commit it to memory. Sounds like a master password to me
- tome 9y ago
  That's what I was just thinking. I really wonder what the response is to this objection.
1ba9115454 9y ago
I use KeePass and I'm quite happy. The database is local and enrypted with AES. My master password is around 72bits of entropy. I keep 2 files actually. Day to day stuff and critical services. So I only open up and therefore expose my master password infrequently for the critical services. (i.e. banking etc.) I've enabled 2FA on everything I can. So I think I'm safer than this deterministic solution as if my master password gets out, you still have to get past 2FA.
- kuzimoto 9y ago
  I love using KeePass. I keep the database file at home and only use it remotely with a plugin to allow accessing it via SSH so that the file is never (permanently) stored on disk. I like to think that this is even more secure than other methods since even if someone were to log keystrokes, they would need to know the SSH server details as well to actually gain access to the file. It can also be used to store 2FA secrets and KeePass2Android lets you generate the TOTP pretty easily so you're not relying on an app such as Google Authenticator which (last time I used it) doesn't backup secrets, and app itself isn't password protected.
  - 1ba9115454 9y ago
    Authy can be used instread of Google authenticator and backups up an encrypted copy of your secrets.
- BeetleB 9y ago
  >I've enabled 2FA on everything I can. This may make things less secure, especially if the second factor involves a phone. https://www.wired.com/2016/06/hey-stop-using-texts-two-factor-authentication/ https://www.wired.com/2016/06/hey-stop-using-texts-two-facto... It's a lot easier than the article indicates to get control of your phone. People have just walked into the phone company's store and get whatever is needed to control your phone number. Security based on poorly trained frontline folks (i.e. the clerks at those stores) is the worst kind. I've fooled (or observed) leasing offices give the keys to an apartment to someone not on the lease. I've obtained hotel room keys that way. I've had checks cashed that were not signed.
jhasse 9y ago
GUI implementation with this approach: https://bixense.com/pwcalculator/ https://bixense.com/pwcalculator/
- w8rbt 9y ago
  The java version of dpg is a GUI.
  - jhasse 9y ago
    My bad, sorry. I only took a look at the C++ version.
prohor 9y ago
There is similar plugin for Firefox for years. There is also one for Chrome that uses the same algorithm, so generates the same password. It keeps user name and version of the password for a domain in regular FF password storage. https://addons.mozilla.org/pl/firefox/addon/password-hasher/ https://addons.mozilla.org/pl/firefox/addon/password-hasher/
dchest 9y ago
Such generators seem to pop up every week or so (I'm also guilty of creating a few of them; then switched to a normal password manager). Obligatory analysis: https://crypto.stackexchange.com/a/5691 https://crypto.stackexchange.com/a/5691
rolfvandekrol 9y ago
Every few weeks a discussion about a deterministic password manager comes up. This is not a new idea, and already countless times proved to be a flawed idea. Lenghty explanation, better worded than I can: https://tonyarcieri.com/4-fatal-flaws-in-deterministic-password-managers https://tonyarcieri.com/4-fatal-flaws-in-deterministic-passw...
jlebrech 9y ago
what about using something like this https://www.passwordcard.org/en https://www.passwordcard.org/en and a sequence like up, down, down, up (memorizing the collumns and rows too). and using separate cards for different keystores.
baby 9y ago
I don't think stateless is the answer, but I think that approaches like SPHINX is: http://webee.technion.ac.il/~hugo/sphinx.pdf http://webee.technion.ac.il/~hugo/sphinx.pdf It deterministically generates passwords, and coupled with a statefull client you should be able to have a practical password manager that doesn't need to trust any third party.
epistasis 9y ago
$ dpg "The sentence" word Doesn't this store all your secret info in your .bash_history file, an unencrypted plain text file, with a convenient marker for finding it in the history file? This is no better than just storing the password that DGP generates directly; it's deterministic and trivial to derive the password. For somebody concerned about a "master password" being insecure, this is a far far worse solution.
- untog 9y ago
  Yes. And this is a great example of why titles like this one undermine any point the author hopes to make. I'm a full time and, I hope, very capable developer. But I'm not a full time, capable password manager developer. Simply by virtue of the number of hours available in the day, the homebrew password manager I create in my spare time will never be as secure as the one made by someone who dedicates themselves to this area. So I'll just go ahead and use the one they made.
- mnarayan01 9y ago
  You could potentially add something like: HISTIGNORE='dpg *' to e.g. your .bashrc -- not sure if the version of bash on OSX supports HISTIGNORE though (plus many other issues).
  - acdha 9y ago
    This is true but I'd be really hesitant to recommend it since the failure mode is so subtle unless you updated dpg to do something like loudly throw an error if that's not set.
- bluGill 9y ago
  Worse it puts the secret into the process table where any user with ps can read it.
- w8rbt 9y ago
  The purpose of the C++ implementation is to test and validate the other implementations. Use the Python or Java versions.
caio1982 9y ago
They might be flawed but they provide easy-to-use solutions that add value to a huge user base. If you think a solution is better, at least make it so you don't need to reeducate everybody on Earth. It's like that saying: would you rather be right or be happy?
arm85 9y ago
"Password Safe" isn't a traditional password manager?
johnpython 9y ago
When it comes to security tools, I strongly recommend not to use pet projects maintained by a single person over well-established open source tools. If you are looking for a cross-platform, reliable, secure password manager, KeePassXC is an excellent choice. https://keepassxc.org https://keepassxc.org
45h34jh53k4j 9y ago
I strongly recommend that we stop inventing new implementations of a very flawed concept. Derived passwords from a seed is practically and operationally worse than a encrypted password database. This keeps popping up lately, and every suggested implementation has objectively worse security, scalability and integrity than 1Password, KeePass, Dashlane or Lastpass. Some simple problems that means this cannot work for me: * Many password context's dont have a 'site' to derive from, now need to remember the IV for some random non-internet password (my luggage combo lock PIN, was the seed 'luggage' or 'travel bag' or 'samsonite'?) * Might need multiple passwords per site; Multi users (need to remember all these shuffle codes) * passwords are compromised all the time, now I have to remember the nonce/shuffle value for every one that gets leaked? (how do track this?) * Storing non password data, like 'secret questions' or 'PINs' (not a generic secret store) These same issues come up with every seed derived password scheme. The only place this concept works is a very specific and metadata less context, such as HD derived cryptographic keys.
doppel 9y ago
Instead of remembering a master password, you now have to remember a sentence + a word for every site you want to use ("was it facebook, facebook.com or FB?"). Half the job of a password manager is to make sure you a) have unique passwords for each site and b) do not have to remember more than the master password. I sometimes use 1Password as a test to see if I even have an account if I visit a site I haven't been on in years.
LesZedCB 9y ago
why shouldn't I just continue using my 'traditional' password manager, and just enable 2FA on every site that makes it available. Hidden information and a user-action is much safer. The convenience of my password manager is far to great to give up.
KKKKkkkk1 9y ago
I never understood password managers. What do I get from a password manager that I can't achieve by storing my passwords in a text file and encrypting it with $MY_OS's built-in file-encryption facility? And if I want timestamps and history, I can encrypt a git repo storing that file. Are password managers purely a Windows phenomenon, where you need a GUI for every little task you do?
- kuzimoto 9y ago
  I'd assume that it's mostly for convenience really. Here's some things I can do with KeePass that a text file doesn't do: 1. Auto-Type 2. Access with mobile phone 3. Advanced search; by username, site, password, etc. 4. Audit password complexity 5. Password generator with many options (number of chars, what chars to use, etc.) 6. Ability to store other file types within the database which is associated with a specific entry 7. Password expiration rules Those some of the things off the top of my head. While your method works for you, I really wouldn't trust 99% of people to know how to properly encrypt and store a password text file.
shinratdr 9y ago
Don't let perfect be the enemy of good. Have you seen how people manage their passwords? Even a deeply flawed password manager is better than the current method of using the same password for everything or resetting their password every time they need to log in. Average people probably have 20-50 accounts they have to remember the passwords for regularly, and for people who do a lot of online shopping or internet browsing, it's probably closer to 50-100. Even when we had to remember phone numbers, people retained what, like maybe 10, max? Expecting them to remember unique combinations of 50 different username/email/password combos isn't just bad security, its arguably near impossible for most people. It's all well and good to warn about the flaws in trusting a browser (although this basically amounts to "too much is going on so don't trust it" which is a poor argument) or the inherent insecurity of a master password. But if you're already in the state that most users are in, those "massive issues" are orders of magnitude better than the current state. The convenience compromises those solutions make is so that people will adopt them. Is this more secure? Definitely. Will any significant number use it? No.
tzs 9y ago
Speaking of password management, it would make it a lot more convenient if website login pages supported single field login. What I mean by single field login is allowing both the username and the password in the same field, so that a single copy/paste from the password manager to the browser could fill in both. Suggested implementation: provide separate username and password fields that work normally when both are filled, but if the username field is empty then check the password field for something of the form username/password (or something like that, details depending on the username and password rules for the site).
- tptacek 9y ago
  This is unlikely to happen. Big sites spend effort to avoid confusion or surprise on login pages. They could add a new password-manager login page, but all the major password managers already have logic to do the two pastes into the two fields, so what would be the point?

55 points by w8rbt 9y ago

patrickmn 9y ago

Related discussion: https://news.ycombinator.com/item?id=14587357 https://news.ycombinator.com/item?id=14587357

xenph 9y ago

Is it just me, or would the suggested C++ usage leak the all the credentials to the history buffer?

jhasse 9y ago
I think you're right. Quite a big flaw.

ketralnis 9y ago

Despite the inflammatory title, these kinds of password "managers" that are stateless and rely instead on a hash system come up quite frequently but they never have an answer for some basic problems that plague real-life accounts and passwords. * Requirements of character sets used on different services. One upper case, two special characters, and 18 octothorps required. * Differing rotation schedules. ___ Bank forces me to rotate every 6 months but _____ Work account forces me to rotate every 12 * Similarly, the ability to rotate a password after a breach of it or of a service There are some other features of password managers (that I like to have but aren't deal breakers) that aren't supportable statelessly: * A way to store the username you used, or even a way to look up "do I have an account on ____ service?" so you can know if it needs rotating after a breach of the site * A way to list all known accounts, so that they can be rotated after a breach of the master DB (or master "sentence" in this case) or even just periodically Solving any one of these problems requires a secure place to store state, but once you have a secure place to store state you can just store the passwords themselves. I'd recommend very strongly against a system like this because it strongly discourages proper rotation hygiene

harryf 9y ago
Your first two points should be pretty easy to implement with this stateless approach. The second two points could be do-able if you're willing to let the tool dictate choices for you (e.g. choice of username). The last - OK probably not.
wfunction 9y ago
> A way to list all known accounts (I'll call this "discoverability" or "browsability".) I'm gonna go farther and say that the entire notion of discoverability is undervalued in a whole range of scenarios, not just here. Many of us programmers are so used to the notion of "you should already know X in order to do Y" that we completely ignore how detrimental and unusable it is for mortals. At the risk of going off-topic, another example is the fundamental difference between a GUI and a CLI... the poor user who's just trying to learn how to use the computer can always click a menu or right-click an empty window to see most things that can possibly be done (there's only so many buttons on a mouse), but good luck having them discover what they can do with their keyboard. e.g. there's a command called "apropos foo" but how the hell is the user supposed to know about it? On a GUI you just click the Help menu (it's already there) and look at the contents. And even the help system can't know about every command. People have to read manuals and remember a ton of things before they can use CLI tools, in contrast with GUI tools which they can discover as they go. (Obligatory note: I'm not saying they can always substitute for each other, or that even one is always better... e.g. it's obviously much harder to automate GUI tasks. Just drawing a comparison here because I think there is a larger point to be made.) Another (off-topic) example is the difference between opt-out and opt-in systems for practically anything. In practice (maybe not in theory), people have to know what to opt out of in order to have any chance of being successful at it, but they are generally allowed to discover what they can opt into. Of course this is usually due to misaligned incentives, but the point is that knowing a-priori what to do can be a crux of what makes something practical vs. impractical for consumer usage.
- sokoloff 9y ago
  > good luck having them discover what they can do with their keyboard. e.g. there's a command called "apropos foo" but how the hell is the user supposed to know about it? This is one of the prime drivers behind stackoverflow (and related)'s success. I'm amazed at the number of times I run into a "how to get equipment X to behave in fashion Y" and find a cookbook recipe of exactly (or more than half of) what I need to do. It's my own personal reminder that the world is a big place with lots of people not all that different from myself.

kennydude 9y ago

> Use the same sentence everywhere. Commit it to memory. Sounds like a master password to me

tome 9y ago
That's what I was just thinking. I really wonder what the response is to this objection.

1ba9115454 9y ago

I use KeePass and I'm quite happy. The database is local and enrypted with AES. My master password is around 72bits of entropy. I keep 2 files actually. Day to day stuff and critical services. So I only open up and therefore expose my master password infrequently for the critical services. (i.e. banking etc.) I've enabled 2FA on everything I can. So I think I'm safer than this deterministic solution as if my master password gets out, you still have to get past 2FA.

kuzimoto 9y ago
I love using KeePass. I keep the database file at home and only use it remotely with a plugin to allow accessing it via SSH so that the file is never (permanently) stored on disk. I like to think that this is even more secure than other methods since even if someone were to log keystrokes, they would need to know the SSH server details as well to actually gain access to the file. It can also be used to store 2FA secrets and KeePass2Android lets you generate the TOTP pretty easily so you're not relying on an app such as Google Authenticator which (last time I used it) doesn't backup secrets, and app itself isn't password protected.
- 1ba9115454 9y ago
  Authy can be used instread of Google authenticator and backups up an encrypted copy of your secrets.
BeetleB 9y ago
>I've enabled 2FA on everything I can. This may make things less secure, especially if the second factor involves a phone. https://www.wired.com/2016/06/hey-stop-using-texts-two-factor-authentication/ https://www.wired.com/2016/06/hey-stop-using-texts-two-facto... It's a lot easier than the article indicates to get control of your phone. People have just walked into the phone company's store and get whatever is needed to control your phone number. Security based on poorly trained frontline folks (i.e. the clerks at those stores) is the worst kind. I've fooled (or observed) leasing offices give the keys to an apartment to someone not on the lease. I've obtained hotel room keys that way. I've had checks cashed that were not signed.

jhasse 9y ago

GUI implementation with this approach: https://bixense.com/pwcalculator/ https://bixense.com/pwcalculator/

w8rbt 9y ago
The java version of dpg is a GUI.
- jhasse 9y ago
  My bad, sorry. I only took a look at the C++ version.

prohor 9y ago

There is similar plugin for Firefox for years. There is also one for Chrome that uses the same algorithm, so generates the same password. It keeps user name and version of the password for a domain in regular FF password storage. https://addons.mozilla.org/pl/firefox/addon/password-hasher/ https://addons.mozilla.org/pl/firefox/addon/password-hasher/

dchest 9y ago

Such generators seem to pop up every week or so (I'm also guilty of creating a few of them; then switched to a normal password manager). Obligatory analysis: https://crypto.stackexchange.com/a/5691 https://crypto.stackexchange.com/a/5691

rolfvandekrol 9y ago

Every few weeks a discussion about a deterministic password manager comes up. This is not a new idea, and already countless times proved to be a flawed idea. Lenghty explanation, better worded than I can: https://tonyarcieri.com/4-fatal-flaws-in-deterministic-password-managers https://tonyarcieri.com/4-fatal-flaws-in-deterministic-passw...

jlebrech 9y ago

what about using something like this https://www.passwordcard.org/en https://www.passwordcard.org/en and a sequence like up, down, down, up (memorizing the collumns and rows too). and using separate cards for different keystores.

baby 9y ago

I don't think stateless is the answer, but I think that approaches like SPHINX is: http://webee.technion.ac.il/~hugo/sphinx.pdf http://webee.technion.ac.il/~hugo/sphinx.pdf It deterministically generates passwords, and coupled with a statefull client you should be able to have a practical password manager that doesn't need to trust any third party.

epistasis 9y ago

$ dpg "The sentence" word Doesn't this store all your secret info in your .bash_history file, an unencrypted plain text file, with a convenient marker for finding it in the history file? This is no better than just storing the password that DGP generates directly; it's deterministic and trivial to derive the password. For somebody concerned about a "master password" being insecure, this is a far far worse solution.

untog 9y ago
Yes. And this is a great example of why titles like this one undermine any point the author hopes to make. I'm a full time and, I hope, very capable developer. But I'm not a full time, capable password manager developer. Simply by virtue of the number of hours available in the day, the homebrew password manager I create in my spare time will never be as secure as the one made by someone who dedicates themselves to this area. So I'll just go ahead and use the one they made.
mnarayan01 9y ago
You could potentially add something like: HISTIGNORE='dpg *' to e.g. your .bashrc -- not sure if the version of bash on OSX supports HISTIGNORE though (plus many other issues).
- acdha 9y ago
  This is true but I'd be really hesitant to recommend it since the failure mode is so subtle unless you updated dpg to do something like loudly throw an error if that's not set.
bluGill 9y ago
Worse it puts the secret into the process table where any user with ps can read it.
w8rbt 9y ago
The purpose of the C++ implementation is to test and validate the other implementations. Use the Python or Java versions.

caio1982 9y ago

They might be flawed but they provide easy-to-use solutions that add value to a huge user base. If you think a solution is better, at least make it so you don't need to reeducate everybody on Earth. It's like that saying: would you rather be right or be happy?

arm85 9y ago

"Password Safe" isn't a traditional password manager?

johnpython 9y ago

When it comes to security tools, I strongly recommend not to use pet projects maintained by a single person over well-established open source tools. If you are looking for a cross-platform, reliable, secure password manager, KeePassXC is an excellent choice. https://keepassxc.org https://keepassxc.org

45h34jh53k4j 9y ago

I strongly recommend that we stop inventing new implementations of a very flawed concept. Derived passwords from a seed is practically and operationally worse than a encrypted password database. This keeps popping up lately, and every suggested implementation has objectively worse security, scalability and integrity than 1Password, KeePass, Dashlane or Lastpass. Some simple problems that means this cannot work for me: * Many password context's dont have a 'site' to derive from, now need to remember the IV for some random non-internet password (my luggage combo lock PIN, was the seed 'luggage' or 'travel bag' or 'samsonite'?) * Might need multiple passwords per site; Multi users (need to remember all these shuffle codes) * passwords are compromised all the time, now I have to remember the nonce/shuffle value for every one that gets leaked? (how do track this?) * Storing non password data, like 'secret questions' or 'PINs' (not a generic secret store) These same issues come up with every seed derived password scheme. The only place this concept works is a very specific and metadata less context, such as HD derived cryptographic keys.

doppel 9y ago

Instead of remembering a master password, you now have to remember a sentence + a word for every site you want to use ("was it facebook, facebook.com or FB?"). Half the job of a password manager is to make sure you a) have unique passwords for each site and b) do not have to remember more than the master password. I sometimes use 1Password as a test to see if I even have an account if I visit a site I haven't been on in years.

LesZedCB 9y ago

why shouldn't I just continue using my 'traditional' password manager, and just enable 2FA on every site that makes it available. Hidden information and a user-action is much safer. The convenience of my password manager is far to great to give up.

KKKKkkkk1 9y ago

I never understood password managers. What do I get from a password manager that I can't achieve by storing my passwords in a text file and encrypting it with $MY_OS's built-in file-encryption facility? And if I want timestamps and history, I can encrypt a git repo storing that file. Are password managers purely a Windows phenomenon, where you need a GUI for every little task you do?

kuzimoto 9y ago
I'd assume that it's mostly for convenience really. Here's some things I can do with KeePass that a text file doesn't do: 1. Auto-Type 2. Access with mobile phone 3. Advanced search; by username, site, password, etc. 4. Audit password complexity 5. Password generator with many options (number of chars, what chars to use, etc.) 6. Ability to store other file types within the database which is associated with a specific entry 7. Password expiration rules Those some of the things off the top of my head. While your method works for you, I really wouldn't trust 99% of people to know how to properly encrypt and store a password text file.

shinratdr 9y ago

Don't let perfect be the enemy of good. Have you seen how people manage their passwords? Even a deeply flawed password manager is better than the current method of using the same password for everything or resetting their password every time they need to log in. Average people probably have 20-50 accounts they have to remember the passwords for regularly, and for people who do a lot of online shopping or internet browsing, it's probably closer to 50-100. Even when we had to remember phone numbers, people retained what, like maybe 10, max? Expecting them to remember unique combinations of 50 different username/email/password combos isn't just bad security, its arguably near impossible for most people. It's all well and good to warn about the flaws in trusting a browser (although this basically amounts to "too much is going on so don't trust it" which is a poor argument) or the inherent insecurity of a master password. But if you're already in the state that most users are in, those "massive issues" are orders of magnitude better than the current state. The convenience compromises those solutions make is so that people will adopt them. Is this more secure? Definitely. Will any significant number use it? No.

tzs 9y ago

Speaking of password management, it would make it a lot more convenient if website login pages supported single field login. What I mean by single field login is allowing both the username and the password in the same field, so that a single copy/paste from the password manager to the browser could fill in both. Suggested implementation: provide separate username and password fields that work normally when both are filled, but if the username field is empty then check the password field for something of the form username/password (or something like that, details depending on the username and password rules for the site).

tptacek 9y ago
This is unlikely to happen. Big sites spend effort to avoid confusion or surprise on login pages. They could add a new password-manager login page, but all the major password managers already have logic to do the two pastes into the two fields, so what would be the point?