How different should my passwords be? [duplicate]

Suppose I use remember one long high entropy master password, and use variations of it for each of my passwords.

Eg if I remember tSaF4nWeACVkUU4 as a master password and use tSaF4nWeACVkUU4t (with a t and the end) as my Twitter password and tSaF4nWeACVkUU4g (with a g at the end) as my Google password.

Is this bad practice if so how much variation should I put in different passwords.

• and `tSaF4nWeACVkUU4` has been added to a wordlist somewhere. – Matthew Peters Nov 6 '14 at 15:29
• Exactly the same question, over 1 year ago: security.stackexchange.com/q/39300 (I know because it's mine). – Francisco Presencia Nov 6 '14 at 22:50
• While this question is technically a duplicated, consider accepting an answer as this helps future researchers :) – Matthew Peters Nov 6 '15 at 12:42

You use distinct passwords on distinct systems because you know that some of these passwords may leak. If your passwords are high enough in entropy then they won't leak through brute force, but they may still leak through some other ways, e.g. server compromise (grabs the passwords as they come by), key loggers (grabs the password as it is typed),... Using distinct passwords is a damage containment feature. To keep server compromises local that server.

If the password for site B can be easily inferred from the password for site A, as in the method you suggest, then you fail at the damage containment. That the password starts with high entropy has no influence whatsoever on that statement. High entropy is about avoiding a breach through brute force (aka "dictionary attack"). However, once another kind of breach has happened, entropy is no longer relevant. Entropy is a measure of what the attacker does not know. If the attacker could grab your password then he knows all of it and there is no entropy any longer. We are past that step.

For damage containment to work, knowledge of your password for site A must yield no information whatsoever about your password for site B -- which means that both passwords must be generated randomly and independently of each other. Notably, while this means that you should not do some "password derivation" as the one you propose, you should not either reject candidate passwords for site B because they would be "not different enough" from the password on site A: such a rejection rule would also help an attacker narrow his brute force efforts.

(Cryptography-powered password derivation from a root password may be applicable, but these things are subtle and, in any case, you won't be able to run it in your head, which voids the usability advantage of having a simple derivation rule.)

• "If the password for site B can be easily inferred from the password for site A, as in the method you suggest, then you fail at the damage containment." But can it? What are the odds that anyone will guess that such a scheme is in use, never mind what the scheme is? Granted, I can see how it's safer not to take the chance at all. – Lightness Races in Orbit Nov 6 '14 at 18:49
• "If the password for site B can be easily inferred from the password for site A, as in the method you suggest, then you fail at the damage containment." Downright wrong, it doesn't fail at damage containment, but merely is less effective at it. – David Mulder Nov 6 '14 at 19:05
• @DavidMulder Tom's answer is correct. This method is so ineffective at damage containment that utter failure is a correct way of describing it. Once a password on one site is known, the passwords on other sites are known. – Gilles 'SO- stop being evil' Nov 6 '14 at 20:41
• @LightnessRacesinOrbit The odds are pretty good. People who write password crackers are intelligent (at least some of them are, which is enough to warrant protecting against intelligent password crackers). Trying variations on known passwords is routine for password crackers. – Gilles 'SO- stop being evil' Nov 6 '14 at 20:42
• @Gilles: Alright then – Lightness Races in Orbit Nov 6 '14 at 20:57

In a perfect world, sure that would be a wonderful method for a human to remember their passwords. However, the world is far from perfect.

The main issue with your method is that if just one of your passwords is ever discovered (through leakages, guesses, breaches, etc) then your entire security apparatus could unravel -because patterns are trivial to detect.

• In perfect world, no password. ;) – Andrew Hoffman Nov 6 '14 at 16:55

This provides almost no additional security over using the same password everywhere. The entire point of using multiple passwords is to prevent a leak of one from compromising multiple accounts.

If I get your password to twitter, the first thing I'm going to do trying to hack you on Google is going to be to try permutations of your twitter password. It isn't going to take long to figure out that replacing t with g makes it work, in fact, it would probably be the first thing I tried before trying random permutations.

If you really want security, each password should be completely unique and unrelated to your other passwords. Alternately, you can go to the opposite extreme and setup as much as you can under oAuth. This ties everything to the same credentials, but also only offers one service that can be compromised to gain your password and also offers only one place to need to change them as soon as the compromise is detected. It still isn't quite as secure as having a bunch of completely unique passwords, but it is a heck of a lot more usable.

