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.
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.)
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.
To answer your question on variation; you should have completely different passwords. I know this may seem tedious to remember but consider using a password safe to contain all of your individual passwords and simply remember your (ever changing) master password.
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.
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.
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.
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).
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.
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):
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 )
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/ :
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.
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)
hum@n.gm@1l.@!@%%%!@!@ (gmail password)
hum@n.tw1tt3r.@!@%%%!@!@ (bank password)
This allows me to always maintain strong passwords, always remember them. Mind you, there is a threat that someone can figure out the structure via say keystroke logging, inference, it is still very strong in its design, easier to remember than generated nonsense. I fiddle along a structure like this and the way I see it, if anyone is attacking this methodology, then they are a highly strong adversary.
----- ADDED NOTE (edited)
Brute forcing most of my passwords don't work using oclhashcat, or John. Most are too long and would take months. I make it a point to change my password structure once every three months. Again, your mileage may vary, and I can see the responses/comments now: "All I need to do is figure out one thing" To which I respond: "if someone can figure out any of my passwords, a strong adversary they are. They DESERVE to break it"
