4 ms·
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 pas
by drakaal 13y ago
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.
- 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"?
- nitrogen 13y agoYou do recall that LinkedIn had its passwords stolen semi-recently.
- elithrar 13y ago> ... and can add huge delays in your sign-on 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.
- 13y ago