I just added a comment basically saying the same thing. But you should use data that you would have that an attacker would not. First and Last Name as stored in your system, User ID (like 128912) and User Creation date are good choices. These should be in a separate database from the hashes.
Making the password comparison depend subtly on other fields seems like a bad idea from a maintainability perspective. Lots of reasons to update name, etc., which might not happen anywhere near the password code, and might be done automatically.
If the fact that a field might change some where else in your code is a "maintainability" issue, you have bigger issues and shouldn't be doing anything with passwords.
Private User Data should not be changed by many things. That is "PRIVATE" and therefore should be under tighter control than the rest of your data.
You misunderstand, it seems. The user's password shouldn't need to be re-entered and rehashed every time a non-password field is changed. Suppose you have a new developer on your team who writes a new uset profile page that can edit user first and last name without asking for the user's password again. Suppose you want to create an admin interface that allows your customer support team to change a user's name or e-mail address without seeing or knowing the user's password.
Don't try to outsmart the likes of cpercival and tptacek by inventing your own goofy hashing scheme. Just use bcrypt or scrypt as they suggest, the reasons for which they have explained repeatedly on this site for years.
Bcrypt offers no increase in security, and can add huge delays in your sign-on, user creation, and open you up to computational attacks by doing repeated sign-ins.
My "Goofy" scheme is based on the practices which Microsoft, LinkedIn, and FaceBook all use. You know which of those use Bcrypt? Zero.
Maybe you shouldn't blindly follow things people say.
Source? The typical benchmark is 8ms for a generation of a bcrypt hash on a modern machine.
> My "Goofy" scheme is based on the practices which Microsoft, LinkedIn, and FaceBook all use. You know which of those use Bcrypt? Zero.
Again, source? PBKDF2 and scrypt would be acceptable alternatives and both can take just as much time to compute as bcrypt (or more!) depending on how many rounds are set.
The rest of your advice in these comments (esp. your salt 'mechanism') is wildly off-base and in many cases, actively promotes worse security without any evidence to back up your claims.
DoS of the high-work-factor algorithms actually is a thing. The bad part is the attacker doesn't have to wait for a response, so he can actually initiate a bunch easily.
The gold standard if you are worried about DoS and need security vs. stolen db right now is to encapsulate everything inside an HSM and have a symmetric algorithm. Unfortunately HSMs today are shit -- $30k, slow, a hassle, etc. I'm testing some cheap stuff to do this cheaply and sanely (USB connected, etc.).
If you can scale out your frontends, use bcrypt/scrypt/pbkdf2 with a reasonable work factor.
> DoS of the high-work-factor algorithms actually is a thing. The bad part is the attacker doesn't have to wait for a response, so he can actually initiate a bunch easily.
Thankfully, rate-limiting login/registration forms is pretty straightforward (although the metric choice, not so much) and is good practice. If you can HTTP 429 them before they can actually submit a password to your service you're mitigating a large part of the problem.
That makes absolutely no sense. You're already arguing from authority while citing less reliable authorities than the security experts who recommend bcrypt, and then you're going one step further by including a site that hurts your argument by having already had a massive data breach that resulted in leaked passwords.
And your excuse is "people who disagree with me in an unrelated argument cite LinkedIn, so I'm doing it too"?
You misunderstand. You shouldn't have the password in memory. The password should basically never exist beyond the fractional second that you are validating it.
I know that. Which is why the hash should include just the password, and not a bunch of other data that would require having the password in plain text again just to let the user change something in their profile.
> But you should use data that you would have that an attacker would not. First and Last Name as stored in your system, User ID (like 128912) and User Creation date are good choices.
