4 ms·
> ... 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
by 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.