How secure is this hash-based personal password scheme? [duplicate]

Question

I use a password scheme where I keep a small number of easy to remember personal passwords. Instead of using the passwords directly for each service, I run them through a hashing algorithm first, as a sort of a seed, together with the name of the actual service. I then use the resulting hash as my actual password for the service. (There's some more to it, I add some extra fixed letters to satisfy some normal password requirements, but let's look away from that in this question.)

The pattern looks like this (using SHA512, and keeping just the 12 first characters of the resulting hash):

"my_p4SSWord!"      
      +             =>        SHA512        =>   "d4679b768229" 
  "Facebook"

"my_p4SSWord!"      
      +             =>        SHA512        =>   "182c5c2d4a2c" 
  "LinkedIn"

The pattern allows me, not to remember all of my online passwords, but to remember how to easily re-create them, whenever I need to.

There are lots of online services for calculating hashes, and I currently use this one (which is javascript only, and thus purely client-side):

https://emn178.github.io/online-tools/sha512.html

My question to the security experts is, how secure is this personal scheme of mine really? I truncate the hashes to just 12 characters. How does that affect the real crackability of my passwords? Also, I use SHA512. How does it affect my scheme, as a contrast to using for instance bcrypt?

Any comments?

edit: I'm getting some knee jerk reactions here, for which I'm thankful. I'll just make a few quick comments before this probably gets closed off.

I was asking particularly about the cryptographical properties of the hashes that I'm using, and the increased likelyhood of a successful brute force attack against them as a result of the truncation that I'm doing.

Also, a lot of people mention usability. The thing to remember, is that most passwords you don't actually have to type in, the exception being maybe the password to your OS. In my case, I just remember the hashed password to my OS, and that's it. For the rest, it's just a minor inconvenience each time I have to look up and re-generate the hash. It's quick, and the tools are standardized and available everywhere.

Also, there are simple rules that you can have for cases where you do need to change the password for a particular site. Rules that you can just as easily remember, and that you don't have to write down.

Finally, I mean this mostly as an alternative to doing nothing at all, which, after all, is what most people are doing when they reuse the same passwords indiscriminately across all the online services that they subscribe to!

Finally-finally, be kind!

edit2: There's a lot of focus on the method in the answers, and not on the cryptographic properties of the hashes, which is what I intended in the original question.

Since there's focus on the method, I'll add just one extra piece of information, which is that I do keep a small text file on the side. The text file is, as far as I can tell, in accordance with Kerckhoffs's principle, it reveals things, but not the keys. Which is why my original question is focused on the cryptographic properties of the hashes, and their strength.

Answer 1

SHA-512

PROS:

• Due to the avalanche effect, every single modification to the suffix will change the SHA512 sum entirely. This means that from one N first letters of one hash you can't say anything about the N first letters of another hash, making your passwords quite independent.
• SHA512 is a one-way compression function, so you can't deduce the password from the hash; you could try brute-force passwords that will give the same SHA512 sum. As you only use part of the hash, there's more chances to find more than one password that will match.

CONS:

