5 ms·

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

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.
jorvi 9y ago
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.
kybernetikos 9y ago
I use a system that I wrote https://github.com/kybernetikos/sinkless 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.
- bengillies 9y ago
  If you store settings related to password system requirements on a per site basis then you're leaking the existence of your account on that site, which often needs to be private itself.
  - kybernetikos 9y ago
    You're right. If you're worried about that, then you will need to treat that data as not entirely public. The point is just that the secrecy requirements can be much less than you'd have for keeping a password.
- 9y ago
Theodores 9y ago
Forgot what the hash sign was otherwise known as: https://en.wiktionary.org/wiki/octothorps https://en.wiktionary.org/wiki/octothorps
- majewsky 9y ago
  There's an episode of 99% Invisible that chronicles the history of this character and its various names and uses: http://99percentinvisible.org/episode/octothorpe/ http://99percentinvisible.org/episode/octothorpe/
majewsky 9y ago
I use a similar stateless password manager than the one where the submission originates from: https://github.com/majewsky/pwget https://github.com/majewsky/pwget 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.
jclardy 9y ago
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.
hobarrera 9y ago
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.

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.

jorvi 9y ago

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.

kybernetikos 9y ago

I use a system that I wrote https://github.com/kybernetikos/sinkless 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.

bengillies 9y ago
If you store settings related to password system requirements on a per site basis then you're leaking the existence of your account on that site, which often needs to be private itself.
- kybernetikos 9y ago
  You're right. If you're worried about that, then you will need to treat that data as not entirely public. The point is just that the secrecy requirements can be much less than you'd have for keeping a password.
9y ago

Theodores 9y ago

Forgot what the hash sign was otherwise known as: https://en.wiktionary.org/wiki/octothorps https://en.wiktionary.org/wiki/octothorps

majewsky 9y ago
There's an episode of 99% Invisible that chronicles the history of this character and its various names and uses: http://99percentinvisible.org/episode/octothorpe/ http://99percentinvisible.org/episode/octothorpe/

majewsky 9y ago

I use a similar stateless password manager than the one where the submission originates from: https://github.com/majewsky/pwget https://github.com/majewsky/pwget 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.

jclardy 9y ago

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.

hobarrera 9y ago

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.