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

121–130 of 199 posts

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

#121

Post by weeksie »

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.

Try spending a bit of time traveling. I've been on the road for almost a year. My phone number changes every month or two (or more depending on if I'm buying new tourist SIMs everywhere I go).

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

#122

Post by TACIXAT »

xerophyte12932 wrote: post #34
andrewmunsell wrote: post #6

Earlier quoted context omitted.

It would allow you to bruteforce the passwords without any sort of rate limiting. So, if you used a dictionary, you probably could get quite a few weak passwords in a short amount of time relative to a system that had proper rate limiting to prevent these kinds of attacks.

wouldn't the slowness of bcrpyt be a hindrance enough? Of course rate limiting is a much greater barrier, but I thought the whole point of using bcrypt is that its naturally slow and prevents checking several passwords in a short time

You can set the work factor (log rounds). Bcrypt is also cool because it doesn't scale well to GPUs, so it's still pretty slow even if you have decent hardware.

The rounds are a trade off between how long your users will wait to login and how strong the hashes will be. The current recommendation is between 8 and 12 depending where you look. The best practice is to just check on the system you are running, I usually aim for the number of rounds nearest a half a second.

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

#123

Post by nathan-wall »

nilved wrote: post #91
adrianmsmith wrote: post #77

Earlier quoted context omitted.

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.

But 1 second of CPU time on your Web server is a lot different than 1 second of CPU time on a supercomputer.

Or 1 second of GPU time. Or 1 second of time running on an ASIC.

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

#124

Post by _asummers »

jfindley wrote: post #110
facepalm wrote: post #101

Earlier quoted context omitted.

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…

Additionally, there's a new player in town called Argon2 that attempts to solve the problems with bcrypt and scrypt. It's the most recent winner of the password hashing competition.

https://github.com/P-H-C/phc-winner-argon2

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

#125

Post by heinrich5991 »

tim333 wrote: post #116
jfindley wrote: post #111

Earlier quoted context omitted.

Yes absolutely this - I was just trying to explain how salts should implemented - in the real world always use something like bcrypt or scrypt that does all this for you.

OK, I think I got my terminology wrong. But my thinking was that as well as using bcrypt or whatever on the info in the database you can add some random value stored in code rather than in the database so if your database is compromised it's still a job for them to crack it. Not quite sure what you call that.

A pepper.

https://en.wikipedia.org/wiki/Pepper_%28cryptography%29

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

#127

Post by atom-morgan »

pmlnr wrote: post #126

I should just close and burn all my social/bigco accounts and keep only the ones where an RSA token is available and forget to worry about passwords, shouldn't I?

http://www.reuters.com/article/us-usa-security-nsa-rsa-idUSB...

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

#128

Post by thinkt4nk »

bad_user wrote: post #10

Twitter also does 2-Factor Auth. If you value your Twitter account, in addition to changing your password (which hopefully is unique amongst your accounts), also activate 2FA.

Unfortunately this only helps protect a twitter account. It doesn't protect against the greater concern, where the password has been cracked and the user has reused the password on other sites.

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

#130

Post by lkbm »

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.

> depending on work factor

Right, but therein lies the strength of bcrypt. You can set it so it will be several thousand per second, or several seconds per thousand. This comment seems a little like saying "I can run faster than a car, depending on how hard you press the accellertor."

Post reply on HN