Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

techcrunch.com

Post reply on HN
Print view View original

101–110 of 199 posts

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

#101

Post by facepalm »

jfindley wrote: post #93
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.

You're massively overestimating the strength of bcrypt here. olcHashcat on a single modern GPU will do several thousand hashes per second, depending on work factor and GPU speed.

Then why even bother with bcrypt?

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

#102

Post by drrob »

merb wrote: post #19
drrob wrote: post #8

Earlier quoted context omitted.

I suppose the main danger is the possibility that someone might, at some point in the future if processing power should suddenly take a leap forward, come up with a way to crack them.

eventually at least on PBKDF2 you could also increase the number of rounds taken. So if somebody logs in you could recalculate the PBKDF2 hash.

Indeed, though I suppose you've got to hope that the keeper of the passwords gets their hands on a similar level of processing power as the attackers do, with which they can increase the encryption work factor.

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

#103

Post by DasIch »

adrianmsmith wrote: post #77
fit2rule wrote: post #37

Earlier quoted context omitted.

> it can easily take a second to check a hash On what hardware?

With bcrypt you can set a parameter which determines how slow it is. So if hardware gets faster, you can change the parameter. (brcrypt uses 2^n iterations where n is the parameter.) So it doesn't matter on what hardware, if you want bcrypt to take 1 second on modern hardware (for any value of "modern"), you can.

Chances are that you can't afford the most modern hardware. An attacker at least temporarily can probably afford more than you can. If you configure bcrypt so that an attacker spends 1s, it will be to slow to be practical for you.

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

#104

Post by realusername »

silversmith wrote: post #65
imrehg wrote: post #22

Earlier quoted context omitted.

Was just trying to set this up, and not great (IMHO). The feature is called "Login Verification", I think, and it's only SMS based, no Google Authenticator / Authy style one-time password... Also, it was saying I needed to verify my email address before that feature can be used, but there was no option to verify the email address that is used since I've registered almost a decade ago... Had to change my email (used t…

Curious, why is SMS-based auth a downside in your opinion? I prefer to use SMS-based 2FA where available, as you can always pop the sim card into whatever device you have on hand and receive the code. As opposed to smartphone app, where you are tied to a particular device being available and in working order.

No phone network for me why I go back to my parents place so it's complicated.

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

#105

Post by granos »

cdnsteve wrote: post #94

Why doesn't Twitter have 2FA or U2F? Problem solved, at least in terms of users not losing reputation within their own social space because someone is posting as them.

They do. In fact, I just logged in to change my password and had to go get my phone from another room so I could read the code. The annoying thing is that they don't support Google Authenticator or some other TOTP/HOTP token generator. It sucks trying to log into services that use SMS based 2FA when you are not in an are where you get cell reception.

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

#106

Post by MichaelGG »

tim333 wrote: post #90

>the malware sent every saved username and password from browsers like Chrome and Firefox back to the hackers I wonder how you protect against that apart from the thing banks do where they say enter the third and six character? Even with those if the malware monitored a few of them it could probably figure your info.

Saved user/pass are available to any process running on the machine. You don't have to wait until the user logs in, just access the saved pass DB. (Exception is if you use a password to encrypt the browser saved passes, like Firefox's master password. Then the malware needs to wait until you unlock.)

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

#107

Post by DasIch »

merb wrote: post #19
drrob wrote: post #8

Earlier quoted context omitted.

I suppose the main danger is the possibility that someone might, at some point in the future if processing power should suddenly take a leap forward, come up with a way to crack them.

eventually at least on PBKDF2 you could also increase the number of rounds taken. So if somebody logs in you could recalculate the PBKDF2 hash.

You can upgrade hashes offline as well. You just hash the existing hash with the new algorithm/configuration and remember algorithm, salt and any other parameters for all previously used algorithms. If you have all that information you can take the same path to verify the password and replace the chained hash with a simple hash that's faster to calculate.

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

#109

Post by DasIch »

jfindley wrote: post #92
tim333 wrote: post #89

Earlier quoted context omitted.

You can hash a fixed salt + password + some other user info like surname or email address. That way if you have the salt you can't just compute the hash of salt+"123456" to see who had that, you have to compute separately for each user.

What? No. Don't use a fixed salt. Each record should have a unique, random salt. You then store salt:hash(salt+password). There are numerous guides on how to do this properly, for example https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet

Though of coure you don't actually do that, you use something like bcrypt that does this for you.

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

#110

Post by jfindley »

facepalm wrote: post #101
jfindley wrote: post #93

Earlier quoted context omitted.

You're massively overestimating the strength of bcrypt here. olcHashcat on a single modern GPU will do several thousand hashes per second, depending on work factor and GPU speed.

Then why even bother with bcrypt?

Because something with a cryptographic hash, like sha256, you can do millions (or in some cases billions) of hashes per second on the same GPU.

Password hashes, like bcrypt, PBKDF2 and scrypt, are massively slower. That doesn't mean they're uncrackable, it just means they are expensive to crack, so a strong password in a well implemented password hash will take a long time (and cost a lot of money) to crack, by which time the user has hopefully noticed and had time to change their password.

Post reply on HN