Why traditional password managers are flawed

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

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

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

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.

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.