Skip to main content
added 659 characters in body
Source Link

If the password ever collides with salt (for some reason), then $a=b$, which can be quite disastrous.

Such event may be, for example, caused by a bug in the software implementation, which could reuse password as salt (or vice versa) if the latter input is not generated properly or is missing. Another example would be predicable salt; then an adversary could choose password equal to the future salt and cause $a=b$.

If this happens, whoever eavesdrops the authentication procedure can encrypt/decrypt (and vice versa). Without further details it is hard to estimate the consequences, but for safety I'd recommend using something like $$ a = PBKDF2(0,x,y);\\ b = PBKDF2(1,y,x). $$ which is very close to the original but does not have the weakness.

If the password ever collides with salt (for some reason), then $a=b$, which can be quite disastrous.

If the password ever collides with salt (for some reason), then $a=b$, which can be quite disastrous.

Such event may be, for example, caused by a bug in the software implementation, which could reuse password as salt (or vice versa) if the latter input is not generated properly or is missing. Another example would be predicable salt; then an adversary could choose password equal to the future salt and cause $a=b$.

If this happens, whoever eavesdrops the authentication procedure can encrypt/decrypt (and vice versa). Without further details it is hard to estimate the consequences, but for safety I'd recommend using something like $$ a = PBKDF2(0,x,y);\\ b = PBKDF2(1,y,x). $$ which is very close to the original but does not have the weakness.

Source Link

If the password ever collides with salt (for some reason), then $a=b$, which can be quite disastrous.