6 ms·
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
by drakaal 13y ago
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.
- rolux 13y ago> 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 two statements contradict each other.
- rdl 13y agoMaking 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.
- drakaal 13y agoIf 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.
- nitrogen 13y agoYou 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.
- drakaal 13y agoYou misunderstand. You shouldn't have the password in memory. The password should basically never exist beyond the fractional second that you are validating it.
- nitrogen 13y agoI 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.
- drakaal 13y agoBcrypt 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.
- mistercow 13y ago>Bcrypt offers no increase in security [citation needed] >My "Goofy" scheme is based on the practices which Microsoft, LinkedIn, and FaceBook all use. I don't want to be sarcastic here, but you're seriously going to cite LinkedIn? Really?
- drakaal 13y agoI don't like to, but every time I point out why node sucks, the node guys cite LinkedIn, so now I include it.
- mistercow 13y agoThat 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"?