• You think you have a strong password as it is 12 characters long and contains both letters and numbers, but it actually has a very limited character set of 0-9 + a-f (it's a hexadecimal number). This gives only 16^12 i.e. log2(16^12)=48 bits of entropy, which is less than 10 characters of a-z+0-9 and close to 8 characters of a-z+A-Z+0-9.
• Online services could save the hashes you create. Use a local tool for the hashing, instead.
• It's possible you can't recall your seed in all cases, which may lead you to lose your password.
  • What happens if you want or are required to change a password? Does the seed become my_p4SSWord!Sitename2 or something else? How you keep track of the count?
  • The site/service name is not always unambiguous. Was your Gmail password suffix Google or Gmail or did you first use YouTube? Was your Microsoft account Microsoft or Live or Office365?
  • Combinations of these makes things even uglier.
• If the site has password complexity requirements, you'd had to add characters and/or convert some of the characters uppercase manually after the hashing. How to keep track of these modifications?
• Someone could still find out your procedure e.g. by seeing you create/use a single password. That would compromise all your passwords at once.

bcrypt

While bcrypt would

• give more entropy usings Radix-64 encoding with 64 characters;
  ASCII 32 (space) through 95 _
  ( !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_)
• be slower to calculate
• use a user defined iteration count you could utilize to make it as slow as you wish

...it's incompatible with your current procedure, as it has incorporated salting and would give you a different hash every time:

$ htpasswd -nbBC 12 Elling my_p4SSWord\!Sitename

Elling:$2y$12$jTkZQqYzWueA5EwKU1lLT.jbLLXUX.7BemHol.Q4SXhoJyeCVhcri
Elling:$2y$12$c1lDwR3W3e7xlt6P0yCe/OzmZ.ocKct3A6Fmpl8FynfA.fDS16bAa
Elling:$2y$12$eAciSW6iGxw/RJ7foywZgeAb0OcnH9a.2IOPglGGk.wL9RkEl/Gwm
Elling:$2y$12$EU/UDJaZYvBy6Weze..6RuwIjc4lOHYL5BZa4RoD9P77qwZljUp22

...unless you exclusively specify a static salt (possible on some implementations like PyPI bcrypt).

Password managers

All the cons are solved in a password manager creating passwords that are

• random
• completely unrelated
• can have different requirements (different character sets and minimum/maximum lengths).

Answer 2

From a usability standpoint, it's awful. You need to generate a hash each time you want to log in. Even using a password manager to look up truly random strings would be less work.

From a security perspective, you have combined the problems of hashing client-side and using a password pattern:

1. Yes, using a password hash on the client-side means that your plaintext password is protected from function weaknesses on the server-side. But if you have a compromise on the client-side, this does no good.

2. It does not survive Kerckhoffs's principle. If an attacker knows that this is your process, then your password for any given service is only my_p4SSWord!. Once I know that, I can log into every one of your accounts. Re-using the pattern exposes all your passwords once one is known.

Answer 3

One of the main purposes of your scheme is to prevent access to all of your accounts if one password is compromised. While it's better than simple password reuse, it is still easily bypassed by an attacker and imho doesn't add enough value to justify the added complexity.

As you mention that you want to focus on the cryptographic properties:

sha512 is an awfully quick function and not suitible as a cryptographic hash function for password storage.

Truncating the hash has no relevance when trying to gain your key from a leaked password[*]. It increases collisions, but an attacker would want the correct key (my_p4SSWord!), not just any input that produces the hash.

So if we assume that your approach is known to an attacker[**], and that they were able to compromise a plaintext password on just one website[***], they can now likely crack sha512([key_guess]compromisedwebsite) in a reasonable amount of time and gain access to all your accounts on other websites.

the tool I was linking to is JavaScript only, and thus client-side only

Have you verified this? Do you verify every time that no changes have been made (either by the owner, or because the site or one of the JS dependencies have been compromised)?

Personally, if you need a third-party dependency for your password scheme anyways, I would rather trust an online password manager (or it it's feasible usability-wise, an offline password manager) which was specifically designed to keep passwords secure.

_{[*] it does have relevance when an attacker only has access to a hashed version of the password and needs to crack that first, so I would skip the truncating as it seems unnecessary.}

_{[**] Which it now is :)}

_{[***] Maybe they set up a fake website you registered on, maybe you registered on a site that stores/logs/sends passwords in plaintext, maybe the attacker has an RCE on a site you registered and logs all passwords as they are entered}

Answer 4

The comments have ping-ponged around making it difficult to see the whole. Rather than play whack-a-mole, here is a summary.

First, let's remember that any password scheme must improve on best practice. Best practice is to use a good password manager with a good password generator.

Let's also remember that security is only as strong as its weakest link. It doesn't matter how awesome your door is if I can go in through the window. Any single weakness invalidates the whole scheme. All weaknesses must be addressed.

Finally, a system's security is evaluated not as an ideal, but how it's actually used. The OP's question presented an ideal, but over the course of comments and edits we find that it's used rather differently in practice.

Passwords are only as strong as the key, and every password exposes the key to attack.

The main flaws in this system are that every password exposes the key to attack, and the strength of all passwords rests on how hard it is to brute force the key.

To brute force the key, one needs the a password, the salt, the prefix, and the process.

You do not control the security of your passwords, one must assume they will leak. The salt is, by design, easy to guess. The prefix can be discovered by comparing multiple passwords. Kerckhoffs's principle says we must assume the process is exposed.

The choice of an inappropriate hash algorithm makes brute forcing easier than it should be. And, as we'll see, once you start making passwords this is increasingly laborious to fix. Similarly, the key cannot change; you're stuck with an increasingly weak key.

Password managers have none of these flaws.

Ideal vs Practice

The ideal version of this scheme makes these claims about its usability.

1. One only needs to remember the key.
2. It's stateless, nothing needs to be written down.
3. The process of choosing a salt is simple and easily remembered.
4. No 3rd party needs to be trusted.
5. It can handle "all of my online passwords".

These don't hold up in practice.

1. One needs to remember two things, the key and the prefix(es).
2. Salts and prefixes are written down because...
3. Corner cases mean salting is complex and multiple prefixes are required.
4. One can chose to trust insecure services with the key, prefix, and passwords.
5. It cannot handle all online passwords without compromising security and usability.

In contrast, a good password manager...

1. Only requires remembering the master password.
2. Has state, but it's all encrypted.
3. Has no algorithms to remember.
4. Is audited by professionals.
5. Can handle all secrets.

Too many important decisions must be made by the user.

The user must choose a hash algorithm, hash method, key, prefix, and salt procedure. All of these have an impact on usability and security. None of these should be made by the user.

For example, the OP chose an inappropriate hash algorithm making brute forcing the key easier. They used an untrusted site to do the hashing exposing everything. Their salt process is insufficient to cover all cases requiring some service names to be written down degrading usability. The chosen prefix may be inadequate to cover all password requirements.

The scheme can be improved by having professionals recommend choices for the user, but the user can still ignore them.

A good password manager has none of these flaws. The entire process is created by professionals, constantly reviewed and improved, and handled by the software.

Poor choices cannot be fixed.

In this scheme, a password relies on four pieces.

• The key
• The prefix
• The salt process
• The hash algorithm

Change any one of these and all passwords must change. This makes the system very brittle and has many consequences for security and usability.

Needless to say, a good password manager has none of these flaws.

For the remainder, for brevity, when I say "it cannot change" please read "it cannot change without changing all passwords". And if change is difficult, the user is likely to make compromises with their security.

The hash algorithm cannot be changed.

It's important to be able to change your hash algorithm should a weakness be exposed. A good system would be able to quietly swap in a better algorithm for passwords going forward.

SHA-512 is an inappropriate choice making it easier to brute force the already over-exposed key.

A password manager takes care of this for you.

The key will be increasingly compromised.

While mandatory password rotation has gone out of vogue, it remains a security cornerstone that you need be able to change your keys upon any suspicion of being compromised. The simpler the process the more likely you are to use a fresh key at any hint of a vulnerability.

If you chose a weak key, you cannot chose a better one. As computing power becomes stronger, you'll need a stronger key.

With a password manager, you can change your master password as often as you like.

The salting procedure will be inadequate.

To avoid writing salts down, the procedure to get a salt for a service must be flexible enough to accommodate all situations, yet simple enough to remember and be done in your head.

It's likely the user will pick a simple scheme and find it increasingly inadequate. Here's a few corner cases...

• Is github.com "Github" or "GitHub?
• If foo.com is "Foo" what is foo.us?
• How do you store foo.github.io?
• Will you realize that foo.io used to be foo.github.io?

The procedure cannot predict all situations, or it is so complex it cannot be reliably done in your head. The inevitable result is some service names must be written down decreasing usability and security.

The salting procedure may also drift over time as it's subtly changed to accommodate more edge cases. It may become incompatible with older passwords.

A password manager needs no such procedure.

One prefix does not fit all.

While password policies are finally going away, they're still around, and they're often nonsensical and contradictory. With this scheme one must, up front, choose a prefix which will cover all possible cases. This unlikely and perhaps impossible.

Edge cases require a special prefix just for one site, requiring them to be written down, decreasing usability and security.

A good password generator can accommodate most policies. If not, you can manually alter the generated password.

It cannot be safely shared.

Let's say, I want to have a shared set of passwords. Maybe for work or a project or with family.

With a good password manager I can create tertiary keys, hand them out, and, most importantly, revoke them. The vault can be made available either via the cloud or simply copying it. I can create shared vaults and choose which passwords are shared.

With this scheme, one must share the key, prefix, hash algorithm, and explain the salting procedure. The receipients must be willing to jump through all these hoops exclusive to this system. None of this can be revoked. All passwords are exposed, including future passwords. If one person compromises the key or prefix, everything is compromised. If you want to share only specific passwords you need to come up with and remember a new key and prefix and remember which passwords were generated with which key and prefix.

Difficult to backup.

One could store the key and prefix(es) and special salts and hash algorithm in a safe location. But one also has to write down an accurate description of the increasingly complex salting procedure. Anyone who reads documentation knows how difficult that is.

With a good password manager, one stores the vault key in a safe location and backs up the vault. Since the vault is encrypted it can be backed up anywhere.

How secure is this hash-based personal password scheme?

It's more secure than reusing a few easy to remember passwords. Compared to a good password manager and randomly generated passwords it's much harder to use, less featureful, and much less secure.

If you're allergic to commercial software, use open source. If you don't trust cloud storage, store the vault locally. If you want it available anywhere, store the vault and software on a thumb drive on your key ring.