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
I use a system that I wrote https://github.com/kybernetikos/sinkless (incidentally it uses a similar system to this article - PBKDF with SHA512 -
in browser plugins) that supports many of these situations.
* The character sets can be entered manually. They form public information and are stored locally, can easily be exported as csv.
* Each password has a 'version' which you can increment. The version is considered public information and is stored locally and can easily be exported as CSV. In order to help you know that you've got the version correct, there is a visual indicator - an emoji.
* The version can be used to rotate passwords after a breech.
* My system stores all the settings that have been used on this client and lets you export them and import new ones. This lets you see if you have an account on a service.
* I don't have an explicit way of storing the username, but there are ways - you can include the username in the salt.
* The ability to list all accounts that a particular client has seen gives a partial solution to your need to see all known accounts.
> 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.
This is not true. All of these things are settings related, and can be considered public information, which means you don't need a secure place to store this state, you can store it nearly anywhere, drop box, email, plain text on a website if you want. In a gist etc.
Also, even if it were true, storing the actual passwords means that you have a single point of failure - if the password storage is compromised the whole thing is compromised.
(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.
Yeah, the random, terrible requirements of some sites is what will keep me on 1password. Yes, if I was specifically targeted I'm sure my accounts will be compromised, but the thing is I am not really concerned about that - the bigger problem is every random site losing user data every other week. If they have a throwaway password I am already better off than 95% of the population.
But honestly, it is quite unbelievable how many sites don't allow certain special characters, limit you to X characters, etc.
And I think one key factor that developers forget is convenience and UX, if a password manager is cumbersome, or only works on some sites, then the chances of a user dropping it will increase a ton.
My tool uses a revocation list for scheduled password changes. Normally, the password is generated as
i = 0
return kdf(masterpassword, sitename, 0)
where kdf() is a suitable key-derivation function. However, when that password is on the revocation list, then i is incremented and the kdf() reexecuted until a non-revoked password is found.
The revocation list technically makes the password manager not-stateless, but I don't care. If I ever lose it, I can just generate passwords for each site and revoke them until I find the one that works.
For all the other concerns that you list, I have a textfile listing all my accounts, and the weird derivation rules that are required for some of them (e.g. "take first 19 chars, then append capital A"). That text file is in a private Git repo. Now you could hack my notebook to get at that repo, but if you do, all is lost anyway, so as far as my threat model goes, it's not a problem to have this text file.
I agree with all these points completely, and I'd like to extend a bit more:
* The criticism of cloud-based storage isn't really valid. Any decent password manager should only sync the encrypted data, and never move anything unencrypted.
* Browser integration isn't obligatory. Lots of PM's don't use that, and lots of users are okay with that, so that attack surface isn't an intrinsic part of a classic password manager.
Since a lot of sites have unique requirements, but those unique requirements are usually a subset of 1 number, 1 special character, 1 uppercase character, why not just force the generator to always contain uppercase, always put in a number and always put in a `.` (or whatever the most accepted special character is)? Yes, it ever so slightly reduces the brute force searchspace, but that's non-trivial with a lengthy password.
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.
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.
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.
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.
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.
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.
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-passw...
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.
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
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?
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).
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?
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.
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.
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.
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.
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?
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.
what about using something like this 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.
[+] [-] ketralnis|8 years ago|reply
* 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
[+] [-] kybernetikos|8 years ago|reply
* The character sets can be entered manually. They form public information and are stored locally, can easily be exported as csv.
* Each password has a 'version' which you can increment. The version is considered public information and is stored locally and can easily be exported as CSV. In order to help you know that you've got the version correct, there is a visual indicator - an emoji.
* The version can be used to rotate passwords after a breech.
* My system stores all the settings that have been used on this client and lets you export them and import new ones. This lets you see if you have an account on a service.
* I don't have an explicit way of storing the username, but there are ways - you can include the username in the salt.
* The ability to list all accounts that a particular client has seen gives a partial solution to your need to see all known accounts.
> 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.
This is not true. All of these things are settings related, and can be considered public information, which means you don't need a secure place to store this state, you can store it nearly anywhere, drop box, email, plain text on a website if you want. In a gist etc.
Also, even if it were true, storing the actual passwords means that you have a single point of failure - if the password storage is compromised the whole thing is compromised.
[+] [-] wfunction|8 years ago|reply
(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.
[+] [-] jclardy|8 years ago|reply
But honestly, it is quite unbelievable how many sites don't allow certain special characters, limit you to X characters, etc.
And I think one key factor that developers forget is convenience and UX, if a password manager is cumbersome, or only works on some sites, then the chances of a user dropping it will increase a ton.
[+] [-] majewsky|8 years ago|reply
My tool uses a revocation list for scheduled password changes. Normally, the password is generated as
where kdf() is a suitable key-derivation function. However, when that password is on the revocation list, then i is incremented and the kdf() reexecuted until a non-revoked password is found.The revocation list technically makes the password manager not-stateless, but I don't care. If I ever lose it, I can just generate passwords for each site and revoke them until I find the one that works.
For all the other concerns that you list, I have a textfile listing all my accounts, and the weird derivation rules that are required for some of them (e.g. "take first 19 chars, then append capital A"). That text file is in a private Git repo. Now you could hack my notebook to get at that repo, but if you do, all is lost anyway, so as far as my threat model goes, it's not a problem to have this text file.
[+] [-] hobarrera|8 years ago|reply
* The criticism of cloud-based storage isn't really valid. Any decent password manager should only sync the encrypted data, and never move anything unencrypted. * Browser integration isn't obligatory. Lots of PM's don't use that, and lots of users are okay with that, so that attack surface isn't an intrinsic part of a classic password manager.
[+] [-] jorvi|8 years ago|reply
[+] [-] harryf|8 years ago|reply
[+] [-] Theodores|8 years ago|reply
https://en.wiktionary.org/wiki/octothorps
[+] [-] epistasis|8 years ago|reply
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|8 years ago|reply
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.
[+] [-] bluGill|8 years ago|reply
[+] [-] mnarayan01|8 years ago|reply
[+] [-] w8rbt|8 years ago|reply
[+] [-] 1ba9115454|8 years ago|reply
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.
[+] [-] BeetleB|8 years ago|reply
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-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.
[+] [-] kuzimoto|8 years ago|reply
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.
[+] [-] 45h34jh53k4j|8 years ago|reply
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.
[+] [-] rolfvandekrol|8 years ago|reply
[+] [-] kennydude|8 years ago|reply
Sounds like a master password to me
[+] [-] tome|8 years ago|reply
[+] [-] doppel|8 years ago|reply
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.
[+] [-] xenph|8 years ago|reply
[+] [-] jhasse|8 years ago|reply
[+] [-] dchest|8 years ago|reply
[+] [-] patrickmn|8 years ago|reply
[+] [-] caio1982|8 years ago|reply
[+] [-] tzs|8 years ago|reply
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|8 years ago|reply
[+] [-] shinratdr|8 years ago|reply
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.
[+] [-] johnpython|8 years ago|reply
https://keepassxc.org
[+] [-] prohor|8 years ago|reply
https://addons.mozilla.org/pl/firefox/addon/password-hasher/
[+] [-] baby|8 years ago|reply
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.
[+] [-] arm85|8 years ago|reply
[+] [-] jhasse|8 years ago|reply
[+] [-] w8rbt|8 years ago|reply
[+] [-] KKKKkkkk1|8 years ago|reply
[+] [-] kuzimoto|8 years ago|reply
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.
[+] [-] jlebrech|8 years ago|reply