Lets say I create 100 separate passwords, consisting of around eight random characters followed by two constant ones that are the same for all passwords:

``````Generated password = 8 random characters + `.p`
``````

If I do this for all 100 passwords, does adding the same `.p` for every password make them more or less secure? How much of an impact would it have if two of all those passwords were compromised?

• Isn't this basically salting your password in a small scale? I know I'm working backwards from this assumption, but Anders' answer to this question seem similar to those for other questions about using the same salt for all passwords: here and here. Commented Apr 3, 2018 at 14:47
• "[question is if] adding the extra two digits actually made a password less secure overall". Sure, it's less secure than 10 random digits (in a targeted attack), but more secure than 8 random digits - so if you're memorising passwords and can only memorise 8 digits comfortably, then there's nothing wrong with this. Commented Apr 3, 2018 at 15:19
• It's only harmful if you're doing it excessively. I use 4-5 word Diceware passwords for my banking. I typically capitalize the first letter and add an '1!' to the end. Because the strength of my password isn't based on those characters, it doesn't matter. If my password was 1 upper case, 1 lowercase, 1 number, and then 37 '#' symbols, it would be a big issue because I would be making it appear stronger than it was. Commented Apr 3, 2018 at 18:25
• One strategy you might consider is to make your randomly generated part the same "type" as your fixed part. Suppose an attacker found '4577657' and 4577614', they wouldn't know whether the rotating part was the last two digits or the last three. Commented Apr 3, 2018 at 21:59
• Use a KDF (Key Derivation Function) for [enter-favorite-deity-here] sake! Commented Apr 4, 2018 at 19:04

It depends on what kind of attack you are trying to protect against:

• If your password is one among millions in a data breach where the attacker isn't targeting you specifically, then your password is effectively 10 random characters long instead of 8. It will be harder to crack.
• If an attacker is targeting you, and knows about your pattern, then it gives you no protection at all.
• If an attacker is targeting you, and doesn't know about the pattern, it could help until the attacker finds out about it. Breaking one account would give a little help, breaking two would make the pattern obvious and hence useless.

So your system could be helpful sometimes, but not always. Or in other words: your "effective" password length will be somewhere between 8 and 10 depending on your threat model. But unless you have some specific reason not to, I would just forget all about clever systems and just install a password manager instead.

• And now that the pattern was revealed, he has to come up with a new pattern (or none, like how it should be). Commented Apr 3, 2018 at 14:45
• Exactly, it depends on your threat model. It is less secure than 10 random characters, and only as secure as 8, once the pattern is known. You have to assume the pattern will become known eventually. Commented Apr 3, 2018 at 17:06
• Related to the "attacker doesn't know the pattern" argument, if you use this algorithm on several websites, and a few of them do a very poor job of managing your passwords, then the algorithm may be quickly revealed and then the attacker gets to attack your effectively 8-character password on the strong sites they care about. Commented Apr 3, 2018 at 23:49
• The two words you are looking for are: Kerckhoff's principle. Commented Apr 4, 2018 at 20:22

So far the answers have been for "If I as a user add '.p' the end of all my passwords on various sites".

So I'd like to tackle the other possibility the original question could mean: "If I as a system programmer add '.p' to the end of all my users' passwords"

What you're describing is called a "Pepper" - it's a application-specific snippet that's tacked onto the password before hashing.

So what does this get you?

• It prevents dictionary attacks (since the attacker wouldn't know that every password has a specific string of characters appended to the end.)
• It prevents a breach in another set of credentials from compromising yours (since there's no way another system's Hash(Password) would match your Hash(Password+AppSpecificPepper).

What does it not get you?

• It doesn't prevent one password being cracked from cascading to all accounts with the same password, since Hash(Password+Pepper) would match for all accounts with the same password.

So, when it's all said and done? Absolutely - add the '.p' (or a much longer secret string) to the end of users' passwords. It makes the passwords more secure than just the original 8 chars alone - worst case, the attacker manages to compromise the app and get the pepper, in which case you're only as bad off as if you hadn't used a pepper in the first place. But make sure to add a Salt as well, so you don't let an attacker compromise multiple accounts with a single password crack.

• "It prevents dictionary attacks"/"It prevents a breach in another set of credentials" how so ? If the attacker is going through your application login interface, the suffix will be added to the password attempt by your application, no need for the attacker to know about it. Same thing if the user credential is compromised. This seems to only protect against a direct attack to the password database but if the passwords are correctly hashed and salted, I don't see any added benefits. Commented Apr 4, 2018 at 8:12
• @zakinster To avoid repeating the entire discussion, see here: security.stackexchange.com/questions/3272/… Commented Apr 4, 2018 at 10:22

No more, no less secure. An attacker has no clue even if he reveals one of your passwords (if you don't use as your suffix 2 digits, which is for an attacker the common setting of his attack's rules).

But if the attacker reveals two or more of your passwords and will try to break other of them, he certainly will see the pattern and will employ it.

• Even if they only get one, they can add that to their dictionary which will quickly adapt it to any future attack attempts. It would be foolish for them not to. Commented Apr 3, 2018 at 12:22
• @forest - The password as a whole entity may be added to their dictionary but what makes variations are rules applied to individual passwords, and from only 1 occurrence there is no clue which new rule add to current ones. Commented Apr 3, 2018 at 13:10
• @forest I don't get what you mean by "they can add that to their dictionary"... add what to the dictionary? Cracking one password will yield what to all intents and purposes are 10 random characters. I can't see how adding those 10 characters to the dictionary will help, and with only one password cracked, there's nothing to suggest that `.p` at the end is anything special. Commented Apr 3, 2018 at 15:32
• @Adonalsium Your point is unrelated to what TripeHound said. TripeHound said that after cracking one password, there is no pattern. Your point was that after cracking two or more passwords, there is a pattern. You also have to read the comment TripeHound was responding to, for context. Commented Apr 3, 2018 at 18:22
• @MarianD Of course there is an advantage. If I feed that into a cracking ruleset, it will automatically break it down and try variations of it as a prefix/suffix when attempting a brute force attack. Obviously the advantage is not large, but there is an advantage. There's a reason rulesets support adding existing known passwords. Commented Apr 3, 2018 at 19:42