Fritzy.io

Redis Lua: Storing and Checking Hashed Passwords

redislua

See the update at the bottom: this approach isn't secure (but I still think it's interesting).

Storing passwords in plain text is bad.
Time and time again, databases get hacked and passwords get leaked.
Hashing a password creates a consistent string from a password that you can store, but isn't the password, and isn't easily reversed.
Reversing a hash is difficult, and typically done with brute force if the hashing algorthim is fairly secure.

People end up creating giant lookup tables called "rainbow tables" of every possible string combination up to a certain number of characters in order to quickly reverse hashes.
The best defense against this is to hash something larger than a typical password because it takes exponential time to create a rainbow table for each additional character.
We do this with dynamic and static salts.
Salts are used to add length to the password string before hashing.
A static salt is global across the application, and a dynamic salt is unique for each user.

Awhile back ago, @antirez accepted a pull request for redis.sha1hex() in Redis's EVAL scripts.
This gives us a great way to store and check hashed passwords.

> EVAL "setpassword script" 1 testpass bob "hi"
"Password must be at least 8 characters."

> EVAL "setpassword script" 1 testpass bob "hi there"
(nil)

> EVAL "checkpassword script" 1 testpass bob "hi there"
1) (nil)
2) (integer) 1

> EVAL "checkpassword script" 1 testpass bob "wrong password"
1) (nil)
2) (nil)

There are a few things to note here.

Update:

Again, Pierre Chapuis @pchapuis has some good feedback.
He references http://codahale.com/how-to-safely-store-a-password/ which argues against using typical hashing algorithms for hashing.
Since someone who has your redis db also has your Lua scripts, the salts are rather available to the cracker, even the dynamic ones.

We can easily argue that bcrypt/scrypt is the better way to go.
Unfortunately, it's not available in Redis, but that's not a terribly valid reason to discount it.

This approach is much better than nothing, but perhaps outdated.

As I'm writing this, Alex Gaynor @alex_gaynor just gave the same advice.