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

Security Update

stackoverflow.blog

Post reply on HN
Print view View original

121–130 of 207 posts

Re: Security Update

#121

Post by dhritzkiv »

bredren wrote: post #117
dhritzkiv wrote: post #109

Earlier quoted context omitted.

MD5 is one thing as a password can be retrieved from a hash table. But pulling out passwords from a hashed + salted value (e.g. via bcrypt) is many orders of magnitude more infeasible, no?

I would be impressed if SO's user password table is in bcrypt.

What makes you say that? bcrypt's been the defacto best practice for user password "storage" for probably 10 years now. MD5's been known to be inadequate for much longer.

Even if they had a legacy implementation in MD5, gradually migrating from storing MD5 hashes to storing bcrypt hashes is trivial to do.

Re: Security Update

#122

Post by thaumasiotes »

bredren wrote: post #105
9nGQluzmnq3M wrote: post #47

Earlier quoted context omitted.

I would like to hope Stack Overflow of all companies doesn't store passwords in plaintext, but you never know.

I work on an enterprise infosec tool that just demonstrated 48 trillion MD5s per second using AWS GPUs. Hashed passwords are cracked so easily it is a minor obstacle at this point. It is a question of when not if a hash table is fully cracked.

> It is a question of when not if a hash table is fully cracked.

...? At 48 trillion hashes / second, you could get the entire hash space in as little as 224 quadrillion years.

Of course, if you had any collisions, it would take longer. A lot longer.

This suggests that strong passwords are still just as strong under md5 as under a more modern hash. No? Use of md5 is a problem because people use passwords that are easy to guess, not because you can enumerate the hash space. The one-way-ness is as secure as ever.

Re: Security Update

#124

Post by IloveHN84 »

9nGQluzmnq3M wrote: post #40

Serious question: what sensitive user data is there on Stack Overflow anyway? Questions, answers and comments are all public, the content is Creative Commons licensed and even available in handy downloadable & queryable form: https://data.stackexchange.com/ As far as I can see, the primary sensitive user data they have is e-mail addresses, but (unlike, say, Reddit) most StackExchange forums don't deal with personally…

Passwords that might be similar to other services and then try to access those services as well.

And also all the metadata associated to user's activity

Re: Security Update

#125

Post by pathseeker »

bredren wrote: post #119
cyphar wrote: post #114

Earlier quoted context omitted.

Well, nobody should be using MD5 (nor should they have been using it 20 years ago with the introduction of bcrypt). In fact, nobody should be using any hash function that was designed for speed (such as the SHA family) because you don't want fast hashing of passwords . Modern cryptographic hash functions that are tailored for password hashing (such as scrypt or Argon2) are much harder to brute-force and have tunable…

There are plenty of publicly leaked hash tables running MD5 and the like. Just because modern hash functions exist does not mean they are in use. [1] Also you do not need the hash table of a hardened system to get useful passwords. You need a reused password from a weak one. [1] https://hashes.org/leaks.php

>There are plenty of publicly leaked hash tables running MD5 and the like.

Not related to stackoverflow though.

>You need a reused password from a weak one.

If the weak password is already public, what is gained by finding out that it's a weak password in a strong DB? You've just described a dictionary attack.

Re: Security Update

#126

Post by bredren »

dhritzkiv wrote: post #121
bredren wrote: post #117

Earlier quoted context omitted.

I would be impressed if SO's user password table is in bcrypt.

What makes you say that? bcrypt's been the defacto best practice for user password "storage" for probably 10 years now. MD5's been known to be inadequate for much longer. Even if they had a legacy implementation in MD5, gradually migrating from storing MD5 hashes to storing bcrypt hashes is trivial to do.

From what I understand, many systems do not choose to implement strong hashing algos.

Re: Security Update

#127

Post by AstralStorm »

thaumasiotes wrote: post #122
bredren wrote: post #105

Earlier quoted context omitted.

I work on an enterprise infosec tool that just demonstrated 48 trillion MD5s per second using AWS GPUs. Hashed passwords are cracked so easily it is a minor obstacle at this point. It is a question of when not if a hash table is fully cracked.

