Perhaps they mean it's salted by 3 different environments, so an attacker would need to crack the db server and 3 other servers just to get a chance to start cracking the passwords.
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 get the third salt.
Why reinvent the wheel using engineering techniques you only have cursory knowledge of from reading an encyclopedia?
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.
I wasn't advocating this method or defending Mt. Gox. (Their touting of SHA-512 and use of the unclear term 'triple salted' raises red flags.)
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.
No, we haven't worked together. My "cursory knowledge" comment was more directed at the people running MTGox, not you. Sorry if I phrased it in such a way to imply so.
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.
That idea is absolutely not clever. It's a system that would be difficult to implement, fragile, and most importantly would provide almost no added security.
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 are plenty of ways that you could use 3 different salts without it having to pass through 3 servers, but I was specifically responding to the OP, where he spoke of 3 salts in 3 different servers.
