I'm considering moving to a password-management strategy based on supergenpass or something similar. This is an alternative to other password managers where instead of having a database of passwords encrypted on your master key, your password for any individual site is a hash of your master key + the site's domain name, e.g. if your secret key was "hunter2", your password for google would be sha-256("hunter2google.com"). As far as I can tell, the advantages over a traditional password manager are:

  • No encrypted database which has the potential to be found and decrypted
  • No risk of losing your database, as long as you know your master key and the algorithm you will always have access to all your passwords
  • No hassle with sharing your database across devices. This scheme is decentralised, and you can use it across multiple devices trivially.

And the disadvantage is that you're sharing a poorly-salted hash of your master key with every site you use this scheme to log into. But if your master key is sufficiently complex, reversing its hash is impossible, right?

Is there anything I've missed? Is there a more substantial security difference between these two password-management strategies?

  • 4
    "No encrypted database which has the potential to be found and decrypted" Decrypting that database is at least as hard as recovering the master key from an individual password with the derivation based schemes. (Due to salting it's typically even harder) Apr 12, 2014 at 12:34

1 Answer 1


As @CodesInChaos comments, an encrypted database, if done properly, will be at least as strong against brute-force attacks as a hash value. From that point of view, the hash-based method is not more secure. There are details, though, depending on the attack model:

  • With the local database of passwords, you can use random site-specific passwords. If one site is hostile, then it may learn your password for that site, but this will get him nowhere because there is no actual mathematical relationship between the master password (for database encryption) and the password you show to the sites. On the other hand, you have a local database which you must store somewhere (e.g. in your laptop computer), and if an attacker steals that storage then he can try an offline dictionary attack (i.e. brute force on your master password).

  • With the hash-based method, there is no database at all, hence the laptop theft scenario no longer threatens the confidentiality of your passwords. For that specific attack model, the hash-based method is superior. However, it also implies that each site-specific password can be used for an offline dictionary attack on the master password. So that's the trade-off: you are depriving the local thief from means to attack your master password, but you are giving such means to every site you register in.

If your master password is strong enough (say 80 bits of entropy or more; less might be sufficient is proper password hashing is used), then dictionary attacks don't work, and both methods have equivalent security (i.e. "not breakable through brute force").

If your master password is not strong enough, then I'll tend to prefer the database method, because ensuring physical security of a single laptop looks easier than ensuring that every single site I use is honest, competent, and not under hostile control.

As for usability, one may note that the hash-based method has the following issues:

  • You get only one password per target site. If the site wishes to force a password reset, and filters out attempts at reusing the same password, then you lose.

  • All sites don't have uniform requirements. In fact there is no password which could be used on every site, because length and contents requirements used in practice are not compatible. For instance, some sites mandate a minimum password size of 10 characters, while others mandate a maximum password size of 8 characters; there also are conflicting requirements on use of punctuation signs, digits,...

Both issues are easily solved by keeping track of site-specific password requirements, and possibly a site-specific counter or salt value to handle resets. But that means a "database", which voids the usability advantage of the hash-based method. That database contains only public data so it needs not be encrypted, but that's all.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .