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:
- 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:
- would this introduce any new vulnerability in the system?
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.
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?