Hacker News new | ask | show | jobs
by walkon 5462 days ago
True, but I think this has been fixed, assuming their new site is live:

"The new Mt. Gox site features SHA-512 multi-iteration, triple salted hashing and soon will have an option for users to enable a withdraw password that will be separate from their login passwords."

2 comments

Which means that they're not using bcrypt, which means they still have no idea what they're talking about and are probably insecure.
They could be using PBKDF2, but if they were, they probably should have said the magic words. Also, the iteration count is kind of important. If it's triple-iterated, that won't do much good.
Even with the iteration count, SHA512 is not exactly meant to be slow. They're taking the long way around to try and get the security of bcrypt... without just using bcrypt.
> Even with the iteration count, SHA512 is not exactly meant to be slow.

Increasing iteration count is synonymous with intending something to be slow. BCrypt itself uses a default of 2^10 iterations in most bindings. PBKDF2 + and an NIST studied hashing algo like SHA512 is a perfectly valid method.

Iteration is valid, but what is this about "triple salting"?

Googling "triple salted" sha -gox gives me 13 results, of which 3 are about caramel cupcakes and none are serious evaluations of such an approach. It sounds like homebrew security.

I can't see how it could mean anything at all. Your password is either salted or it isn't, a hash can't really be said to have multiple salts. Maybe they're using different salts in their various rounds of hashing, can't see how that would provide any more security.
Not sure why I'm downvoted, SHA-512 is obviously better than MD5 and we don't know the details. The constant spewing that bcrypt is the only way to hash a password is getting old fast.

<edit> Ok, whatever, keep downvoting, fuckers.

The reason you're being downvoted is because this has been explained a fair number of times on HN. The problem with using SHA-* or MD5 for hashing is that those algorithms are designed to be fast. This means that it's relatively easy for a cracker with a dump of the database to bruteforce passwords, since they can try gazillions of combinations very quickly. Hell, they can even parallelise the task on EC2 and get it all done in an hour.

By contrast, computing bcrypt takes a significant amount of time and CPU. It's slow. It's designed to be slow. It's designed so that you will need a LOT of CPU power to bruteforce it.

So, no, SHA-512 is not much better than MD5. It's still a fail.

And bcrypt is better than sha512, why use an inferior option when you don't have to? bcrypt both exists and is free.
Many are forced to use insecure hashing for compatibility reasons with outside vendors. Google email for orgs/colleges has two options for hash exchange (or used too... it may be different now) MD5 and SHA1. So you could not migrate user accounts unless the hashes were MD5 or SHA1.