28

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.

46

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).
| improve this answer | |
  • 1
    I noticed your suggestion of using bcrypt was unanswered, so I've added some thoughts on that. – Esa Jokinen Apr 29 at 8:02
  • 1
    Thank you Esa, I have marked your answer as the accepted answer to my question. I think it covers the original intent (much) better than the other one, despite the votes. Also, things became a bit messy here, I'll try to focus my questions a bit better in the future! – Elling Apr 29 at 8:16
  • 1
    Converting hexadecimal to base64 is fairly straightforward. – Taemyr Apr 29 at 10:32
  • 2
    @Taemyr: Yes it is, as well as Ascii85, Base96, multiple stacked hashing algorithms, rot13 etc., but we can't cover all the possible combinations on a single answer, can we? This is intentionally limited to the suggestions OP originally had, and already it has swelled up this much. – Esa Jokinen Apr 29 at 10:57
  • 1
    Yes it is. Password managers hides this information by replacing it with asterisks, so even if someone sees you copying a password, he doesn't see the actual password. – Esa Jokinen Apr 30 at 9:44
42

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.

| improve this answer | |
  • 11
    > But if you have a compromise on the client-side, this does no good This point is mute -- that argument can be applied to any sort of password manager – Feek Apr 29 at 5:05
  • 3
    Even with the edit (or rather because of it), this won't survive Kerckhoffs's principle: if your text file and the procedure was public, it would reduce your password to the original my_p4SSWord!, and once that's brute-forced against a single hash, all your passwords are known. – Esa Jokinen Apr 29 at 8:08
  • 3
    @Elling it's not about breaking the hash. It's about brute forcing your password: I guess a password, hash it with the known algorithm and send it to the corresponding service. If I log in, I know I guessed the correct password and can then produce the hashes for all of your services. – Tim Pohlmann Apr 29 at 12:36
  • 1
    @TimPohlmann If the login succeeds, I only know I guessed a password that for this site produced the same initial 12 characters of the hash as the correct one, don't I? – DonHolgo Apr 29 at 13:53
  • 3
    @Elling If you manage all your passwords like this, we are talking about a lot of services. One of them not having brute force prevention is enough. The more common (afaik) attack vector however is a leaked db: The attacker gets access to the actual hash value and can now run the brute force attack locally on his own computer. – Tim Pohlmann Apr 29 at 14:18
7

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

| improve this answer | |
  • I assume the OP's reason for truncating is to shorten the resulting password to comply with many sites which limit the size (which sadly still happens fairly frequently). – Jon Bentley Apr 30 at 9:40
  • @JonBentley But 12 characters? Apart from banking sites (where the limit is sometimes even less), in my experience the length limit is usually much more reasonable than 12 characters (I would expect more problems with character type restrictions). – tim Apr 30 at 9:42
  • Thanks tim! Your answer mimics my own reasoning, and you're correct that my main purpose is to avoid cross contamination between sites if one of my passwords gets stolen. I conclude that if I make my input seed a little bit stronger, strong enough to make brute forcing into a week or month long affair, even for a state sponsored enemy, then my scheme might be OK even with SHA512. – Elling Apr 30 at 9:50
  • I do get however, that I risk everything being compromised if my master key is somehow found out through more traditional methods, but that's no different than my situation was before I adopted this scheme, when I was simply re-using my plaintext passwords more or less indiscriminately between different services. – Elling Apr 30 at 9:51
  • @JonBentley That's correct, Jon. I truncate for that reason, and also to keep things uniform, and short enough so that I can remember one or two hashed passwords if I need to. – Elling Apr 30 at 9:55
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.

| improve this answer | |
  • Good write-up. One comment: you can approximately safely share the generated password for a single site, although it will be difficult for your counterparts to remember. Sharing groups of passwords becomes complicated as you describe. – Stobor May 1 at 4:47
  • Hi @Scwhern. Thanks a lot for a very comprehensive comment. I'm an amateur, so these are valuable insights, even if I do not agree 100% with all of them. I have only 20-25 online accounts, and my scheme works fine with those, but I understand that I might run into trouble if I try to do something even more complex with it. – Elling May 1 at 8:57
  • Also, like I said, I do keep a small text file on the side. I treat it as a sort of a note that I can keep in my wallet. If it gets stolen, my passwords are not compromised. It contains things such as the exact spelling of the service names. It could also, potentially, contain text like "these new passwords use hashing algorithm B and not hashing algorithm A". It complicates things, of course, but it wouldn't ruin everything. – Elling May 1 at 8:58
  • My goal is to have a scheme that's as independent as possible. Just a common hashing algorithm, and a simple text file that I can duplicate everywhere if I want to. I don't want this text file to be large or complex, but it can be. I'm willing to sacrifice some usability for the sake of 'owning my own scheme'. That's the gist of it. – Elling May 1 at 8:58
  • 1
    @Elling If you say so, you're the expert! ;) – Schwern May 3 at 19:15

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