This seems more complicated than it has to be. hash(salt + nonce + password) gets the same job done. If you don't trust your hash algorithm... pick a new one.

This seems more complicated than it has to be. hash(salt + nonce + password) gets the same job done. If you don't trust your hash algorithm... pick a new one. EDIT: It occurs to me that this whole notional improvement (the one from the article and my alternative) isn't as great as it might first seem: if an attacker gets the table of salt+password, and if the attacker knows the password to one account on the system, he can figure out what the nonce is by doing trial hashes using hash(nonce+salt_k+password_k), where salt_k and password_k are the known salts and passwords. In this way, he can figure out the nonce. Since you will very likely run into collisions when attempting to guess the nonce, you will have to have more than one known password, and you probably want to know something more about the nonce, e.g., its length, but fundamentally you're only increasing the difficulty of the attack by a small amount. EDIT 2: thinking about it more, the right way around this is just to use a gigantic nonce. If your nonce is 1k, good luck brute forcing it. In this case, I'm fairly certain that my proposed alternative is just as sufficient as the original.