Is this password encryption safe enough?

Question

I was thinking of doing a simple password upgrade to a system that at the moment has something like this:

md5(md5($pass) . $user);

The password will pass through a JavaScript hashing algorithm before being sent and this always makes a three characters password about 20+ characters.

I thought using the ends of the hashed password as KEY and IV to encrypt the rest should should suffice.

$pass = '20_plus_characters_long';
$hash = openssl_encrypt(substr($pass, 5, -5), 'aes-128-cbc', substr($pass, 0, 5), false, md5(substr($pass, -5), true));

Am I correct?

Answer 1

There are several weaknesses in your scheme. Actually you encrypt the password and throw away the key.

1. You take only 5 (base64 encoded) characters as the key, so an attacker needs about 1 Giga tries to crack the hash in the database (for comparison, everybody can crack 8 Giga MD5 hashes per second). This cracked database-hash can then be brute forced with the md5(md5($pass) . $user) scheme, which is also ways too fast.
2. Since you do not add a random salt in the MD5 part, an attacker could prepare rainbow-tables for specific accounts like user "admin", then the only protection is the weak encryption part.

Actually there is no advantage over the standard way with the password_hash() function. This function will produce a BCrypt hash, and the cost factor determines the needed time for calculation to thwart brute-force attacks.

Answer 2

Is this password encryption safe enough?

Probably not, but it depends on your threat model.

Two users with the same password will have the same entry in the password database. That's a loss in PRP-security (pseudo-random permutation). That is, an attacker will be able to distinguish a random answer from a real answer.

---

md5(md5($pass) . $user);

You should probably look at Openwall's Portable PHP password hashing framework (phpass) and John Steven's Secure Password Storage. Steven even takes you through the threat model and explains why you do things.