# salting with password hash to improve security?

Would something like the following improve security (against rainbow attacks, not brute force)? Assume that $P$ is a user-chosen password, and the objective is to obtain a hash $H$ for password checking.

• Let $S$ be a random salt.
• Let $A_1 = MD5(P || S)$
• Let $A_2 = MD5(A_1 || P) || A_1$
• Let $H = MD5(A_2)$.

The idea is to increase the ciphertext length and the number of MD5 iterations by "salting" the hash with another hash of the password. Does that really help?

-
Duplicate on security.stackexchange: When hashing passwords, is it ok to use the hashed password as the salt? – CodesInChaos Aug 5 '13 at 15:25
sorry, searched but didn't find that. – nonchip Aug 5 '13 at 16:08
Please don't roll your own password hashing protocol. A single round of MD5 with any salt is not good enough. Use bcrypt, scrypt, or PBKDF2. – Stephen Touset Aug 5 '13 at 17:18
@e-sushi "Duplicate of a question on another SE site" is (IMHO) not a valid close-reason. Either it is off-topic here (then it doesn't matter much if another site has a duplicate, other than for not migrating it there), or it is on-topic here and should get an answer here. (There are some ways this question could be improved to actually become on-topic.) – Paŭlo Ebermann Aug 5 '13 at 19:00
@PaŭloEbermann I disagree that this question is off-topic. It's about whether a cryptographic algorithm is appropriate for an objective. The PHP code was readable and the implementation wasn't at stake, but in any case I've translated it to mathematical notation. – Gilles Aug 6 '13 at 14:38

Security against attacks using rainbow tables requires using a salt. In your first step $A_1 = MD5(P || S)$, you're already mixing in a salt. Provided that the salt is indeed globally unique (and randomly generating the salt is a correct way of achieving that), you already have protection against rainbow tables.
So if instead of using $A_2$ you used $A_{10000}$ (or however many iterations would be reasonable based on current CPU speeds), you would have what looks like a reasonable password hashing scheme, built along the same lines as PBKDF2, which is one of the recognized good password hashing functions. However, in cryptography, details matter. Maybe what you're doing is as good as PBKDF2, or maybe it has a fatal flaw that isn't immediately obvious to me. It would take a long time of analysis by multiple expert cryptographers to determine whether your password hashing function is acceptable.