News for hackers. Stuff that matters.

A comment on Passwords for 32M Twitter accounts may have been hacked and leaked. Parent comment

Re:Passwords for 32M Twitter accounts may have been hacked a... by jfindley on Thursday June 09, 2016 @09:57AM (#11869383)
The work factor also increases the work the server has to do to handle users logging on, which is a big cost both in UX and hosting fees. In practice, reasonable work factors for bcrypt are between 10 and 12. What application could tolerate a full second of delay (and 100% usage of a server core) just to hash the users password?

Also, a few thousand hashes per second (and that's on a GPU, and bcrypt is decidedly GPU unfriendly due to memory allocation patterns) won't allow you to do much more than a dictionary / rule + dictionary attack, so in the short term you're only going to get weak passwords.

[ Parent | on HN ]
Re:Passwords for 32M Twitter accounts may have been hacked a... by cm2187 on Thursday June 09, 2016 @11:54AM (#11870214)
I don't think anyone has any expectation that a login should be as fast as any other page load. Same thing for authorising a payment. I don't think a 1 sec delay when authenticating is unreasonable.

To me the risk with using bcrypt is DOS. If you have a high work factor, all an attacker has to do is to run a lot of logon (no need to be successful, they just need to relate to real users) to sink your servers.

[ Parent | on HN ]
Re:Passwords for 32M Twitter accounts may have been hacked a... by giovannibajo1 on Thursday June 09, 2016 @01:46PM (#11870990)
No matter what you do, you always need to have a rate limiter / DOS mitigation for your login APIs / pages.
[ Parent | on HN ]
Re:Passwords for 32M Twitter accounts may have been hacked a... by seanwilson on Thursday June 09, 2016 @12:50PM (#11870583)
> The work factor also increases the work the server has to do to handle users logging on, which is a big cost both in UX and hosting fees. In practice, reasonable work factors for bcrypt are between 10 and 12. What application could tolerate a full second of delay (and 100% usage of a server core) just to hash the users password?

Is there a way client side processing power could be leveraged to help calculate the final hash value so that the computational cost could be practically increased?

I'm aware that having the client calculate and send the final hash value by themselves is a bad idea though.

[ Parent | on HN ]