This question already has an answer here:


The goal of a password manager is to reduce the number of passwords which one must memorize down to one, and then have all other passwords be encrypted under that master password. My solution aims to solve the same process without the use of any data storage.


First, generate a secure password. Then, conconcatenate the name of the account to the end of it and hash the result, possibly in the chain-style outlined in this answer. The final result would be my password for that account.


Using an example password "GreenPlanetAboutStudentCaughtGoodbye" and my "StackExchange" account, I would hash "GreenPlanetAboutStudentCaughtGoodbyeStackExchange", and use the result as my password.


The purpose of the hashing is to ensure that even if a website were to store my password in plaintext, only that password would be compromised. Assuming that accounts allow for all 40 characters of a SHA-256, the entropy of the passwords would be max(256, entropy of initial password).


  • Requires no encryption
  • Requires no data storage
  • Passwords can only be lost if the master password is forgotten
  • Can be used anywhere


  • Dependent on websites allowing for unlimited password length (though one could trim the hash for websites which require it)
  • Assumes all special character reqs will be met by the random password (highly likely but still a chance they won't)


Is my idea sound (reasonably secure)? Is there any critical flaw which I am missing?

marked as duplicate by forest, Community Mar 1 '18 at 4:42

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.


The idea is, broadly, secure. In fact, it's been implemented several times before. There are a few problems that any such approach (and a few more than an approach as simple as this) will run into, though. In no particular order:

  1. Multiple accounts per site. The scheme, as described, provides no way to differentiate between accounts for the same site. You'd need to stick a username in there somewhere.
  2. Password rotations (mandatory, or due to compromise). You can't change the generated password without changing the master password. While mandatory password rotations are becoming less common, they do still exist in some places.
  3. Password complexity rules. Sites tend to have a wide-ranging (and often very bad) list of complexity rules, some of which are mutually incompatible (e.g. one site insists on "special characters", another forbids anything non-alphanumeric). This tool has no way to meet constraints like that.
    • Speaking of which, how exactly do you plan to encode the hash digest? 256 bits is 32 bytes is 44 (if you keep the terminating =) base64 characters or 64 hex characters... None of these are the 40 characters you mention (are you thinking of SHA1 - a 160-bit digest - in hex encoding?)
  4. Master password can't be rotated. With normal password managers, you can change the master password (if, for example, you fear somebody may have keylogged it), and while it's a good idea to then also change all the passwords it was protecting you probably have some time to do so. With this scheme, you have to update the passwords on all your sites if you want to change the master password.
  5. Lacks brute-forcing protection. While the master password you chose is long enough to probably be safe (assuming you use something of similar entropy), most people are going to pick more predictable passwords than that. A single round of any fast hash (including all members of the SHA family) salted with nothing but a predictable string provides very little protection against brute-forcing, these days; a decent graphics card can compute billions of hashes per second (and specialized hardware can do much more than that) trying to find the original password. You need, at a minimum, to use a few thousand rounds of hashing to slow down the search; you could also use one of the newer algorithms (like scrypt or argon2) that is specifically designed for password hashing.
  6. Passwords are hard to transcribe. If you need to enter a password into anything that doesn't let you copy-paste it, you're in for a lot of very careful typing.
  7. No way to look up stored accounts. While this can be a plus in the event of your system getting compromised, it's more often a minus. If you don't know whether you have an account for some service, or don't know what the "salt" for the account is (is it "bankofamerica", "BankOfAmerica", "Bank of America", "BOA", "boa", "BofA", ...?) you might spend a while trying wrong passwords without knowing for sure.
  8. No way to store associated secrets. For example, a password manager lets you store things like multi-factor backup codes or "secret question" answers; this system doesn't support the first at all and the second only clumsily (by basically using the question itself as a site/username/salt/whatever).
  9. No support for changing cryptographic primitives or work factors. If SHA-256 gets broken and everybody is told to move to the SHA3 family, you have to change all your passwords. If in two years you want to double the number of iterations you do to account for Moore's Law, you have to change all your passwords.

Anyhow, not saying such a scheme is actually insecure (though you might want to harden the hashing function a bit, at a minimum) but it does have a lot of limitations and potential pitfalls.

  • Regarding #7, typically it's the domain of the service, so Bank of America would be www.bankofamerica.com. Sites change their actual domains rarely enough that you would remember the previous domain and would be able to change your password to match the new one if needed. As for #9, you should be using a KDF like PBKDF2, not a single SHA-256 hash. That way minor breaks of the kind we expect are harmless. You should not use "multiple rounds of hashing" as you claim in #5 as that leads to security issues. Use PBKDF2 instead (which is not as simple as "multiple rounds of hashing"). – forest Mar 1 '18 at 4:59
  • For #3, if base64 isn't sufficient, you can use uuencode, or even just use hex and append a constant suffix like @#&aA12 which won't improve security but will make the website happy. Doing some PBKDF2-SHA2 or bcrypt truncated to 128 bit output would allow for a 32 character hex password, which is not too big for most sites. – forest Mar 1 '18 at 5:02
  • Regarding #3, b85 will can contain 40 characters. – Sebastian Mar 1 '18 at 5:30

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