Why traditional password managers are flawed | Hacker News Reader

Why traditional password managers are flawed

github.com

55 pointsw8rbt62 comments

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

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.

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

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

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.

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.

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.

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

How is your system different? If I get ahold of your master key, your entire thing is compromised.

This is true, but on the other hand the master key is never stored anywhere, so your chance of getting hold of it is reduced.

EDIT: as pointed out, no sensible system stores the master password. I do stand by the earlier 'single point of failure' point though. If you store a password vault somewhere and it goes down, or is encrypted by malware, or you lose the ability to access that storage for whatever reason you're stuck.

Isn't this true of 1Password and similar as well? My master key for 1Password isn't stored. That's what I need to enter to unlock my vault.

It's reduced but by how much? For example, 1Password uses PBKDF2 with something like 10k or 100K rounds to encrypt the local vault. If you were looking at ways that could be compromised, is it really likely that you need to worry about an attacker getting a copy and dedicating a lot of expensive hardware to brute-forcing it anywhere near as much as the attacker getting malware on your system which captures those keystrokes?

Except 1Password is also pwnd if an attacker gets mallware on your system? They just snatch the database and record keystrokes when you unlock it.

Any algorithmic pw-manager can be attacked the same way: just record the keystrokes when the master pass phrase is entered. If the attacker has malware on your system, assume all is lost.

That was exactly my point – on something other than iOS/ChromeOS there might be a chance if the attacker manages only a partial compromise[1] but in general it's wise to assume that a compromise will get the master passphrase or could simply read the unencrypted data out of the process memory and take precautions based on that worst-case scenario (e.g. using U2F everywhere it's available).

1. e.g. if the compromised process is sandboxed enough that the secure keyboard input features work or something like the macOS securityd running as a separate user prevents unrestricted access.

You're right, I was wrong. Theres no benefit from that point of view.

My system also uses PBKDF2 with 800K rounds :-)

Keystroke capture is the most scary, but I guess anything that doesn't do 2 factor is going to have trouble there.

An alphabet isn't enough to describe some [stupid] bank password requirements (I do admit the banks are really the problem here though).

Two banks I've worked with recently:

* No consecutive digits, not your initials. Numbers cant be your day, month or year of birth. * No repeating any symbol in the entire password. Cannot contain a subset of a previous key (I don't know how long the subset is to trigger this, but I do recall reusing 4 of 8 digits and seeing this).

* is assigned by the system and cannot be changed easily (stupid in itself, but exists nonetheless)

Wow, that's pretty crazy. With this setup, if you did fall foul of one of those rules, you'd have to increment the version until you no longer did.

What is the advantage of this over a traditional password manager? You need to sync a file so you can obtain the state needed to generate a password, just like a password manager. Your CSV file can be stored in a publicly accessible location without losing security, but the same is true of a password manager's database. Both are useless without the master password, and both unlock everything if the master password is compromised.

It seems to me that generating a password from a master password and some settings in a file is equivalent, both in terms of convenience and security, to decrypting a password from a master password and an encrypted password store.

I agree, there's not much in it. If you're not using proper salts there is a small advantage which is that it's usually possible to work out the settings for a site even if your sync file is lost since they will tell you the allowed characters and remembering a version number for the sites where you've changed it is not too hard especially since I show the corresponding emoji every time you log in.

I also prefer it to involving a third party service which is the other way password managers often work.

Forgot what the hash sign was otherwise known as:

https://en.wiktionary.org/wiki/octothorps

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/

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

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.

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.

    $ dpg "The sentence" word

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.

You could potentially add something like:

  HISTIGNORE='dpg *'

to e.g. your .bashrc -- not sure if the version of bash on OSX supports HISTIGNORE though (plus many other issues).

This is true but I'd be really hesitant to recommend it since the failure mode is so subtle unless you updated dpg to do something like loudly throw an error if that's not set.

Worse it puts the secret into the process table where any user with ps can read it.

The purpose of the C++ implementation is to test and validate the other implementations. Use the Python or Java versions.

I use KeePass and I'm quite happy. The database is local and enrypted with AES. My master password is around 72bits of entropy.

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.

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.

Authy can be used instread of Google authenticator and backups up an encrypted copy of your secrets.

>I've enabled 2FA on everything I can.

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.

Most of my 2FA is via Google Authenticator or Authy.

At worst enabling 2FA would make no difference but it will not make it less secure if you still need the password (might not always be the case but then it's not true 2FA).

I would argue that even if it can be beaten it will add security since that extra hurdle can stop a lot of low effort attacks.

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

> Use the same sentence everywhere. Commit it to memory.

Sounds like a master password to me

That's what I was just thinking. I really wonder what the response is to this objection.

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.

Is it just me, or would the suggested C++ usage leak the all the credentials to the history buffer?

I think you're right. Quite a big flaw.

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

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

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.

https://keepassxc.org

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.

https://addons.mozilla.org/pl/firefox/addon/password-hasher/

I don't think stateless is the answer, but I think that approaches like SPHINX is: http://webee.technion.ac.il/~hugo/sphinx.pdf

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.

"Password Safe" isn't a traditional password manager?

GUI implementation with this approach: https://bixense.com/pwcalculator/

The java version of dpg is a GUI.

My bad, sorry. I only took a look at the C++ version.

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.

why shouldn't I just continue using my 'traditional' password manager, and just enable 2FA on every site that makes it available. Hidden information and a user-action is much safer. The convenience of my password manager is far to great to give up.

Reply on news.ycombinator.com