0
$\begingroup$

I was looking into how password managers work and it seems to me that they all store the passwords (albeit encrypted).

How secure would a scheme be where the password manager always generates the password when you ask for it based on your master password and some salt that can be generated from the website name. For example something like

password=sha256("mymasterpassword"+md5("facebook"))

Trivially it seems no more vulnerable than the normal scheme, the attacker still needs to guess my master password, so what security flaw am I missing?

$\endgroup$
  • 1
    $\begingroup$ If somehow your master password revealed but the attackers cannot access your password manager, then this method can reveal all of your passwords. This is the only plausible scenario that I consider. $\endgroup$ – kelalaka Jul 30 at 17:11
  • $\begingroup$ If you're confident your master password won't ever be compromised (and you use it only on trusted machines, because a key logger can get it if you use it on a compromised box), then this would be perfectly safe. You will still need some state though, to help you ride past password changes, multiple accounts on the same service, etc, but this state is not necessarily secret. $\endgroup$ – sitaram Aug 4 at 1:45
1
$\begingroup$

Password managers with similar schemes do exist, and are called "deterministic password managers". While the idea does generally does work, this blog post names some rather big practical disadvantages, two of which I'll summarize:

  • Possibility of master passphrase compromise: If your master secret is ever compromised, all your passwords are now immediately compromised. Compare a classical, disk-based password manager: Here, an attacker would need access to the file as well as to the master passphrase.

    Also, with just access to a single password (as well its seed, i.e. which site is was used for), an attacker can start trying to crack the master passphrase by brute-force. Especially a fast hash function like SHA256 instead of a purposefully slow key derivation function like Argon2 or PBKDF means that your master passphrase better be really good - so it would be advisable to use a randomly generated cryptographic key instead of a human-generated password*. This key would need to be stored somewhere, defeating the whole point of the scheme.

  • Without stored state, you loose some very important functionality: Once generated, it's now impossible to change a password, without memorizing a changed seed. For example, if your facebook password got compromised, you'd now have to remember typing in "facebook1" instead of "facebook". This is bad, because it discourages users from changing passwords they suspect might have been compromised.

    Additionally, password requirements differ from site to site. Some might require special characters, some might forbid them altogether. To accommodate this, you'll also have to remember the exact password generator settings for each website.

In conclusion, your idea is probably sound from a cryptographic standpoint, but only as long as the master passphrase contains enough entropy (that amount being substantially higher than for online-brute-force-only attack scenarios). But in the real world, there are a lot of security and usability considerations making it generally not very practical, compared to a normal password manager.

* Of course, one could generate a rather long random passphrase that is both high-entropy and human-readable. But it might very well exceed your expectations for what is a reasonable length for a password.

| improve this answer | |
$\endgroup$
  • $\begingroup$ I think the "facebook" is stored by the password manager. $\endgroup$ – kelalaka Jul 30 at 20:22
  • 1
    $\begingroup$ The whole point of a deterministic password management scheme is to try not to store any state. Once you're storing state (and trusting cryptography) you may as well just store state (passwords) and trust cryptography (encryption). $\endgroup$ – SAI Peregrinus Jul 30 at 21:26
  • $\begingroup$ I think the stored state problem is over-blown. The state we're storing in these situations is not secret information. For example see the sitelist file in github.com/sitaramc/hap2#normal-usage-with-a-sitelist-file $\endgroup$ – sitaram Aug 4 at 1:42
  • $\begingroup$ @sitaram With a normal password manager, you're not storing "secret information" either, you're storing encrypted passwords. The only difference is which piece of crypto you trust. $\endgroup$ – ManfP Aug 4 at 11:11
  • $\begingroup$ @ManfP OK, I'll change "secret information" to "needs-to-be-kept-secret information" to make it clearer. The site-specific info (typically just a sequence number) need not be secret -- it is similar to a counter in CTR mode block encryption so it is just as safe. Or "useless" to an attacker. The passwords you are encrypting are much more useful if (somehow, maybe software bug -- accidental or "supply chain attack") the outer password is cracked. $\endgroup$ – sitaram Aug 8 at 5:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.