Passwords for 32M Twitter accounts may have been hacked and leaked

Post by steveeq1 » Thu, Jun 09, 2016, 4:57 PM UTC

varikin wrote: post #155

mbrd wrote: post #146

Does anyone know the significance of the date 9-11-1961? The password list has 10,444 matches for "9-11-1961" and 10,231 for "9111961". From Wikipedia, I see that Hurricane Carla hit Texas that day but that doesn't seem noteworthy enough to warrant two instances of the date in the top 20, It would be surprising if it was only due to date of birth too, given I can't spot any other date-like entries.

I also looked up Nov 9, 1961 as most of non-US used day-month-year. Nothing spectacular either.

Post by drummer32 » Thu, Jun 09, 2016, 5:18 PM UTC

simonswords82 wrote: post #69

matthewmacleod wrote: post #68

Earlier quoted context omitted.

The takeaway for me is that (yet) another website I entered personal information has leaked it Well, I think it's quite difficult to argue that. If you had a keylogger installed on your machine – apparently the case here – in what way did the website leak your personal information? Wasn't it the browser's fault? I do think it's pretty illogical to complain about Twitter being vulnerable, if this leak was caused by sc…

Thanks for the explanation, makes sense. Still I wonder how many non-techies will simply read "Twitter hacked" and devalue the Twitter brand in their minds.

Post by kerkeslager » Thu, Jun 09, 2016, 5:21 PM UTC

Someone1234 wrote: post #143

kerkeslager wrote: post #132

Earlier quoted context omitted.

What problems with bcrypt/scrypt does argon2 solve?

It rate limits via IO (specifically memory IO) rather than processing power (CPU/GPU).

Post by giovannibajo1 » Thu, Jun 09, 2016, 5:46 PM UTC

cm2187 wrote: post #163

jfindley wrote: post #137

Earlier quoted context omitted.

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…

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.

Post by paulmd » Thu, Jun 09, 2016, 6:00 PM UTC

rmc wrote: post #169

cm2187 wrote: post #32

Earlier quoted context omitted.

Depends what you mean by short amount of time. Depending on the strength selected with bcrypt, it can easily take a second to check a hash. On a 30m password database, this will take a year on one machine to check just who is using "monkey" as a password.

"a second to check a hash" is a long time, but that's 3,600 attempts per hour. With rate limiting you can bring that down to 10 attempts per hour.