My suggestion is, "don't." The scheme you've suggested is vulnerable to brute force attacks.

Instead, use a password database application that is ported to the devices you use, and can both generate complex passwords and auto-fill them for you.

• Depends on how his password is chosen as a target. If a DB is compromised that used good security practices for hashing the passwords, and his is just one of many upon which a crack is being attempted, this password scheme has more safety than most of them. If the compromised DB used poor security practices and his password is thus discovered, and someone decides to pick him out of a hat and try his password and variations at other sites, he is now vulnerable to brute forcing because of password similarity. – Jason Nov 6 '14 at 18:13
• A secure password hashing scheme (e.g., Password-Based Key Derivation) cannot be broken in a reasonable amount of time. Unless, of course, one has access to the algorithm specifics. A common weakness of password databases is to encrypt the passwords with a seemingly secure algorithm (AES256 or better). At which point, a rainbow table can be generated even in the absence of the encryption key. – W1T3H4T Dec 19 '14 at 23:48

As I disagree with the conclusion of most answers here I am going to break this problem down in a slightly different way. Let's consider a couple of breaches and examine what the effect of such a password scheme would be, however I am going to make one little change to your scheme (as your current scheme is simply too simple):

Eg if I remember tSaF4nWeACVkUU4 as a master password and use tSaF4nWeAtCVkUU4 (with a t in the middle) as my Twitter password and tSaF4nWeAgCVkUU4 (with a g in the middle) as my Google password.

Database hack

The user database is hacked and hashed password are compromised. The password has a high entropy, thus it will not be broken through brute force. Attacking other sites using this knowledge is also impossible.

Site hack

The plaintext version of the password is compromised. It now becomes possible to do a simple bruteforce with around 3 to 10 attempts realistically on another site before you're locked out. Using the proposed scheme this will quite definitely hold up even under relatively close scrutiny. I have recently been observing how many sites actually use time outs and account locks and it turns out that a lot of sites have neither. Without basic protections like that an attacker will be in the same situation as described below with a single plain text password and multiple hashed ones (though the rate of trying passwords against the hash is significantly lower through a web service).

Multiple site hacks

Now, this scheme only becomes seriously weak once an attacker is able to attack a number of different sites and then do a targeted attack against you. In this case he can explicitly look for differences in the password and thus figure out your scheme. A similar thing is possible if one of the hacks is merely a database hack, as he can then search for permutations first in a brute force attack against the hash... which in turn will likely lead to the discovery of your scheme.

Conclusion

In conclusion I think using a well designed scheme that requires at least 3 different password instances to be compromised is sufficient for a lot of uses. Only in case you're expecting an incredibly targeted attack will this start to become an issue. Of course, using completely different passwords is definitely safer, using completely different passwords and a password managers is slightly safer (depending on the password manager and the way you use it), but this has distinct advantages over having a password manager without mostly all pitfalls of having a fixed number of different passwords.

And to all of you who claim this is so simple, have a go at it (and this is even an extremely simple version with just two variables):

• Plain text compromised password: Hsx3e8oHSTBT
Site: PayPal
Domain: paypal.com
Company: Ebay
Category: Finance
Importance: High
• Compromised hash: ab3ba457824c61f052d8cd5e777e518e6cd2ee63
Site: Gmail
Domain: gmail.com
Category: Mail?
Importance: High?
Category: Social
Importance: Medium

Now mind you, the above should be doable, after all, you just were able to hack three different sites and the scheme isn't that complex, but if you only have the first two you won't figure out the third in time before Twitter blocks you. If you have the first and the third you might figure out the second though, but that's why I still called this version weak. Either way, with all this information you know a million times more than any hacker would ever know... so as much as you guys are attacking this approach this should be a walk in the park.

