2
votes

I have a iPhone app that requires users to register before they can use it. I grab the usual info including password. I am saving user registration details to my server and I am encrypting by prepending a salt string to the password and then hashing the result.

I #define a salt string to use to prepend to all my passwods but I read that the salt should be a randomly generated string for each new password.

Thats all good and I manage to generate a unique string for each password.

When I save the password on registration, the salted/hashed value is sent to my database on the server and saved in the "password" column.

Now assume the user logs out and then tries to log back in using their saved password. They enter their password, but then I salt and hash the password for sending, it gets to the database check and it doesnt match any of the passwords as the login password go salted/hashed with a new random salt string.

How do I handle this or do I have the process confused?

Should I be generating a new random salt string for each new password or do I just use the 1 salt string for all passwords?

1

1 Answers

2
votes

Todays password_hash() functions often include the salt plaintext in the resulting hash-value. This way you can store hash and salt into the same database field.

$2y$10$nOUIs5kJ7naTuTFkBy1veuK0kSxUFXfuaOKdOKf9xYT0KKIGSJwFa
 |  |  |                     |
 |  |  |                     hash-value = K0kSxUFXfuaOKdOKf9xYT0KKIGSJwFa
 |  |  |
 |  |  salt = nOUIs5kJ7naTuTFkBy1veu
 |  |
 |  cost-factor = 10 = 2^10 iterations
 |
 hash-algorithm = 2y = BCrypt

For verification they offer a password_verify() function, which will extract the salt from the stored hash-value and use the same salt to hash the login password. These two hashes are then comparable.

Hashing should be done server-side, usually the password is sent plaintext to the server, encrypted with HTTPS/SSL.