0
$\begingroup$

I've implemented a system for my login page (with php) that will update the password hash and initialization vector (for openssl) on each login. So essentially, every time the user successfully logs in, the initialization vector for openssl is re-created in the following way:

1. generate 16 random bytes.
2. Hash the bytes with SHA256.
3. Store the hash in the database.

For encrypting the passwords:

1. Grab the newly created IV.
2. Cut the IV to a 16-byte-long string using a secret algorithm.
3. Use the shortened IV in the openssl_encrypt function, 
   along with the secret key and plaintext password.

Overall, the password is stored as a SHA256 hash of the openssl output, and the IV is stored as a SHA256 hash.

How strong is this method? Does updating the database user credentials increase or decrease the chances of a decryption in any event?

$\endgroup$
  • 1
    $\begingroup$ Choice of password hash aside (spoiler: these days, it takes a strong reason to use anything but scrypt or argon2), what is the threat you hope to thwart by rehashing the passwords on every login? Are you doing this just while upgrading an old password hashing scheme to a new password hashing scheme? $\endgroup$ – Squeamish Ossifrage Nov 15 '17 at 15:59
2
$\begingroup$

the initialization vector for openssl is re-created 1. generate 16 random bytes. 2. Hash the bytes with SHA256. 3. Store the hash in the database

if you generate 16 random bytes (128b), there is no reason to hash it

password is stored as a SHA256 hash of the openssl output.
How strong is this method?

you're encrypting the password what has a principial weakness - it is reversible. Once someone get access to your system (therefore all the code and configuration including your secret key), all user passwords are to be revealed. The user passwords should be stored as salted hash, so they are unrecoverable.

Seems you are effectively storing a salted hash of the password, that is good. However the sha256 is relatively fast function, you better to use PBKDF2 (slow hash) to mitigate dictionary or brute-force attack. There is a nice article how to do it properly

Does updating the database user credentials increase or decrease the chances of a decryption in any event?

The problem is once someone get access to the database and and all the configuration, the adversary will have all information needed to decrypt all the passwords.

Next - if the passwords won't change themselves, I see no reason for re-hashing the passwords, it just increases complexity of your application.

$\endgroup$
  • $\begingroup$ So rather than saving the iv to a separate row in a table, I should prepend it to the password itself? If someone has access to the source wouldn't it make that redundant anyway? $\endgroup$ – Brayden Nov 15 '17 at 9:07
  • $\begingroup$ @Brayden it doesn't matter if IV is in separate column or part of the stored hash, the password matching logic needs to be able to recover the iv. The IV (salt) is needed to create a password salted hash and compare the hashes. Next - really use PBKDF with reasonable complexity to create the password hashes (as described in the linked blog) $\endgroup$ – gusto2 Nov 15 '17 at 9:10
  • $\begingroup$ @Brayden now I am reading the the question again and properly: password is stored as a SHA256 hash of the openssl output - in that case you are good as the passwords are inrecoverable. Regardless that - the SHA256 is a fast function. Better to use PBKDF2 effectively iterating the hash MANY times + some other operations (to make dictionary and brute-force less effective) and I don't see any benefit in re-hashing the password $\endgroup$ – gusto2 Nov 15 '17 at 13:33
  • 1
    $\begingroup$ So store the password (openssl output) once with many iterations of PBKDF2 and stop updating the password on login? $\endgroup$ – Brayden Nov 15 '17 at 13:36
  • 1
    $\begingroup$ @Brayden : indeed, store the output of the salted and iterated slow hash (PBKDF2, bcrypt, ...) and you don't need to update the hash on each login (it won't bring any better security) $\endgroup$ – gusto2 Nov 15 '17 at 13:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.