3 ms·
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-i
by drakaal 13y ago
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.
- 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.
- rdl 13y agoDoS 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.
- elithrar 13y ago> 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.