Hacker News Reader

Comment by Daiz | Hacker News Reader

Should really start doing this for sites using MD5/SHA1 for password hashing too, as using them is barely above plain text in terms of security these days.

View on HN

How would one gather that information? What form of evidence would you accept?

We'd like to refrain from asking people to hack into sites just to figure out their hashing scheme :)

It is harder than with plain text, yes, but it can show through at times. For example, a while back I was looking through my profile settings on a forum I have an account on, and saw a "check password security" link on it. Out of curiosity, I clicked it, and was greeted with "if a Google search for [unsalted MD5 hash of your password] returns results, your password is not secure." I reported it to the site and turns out it was a leftover from their old system, and it got removed shortly after (along with the MD5 password hashes).

You could also always ask too. I was reading through the forums of another site and stumbled upon a thread of someone asking HTTPS support for the site. The staff was pretty reluctant about the idea, which made me wonder about other security concerns. Looking around a bit, I noticed that the site cookies contain a "pass" value that looks very much like an MD5 hash. I got someone who used to be staff to ask the current staff how passwords are hashed, and the answer was "salted MD5".

Also, why is my initial post getting downvoted? Generic hashing algorithms are built for speed, which is bad for passwords. Key derivation functions exist for a reason. Hell, just a while back there was a user database leak from a site called MangaTraders, and they used unsalted MD5 for password hashing. It didn't take long before the vast majority of passwords had been cracked.

If anyone can gather this sort of information, we'll gladly publish it :)

> as using them is barely above plain text in terms of security these days

How so?

Cracking them is so fast these days that they don't offer much in terms of security. For example, take a look at this post:

http://www.troyhunt.com/2012/06/our-password-hashing-has-no-...

Then note that it was posted two years ago. GPUs surely haven't gotten any slower since then.

Same applies to all hash functions. It's how you implement it that counts.

If I recall right, those functions are too fast. It is too easy to iterate through all kinds of possible passwords and you are likely to find plenty of matches.

At minimum, you need to add unique salt to each password. It forces the attacker to run dictionary on each account separately. It is also recommended to use different slower hash function or iterate MD5/SHA1 thousands times, so he will be much slower.

Try to avoid directly invoking "SHA256" in your own security-related code.

good: http://en.wikipedia.org/wiki/PBKDF2

gooder: http://en.wikipedia.org/wiki/Scrypt

Maybe avoid using SHA256 with them because of Bitcoin ASICs. If your passwords get leaked in hashed form, even with these, you'll still want to tell your users and advise/force them to change their passwords. Forcing makes more sense if you have 2FA to something not likely to be accessible with their previous password (SMS maybe?)

See hashcat. :) It is easy to crack those types of hashes these days. Or even just search for the hash in google.

Same applies to all types of hashes. Implementation counts more than which function you choose.

Reply on news.ycombinator.com