The part that bothers me about that is "triple salted hashing". This could mean any number of things, all of which point to a misunderstanding of what a salt is for.
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.