Stateless Password Manager Usability

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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?
  5. 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.
  6. 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.

2 thoughts on “Stateless Password Manager Usability

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

Leave a Reply to henrebotha2 Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.