> It is a question of when not if a hash table is fully cracked. ...? At 48 trillion hashes / second, you could get the entire hash space in as little as 224 quadrillion years. Of course, if you had any collisions, it would take longer. A lot longer. This suggests that strong passwords are still just as strong under md5 as under a more modern hash. No? Use of md5 is a problem because people use passwords that are eas…

No, MD5 has about 18 bit collision strength. Combined with predictable salting practice, this is crackable with a calculator. Welcome to Merkle-Damgard construction allowing any prefix or suffix.

Given random salt (random placed or mixed) or HMAC, you have to use the more complex preimage attack at 123 bits.

This is crackable with a medium sized botnet or a supercomputer.

48 THash is an underestimate. Specialized hardware easily surpasses this, even FPGA does.

SHA1 salted is a tougher customer with 60-64 bit collision resistance meaning you probably cannot crack it with your calculator. However, it is still prone to length extension meaning predictable salting has this much strength.

Re: Security Update

#128

Post by bredren »

pathseeker wrote: post #125
bredren wrote: post #119

Earlier quoted context omitted.

There are plenty of publicly leaked hash tables running MD5 and the like. Just because modern hash functions exist does not mean they are in use. [1] Also you do not need the hash table of a hardened system to get useful passwords. You need a reused password from a weak one. [1] https://hashes.org/leaks.php

>There are plenty of publicly leaked hash tables running MD5 and the like. Not related to stackoverflow though. >You need a reused password from a weak one. If the weak password is already public, what is gained by finding out that it's a weak password in a strong DB? You've just described a dictionary attack.

My mention of MD5 was just a benchmark reference.

I can see from the downvotes the very idea that it is in regular use as triggering for some folks—-but md5 and other weak hashing algos are not just in obscure anime forums but in systems everywhere.

“They don’t like to think it be like it is, but it do.”

And it isn’t about md5 hash rate it’s about the ease of cracking in general due to low cost of compute.

If the SO password hash has leaked even in bcrypt its going to be attacked and many strong passwords will be broken. If they are reused elsewhere, important email addresses will be attempted elsewhere.

Don’t reuse passwords.

Re: Security Update

#129

Post by adrianN »

robomc wrote: post #64
9nGQluzmnq3M wrote: post #47

Earlier quoted context omitted.

I would like to hope Stack Overflow of all companies doesn't store passwords in plaintext, but you never know.

They don't have to store them as plain text for it to be a problem. If they're not salted it's trivial to crack the hashes, and if they are all uniquely salted, while it's time consuming, they can still gradually crack them. Given that you could probably sift through the users to find particularly juicy targets (usernames of maintainers of top open source projects with github repos for example?) that could justify th…

I haven't checked in a while, what's the cost of cracking a single salted password that is stored properly, e.g. with pbkdf2 or bcrypt or whatever is currently state of the art?

Re: Security Update

#130

Post by jve »

robomc wrote: post #64
9nGQluzmnq3M wrote: post #47

Earlier quoted context omitted.

I would like to hope Stack Overflow of all companies doesn't store passwords in plaintext, but you never know.

They don't have to store them as plain text for it to be a problem. If they're not salted it's trivial to crack the hashes, and if they are all uniquely salted, while it's time consuming, they can still gradually crack them. Given that you could probably sift through the users to find particularly juicy targets (usernames of maintainers of top open source projects with github repos for example?) that could justify th…

Of all the sites and people, I expect Jeff Atwood and Joel Spolsky to have followed best practices in storing user passwords.

Jeff wrote this in 2007:

> Do not invent your own "clever" password storage scheme

> Never store passwords as plaintext.

> Add a long, unique random salt to each password you store.

> Use a cryptographically secure hash. I think Thomas hates MD5 so very much it makes him seem a little crazier than he actually is. But he's right. MD5 is vulnerable. Why pick anything remotely vulnerable, when you don't have to? SHA-2 or Bcrypt would be a better choice.

https://blog.codinghorror.com/youre-probably-storing-passwor...

Another topic on passwords: https://blog.codinghorror.com/the-dirty-truth-about-web-pass...

Post reply on HN