Either way, the answer is Hsx3e8(first letter - 1)[HS](if high security)TBT , now imagine mixing in categories or more complex letter schemes or anything else you like. For example, instead of the above three have a look at the plain text versions: GOpwYjbm2vX, GOp24WYjBmvX, gOpWY12jbmvY (that's even more complex than my own scheme though :P )

• Entropy is a property of a password generation process, not of a password. This password generation process you're proposing has not high entropy as you claim, but in fact almost no entropy at all. – Xander Nov 6 '14 at 19:48
• @Xander: Absolutely wrong, information entropy says something about the amount of 'information' a 'message' contains. Yes, knowing all variations one could argue that as a whole the entropy is lower than on it's own, but even so, on it's own is what we're talking about. It has nothing nothing to do with the 'password generation process'. – David Mulder Nov 6 '14 at 19:54
• This is a weak system because it violates Kerckhoffs's principle which says when the algorithm is known, the system should remain strong. This is not the case here, because the algorithm is extremely insecure. It combines a bunch of static data with a tiny amount of deterministic data. Whereas a random password must be brute forced even if the algorithm is known, if your suggested algorithm is known, it would take an average of approximately 1 attempt to guess any password generated this way. This is pure security through obscurity. – Xander Nov 6 '14 at 20:39
• @Xander, which is why we should always assume our algorithm of creating passwords is known. – Matthew Peters Nov 6 '14 at 21:22

As other comments says, the main problem is the too close structure between different password.

A better solution would be to apply a hashing method to this "password + change" so that the result cant give back your main password.

That's the basic principle of http://passwordmaker.org/ :

• You have a master password you only use to generate password (you never write it elsewhere), it must be a real tough password with lots of entropy and symbols (not only letters and numbers). Hard to remember, but you only have one like this to remember.
• You have several salt systems: url of the website, login name, etc.
• You choose the hashing algorithm to use.
• You choose the number of character the generated password will have.
• You choose the set of character to use for your password (some website do not allow specials characters).

The result is a random looking password that cannot give back you main password as there is too many salts to it.

The main drawback to this method is that it is very vulnerable to keyloggers if they record the whole sequence and that you use similar sequence for all your passwords (with only the website url changing).

As example, I'll keep the main password given: tSaF4nWeACVkUU4 (which I do not like as no special characters).

Then I write that is for use with "test.com" website, hashed with "HMA-SHA-256", with user name "test", with modifier "test", and a length of "10". Any change of one of these parameter will generate a completely new password (except for the length that only add or remove characters).

All this give me a new password: "FBaJZ+:1@N" that do not tell much about he main password.

If you do not have exactly all the same parameters, the hash algorithm should prevent to recover the missing ones.

I'm not a cryptographic expert, I may have misunderstood some aspects and I can make mistakes. All this message is what I understand, so not necessary truth.

• if you are using a non-reversible hash function, why not just create completely new random passwords (which is essentially what you are doing with the hash just not in a random way). `random looking` is no substitute. – Matthew Peters Nov 6 '14 at 21:27
• This in in the idea of having only one password to remember. It is an alternative to password bank and it is portable (you can access the html version from anywhere). I don't say it is cryptographically better than new real random passwords, just that this is a real improvement over the method of user288447 – Togh Nov 6 '14 at 21:34
• First, make sure you review hash functions and cryptographic hash functions next, consider that if your method is not `cryptographically better` as you say (which it isnt), then why even bother. The fact is, even if you replace @user288447's t (for twitter) with a super secure password the concept would still be fundamentally flawed because it implements a pattern. see here – Matthew Peters Nov 6 '14 at 22:09
• Maybe I did not describe clearly enough the way passwordmaker.org works. It may be better you to read the author's explanations (just follow the link) than give me some tips to correct my answer so it would be more understandable. – Togh Nov 6 '14 at 22:33

Here is a framework I use (YMMV) that is based on the typical CISSP approach to passwords (something you know, something you are, something you have). I break my password structure down into these three topics with character substitution. Currently I never re-use password, my typical password is about 20 characters, and I can always recall them:

Substitutions: (very common)

``````s = \$
e = 3
o = 0
a = @
i = 1
``````

Something I am: (example)

``````human = hum@n
``````

Something I have: (example I am logging into my gmail account)

``````gmail - gm@1l
``````

Something I know

``````mytelephone_number_with_shift_key = @!@%%%!@!@
``````

My password for gmail might be:

``````hum@n.gm@1l.@!@%%%!@!@
``````

To where I can retain the something I know, something I am and change the something I have:

Something I have: (now logging into my bank)

``````bank = b@nk
``````

This would be a breakdown:

``````hum@n.b@nk.@!@%%%!@!@ (bank password)