Would appending junk data to user passwords before hashing affect security?

Question

I've seen similar questions on the site but not this exact one.

The closest one was Altering passwords before storing where the accepted answer sums up by stating that transforming the password is wasted CPU cycles that could otherwise go into higher iteration count on your actual hashing.

While that much is correct, consider the following scenario:

Lets say your application uses one host for the application code, and another host for the database/storage. It is possible, that sometime in the future, your database would be compromised, but your application code would remain secret.

If that happens, the attacker may try to reveal user passwords with a mixture of either brute force or wordlists with regex, something that is likely to uncover at least some passwords, and more as time passes.

Obviously, if you found out that your database has been compromised, you'd reset all user passwords. But in the delta time between it actually having been compromised, and you finding out about it, the attacker has a potential attack vector to access certain users' vulnerable accounts.

So I've been thinking, specifically for this scenario, wouldn't simply appending some junk data to user passwords before hashing make this attack vector much weaker? (i.e. make it harder for an attacker to reveal any passwords in time before you find out what happened and reset them)

I'm not talking about general transformations but instead specifically about appending because: 1. it ensures that all passwords remain unique after modification, thus not losing entropy. 2. it's a relatively low cost computation task in the process of a server accepting registration forms and formatting responses. 3. it's simple, and does not add code complexity that would make the application harder to maintain in the future.

The string to append would be a constant string, stored in one place in the application code. Obviously, if the application code gets compromised, the whole thing is pointless. But if only the user password hashes were compromised:

1. would this be effective at all in slowing down an attacker? (i.e. make it take longer to reveal user passwords using modern methods)

And, in general:

2. would this introduce any new vulnerability in the system?

Example:

Application server has a constant string: "!@#$%^&(),;" User A registers with the password "secretpassword" The server concats the two, creating: "!@#$%^&(),;secretpassword" Then bcrypts the new string, and stores the resulting hash in the database.

For every future login attempt, the constant string would be appended in the beginning of the user's password (on the server) before recalculating the hash.

Now lets say I have a million users, and an attacker got hold of a million password hashes that my application uses to authenticate the users. The attacker also knows that I'm appending a constant string to the beginning of user passwords on the server, in fact I'm stating it publicly on my register GUI. However the attacker does not know the actual string that I'm appending.

would User A's account be safer (i.e. it would take the attacker longer to reveal his original typed password "secretpassword" or find a way to log in to their account and take hold of their data) or would it be the same? would some other User X become less safe now because of this change, or would no other user be affected for the worse?

Answer 1

What you are proposing is called pepper. It's another type of salt, but it is not stored. This will not help much, because according to Kerckhoffs's principle, you must assume the attacker knows everything on your system, except the key. In this particular case, assume the attacker can read every single file, every record on the database and every log. He only don't know the user's passwords.

If your system is open for registration, the attacker could even register himself, read the database, get his own hashed password, and bruteforce the secret string. If the string is the same for every hash, as soon as he discover the secret string for his password, all your million users are compromised as well.

You can't plan security based on something that immediately loses all usability forever once is broken. As soon as the secret string is discovered, all your passwords are vulnerable and you cannot just change it. You will have to wait all users to login, get the cleartext passwords for each one, change the secret string, and re-hash it. It can take months or years for all your users re-login. Unless, of course, you go full hardcore insecure mode and store the cleartext passwords somewhere too.

You will increase the security by using a strong hashing function, and adding more rounds on the hashing process, not by adding anything on the password, or hash, or both.