Every once in a while, the concept of a simple password manager that needs no storage and no state comes back around. The details differ but the basic premise is always the same. Instead of saving your passwords and encrypting them with a key derived from a master password, these password managers generate passwords on the fly by hashing a master password with the website name. To get your password back, you simply need to remember your master password and the exact name you used for any specific website.
It’s an intriguing technical idea but it sacrifices security and usability. I won’t touch on the security issues here as there are far more qualified people than me that have already addressed this topic. Instead I will focus on the significant usability concerns that would send any user looking for an alternative within days if not hours.
- There is no indication if you have used this password manager for a particular website. This may be considered a privacy feature, but can make migrating passwords from different managers more difficult.
- Saving multiple passwords for a single website is cumbersome. Since your only input is the website name, you have to include the username in the website name if you want to save multiple passwords for a single website. But what happens if you didn’t plan ahead and saved your first password without the user name? You now have to change the password.
- Some websites have weird password requirements. If the default password generation scheme doesn’t fit exactly, you’re out of luck. This can be solved by adding the password rules to the website name, but then you have to remember the rules and type them every time you need your password.
- You can’t change a password without changing the website name. Periodical password changes are still required by a lot of websites and even strong passwords can leak by human error. This leaves the user having to remember more than website name but the password iteration. Is it github1, github2 or github53 now?
- It is impossible to change your master password without changing all the passwords for all websites you’ve used with the password manager. The master password is directly used to create all those passwords and when it changes, all passwords must change too. To make matters worse, you don’t have a list of websites you’ve used with this password manager. This essentially means you have to remember and try multiple master passwords until you get the right one.
- Any security update or bug fix that alters the password generation algorithm will require all passwords to be changed. Standard password managers can simply rebuild their database but since there is no database here and the master password directly affects everything, all passwords must be changed.
All these issues combined mean you have to change your passwords way more often than usual, have to plan ahead a lot, and be very consistent or risk losing your passwords. It requires far more attention than I would be willing to pay just to get a cool stateless solution. At the end of the day, this solution is just not user-friendly.
kichik's blog 
Points 2 through 4 are a misrepresentation of every stateless password manager I’ve seen. Most explicitly use the username as one of the inputs to the generation function, so point 2 doesn’t happen, point 3 is partially solved by the provision of password requirement options in the manager, and point 4 is partially solved by the provision of a password increment field. Also point 6 seems radically unlikely to happen: It would be extremely negligent of the authors of such a tool to summarily change their algorithm.
Points 1, 3, and 4 are solved by a somewhat-stateful solution, which some stateless password managers do offer: storing the username, password options, etc per site.
Thanks for your input henrebotha2! I guess I didn’t say it explicitly, but even if a stateless password manager solves these by asking for the username and revision, it’s still a tougher user experience. You now have to remember four things (master password, website, user, revision) instead of one. If you save those to a state file, then you lose the advantages of a stateless password manager. If you keep the state file in plain text, you lose privacy. If you keep it encrypted with the master password, you reduce the security of your password by providing sample ciphers that can be brute forced.
As for #6, crypto gets updated all the time. Just in the past ten or so years we went from MD5 to SHA1 to SHA256, and from SSLv2 to TLSv1.3. I would argue it is negligent of authors to *not* update their algorithms over time.
Do you have a stateless password manager you recommend? I would be interested to learn how they deal with these issues.
I agree with point 6. The stateless password manager’s generated passwords serve as a verifier for the master password; if any leak, an attacker who knows you’re using a stateless password manager (Kerckhoffs’s principle says they do) can test candidate master passwords until they generate the same one you had. At that point, they can generate all your other passwords.
The defense is to make it cost an unreasonable amount of time and resources to guess the master password. Unfortunately, what is unreasonable today may not be in the future, and updating the generation algorithm is not feasible.
They can of course be used securely, but it requires memorizing a master password which is strong enough to resist guessing attacks until you no longer care about the passwords – say 100 years or so.
You mention more qualified people have touched on the security topic – any links? I’d like to see what other qualified people have said :). (My qualification: PhD candidate focused specifically on password usability and security, so I know a thing or two, but not yet everything).
Good point. It’s doable, but just too much work for anything but very committed users.
I don’t have any links on hand. I vaguely recall a lot of HN topics where people declared themselves to have the right credentials and reached similar conclusions.