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?
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 get the third salt.
Programmers: shut the fuck up and use a well known password derivation function. Stop the NIH wanking -- homebrew cryptography is about as useful as seeing the local witch doctor for a heart attack.
There is a standard method of securing online accounts, using known methods that are currently known to be perfectly safe in every application from financial institutions to the latest social networking site. Triple-salting passwords is not that method.
http://codahale.com/how-to-safely-store-a-password/
http://chargen.matasano.com/chargen/2007/9/7/enough-with-the...
I was providing an example of what could be meant by 'triple salting' that didn't necessarily involve 'three servers'. We could contrive scenarios where bcrypt with this multisource-salt would be a win over bcrypt with a single same-database salt. Intellectually exploring the problem and solution space requires more than just slavishly repeating the already widely-known 'standard methods'.
Have we worked together at a level that would help you assess my level of knowledge, and the sources thereof? I don't recognize your name/handle.
I agree, there could be an implementation where applying multiple salts might have a benefit, but SHA-512 is not that implementation. I was not slavishly repeating 'standard methods', but pointing out that they are or were widely wrong in whatever they were doing to begin with. An MD5 is hilariously weak for password hashing, and salting an MD5 only makes an extremely weak password hashing scheme moderately weak. It honestly sounds like they took the first hashing implementation with the largest number tacked on the back of it that came to mind and called it good. This is not the right thing to do, and anyone that 1) cares about the security of their online web app's users information, and 2) has spent more than 2 minutes reading about the correct ways to secure an online web app, should be able to figure this out.
Point being, the fact that they originally only had MD5, and then "upgraded" to a salted MD5, and now are going to a triple-salted (whatever that means) SHA-512, is a BIG clue that they really don't know what they are doing, and a complex homebrew triple salt implementation that passes a password to 3 different places to be salted is bound to be broken. Unless they have hired a well known experienced cryptographer, I wouldn't trust MTGox with a dime of my internet money.
I could quintuple-salt my passwords with 4096 byte salts chosen purely randomly and there would be no perceivable advantage over a single 512 bit salt.
At the end of the day, salts are there for one thing alone: eliminating the possibility of rainbow tables. But whether you use 1 salt of decent size (64-bit minimum for that) or 1000, you've got the exact same protection there. There's a good reason it's recommended that you use PBKDF2 or bcrypt.
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.
The NIST application involves generating keys from passwords, which you might do a gigantic number of times for every password to get unique sessions and so on. They're not talking about password storage. And even then, 128 bits seems like a huge overkill, which was included just because it's cheap, so why not. I don't mind 128-bit salts, but let's not promote that as some "ultra-secure" feature, which it isn't.
Thus, the fact that they are describing it in terms that none of us have heard of is a troubling sign.
"Don’t write your own Crypto algorithms unless you have a Doctorate in Cryptography."
How do these businesses succeed with business people that have no business wit about them, have NO ability to communicate effectively in these critical situations and have awful taste in technical advice?
Google "bcrypt sha-512 hash passwords" and tell me if it's a hard call to make. You should have heard these guys within the first 36-hours answering questions. Even the business guy over at TradeHill, "Well, you know after mtgox, we need to do a lot to beef up our security". Even if that's a true statement, what a ridiculously terrible way to phrase it.
I think speech and debate classes should be required for everyone to graduate highschool, let alone college. People aren't good at thinking on their feet and speaking in critical situations where wording makes a difference.
When you're in the business of being an online bank for an uninsured (nearly) untraceable currency, mis-speaking like this costs you your most important asset: TRUST. That's not even touching the tip of the iceberg of lies and misinformation that has come out of mtgox.
Anyone that leaves a penny in any mtgox account is an idiot.
They take off because they are excellent, useful and timely ideas. Unfortunately, people who have strong, timely ideas, like this one, frequently aren't able to find good technical co-founders, probably because of the "ideas are worthless" meme so many hackers love to recite nowadays.
So the ideas take off anyway, but the sites basically don't have the technical architecture that they should and have to be rewritten later.
In the current case, well just because it isn't perfect from a technical standpoint, doesn't mean it wasn't the best execution of the idea out in the wild...
You really think so? I find that statement sort of amazing. I guess ever the optimist, right?
BCrypt 1000 iteration test script: https://gist.github.com/1058610
# => That took 76.370953 seconds
BCrypt 1 iteration test script: (same as above but with `1.times do`)
# => That took 0.074209 seconds
SHA512 1000 iteration test script:
# => That took 0.004092 seconds
SHA512 at 1000 iterations is over 18,000 times faster than BCrypt at similar iterations; which, by the way, makes no sense to do.
BCrypt has a "cost" factor, which is used to adjust the computational complexity to your use case. This is why BCrypt makes so much more sense for password encryption than something like SHA512. Running SHA512 n times is just a cheap, ineffective imitation of BCrypt.
So you would either have to port bcrypt or use existing crypto code to approximate bcrypt-level security.
Most advances in cracking cryptographic hashes is not from Moores law, but some insight or breakthrough in the underlying algorithm. i.e. someone figures out a way to make MD5 brute forcing 2^(lots) faster. Usually these are not done overnight, but are chipped away bit by bit.
We are getting there with SHA512. The edges are starting to give. Warning signs are apparent. Eventually someone will reduce it to nothingness. 1000 iterations of nothingness is nothing ness.
SHA-2 is already in most languages without an additional library.
Oh dear god this is a terrible way to make a security decision. You have to install software no matter what you do. Unless you're writing software with a magnet in raw machine code, you will have to install additional software. Take the few minutes to install the bcrypt library.