121–130 of 176 posts
I really hope somebody is giving out the best clusterfuck of the year awards soon, because this just nailed it.
Earlier quoted context omitted.
> 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.
Earlier quoted context omitted.
It's a shame that they can't be bothered to learn about security, since they're in the business of holding other people's money. It seems that they have killed their amazing opportunity, and deeply harmed the public's confidence in bitcoin at the same time.
No, it seems to have gone fine. A lot of people (including Mt. Gox) decided to start taking security more seriously, and the price of Bitcoin has increased slightly.
You really think so? I find that statement sort of amazing. I guess ever the optimist, right?
"The new Mt. Gox site features SHA-512 multi-iteration, triple salted hashing" Why not use a standard key derivation function such as PBKDF2 or bcrypt to provide some confidence in the system rather than inventing their own? AFAIK bcrypt is strong because of Blowfish's expensive key setup. How does this compare to SHA-512?
1st rule of cryptography - don't try it at home. You'll get it wrong. There are any number of standard ways to protect passwords, there's no need for them to be reaching for the bottle of Snake Oil.
"Don’t write your own Crypto algorithms unless you have a Doctorate in Cryptography."
Earlier quoted context omitted.
I think you've meant: A bank is a legally defined concept where I live, this exchange is not one.
Not really no, a bank is a legally defined concept in pretty much every country in the world. Suggested reading: http://www1.law.nyu.edu/centralbankscenter/texts/order.html
Earlier quoted context omitted.
Doesn't a salt just make a rainbow table attack more expensive, in direct relation to the length of the salt?
No, it doesn't. Once the salt is large enough that you don't have several passwords hashed with the same salt value, there is absolutely no further advantage. Frankly, 64 bits of salt seems like enough for anything. Triple-salting sounds like a technique made up by an amateur who doesn't understand what salting is supposed to do.
nist-sp800-132.pdf http://csrc.nist.gov/publications/PubsSPs.html
Not quite the same application, but it would seem best to take a conservative approach and make your salts 128 bits because the storage required is so small - you are only storing one per username.
i realise it is kind of security through obscurity but in this instance the SQL injection wouldn't have compromised the private salt and it would have been much harder to recover the passwords. presumably, you would have to use a known pass/hash combo to brute force the private salt which would take a lot more computation time than recovering simple passwords.
Maybe, maybe not. But this hack may be one without recourse.
Earlier quoted context omitted.
That would mean that logins would have to go through 3 different servers. If anything, I would be more worried about security in that case.
Not necessarily. Let's say the salt is a combination of a per-user salt in the database, a per-user salt from a file on disk, and a per-system salt that's entered at the console at startup and held in memory. A DB compromise doesn't reveal the other 2 salts. A full filesystem image doesn't reveal the third salt. Even an interactive root compromise would need to know to take an image of the running system's memory to…