securing passwords
in a database

Securing the data stored in the database.

youtube (16m55s):

Suppose we store passwords or credit-cards in our database. What might someday happen (inferring from headlines)? Sadly, somebody might breach the db itself (aside from the website entirely) — either a hacker exploiting a DB security hole, or somebody accidentaly revealing the DB account password, or an inside employee stealing data.

Solution: Don't store the password in the database!
“But Barland, how the heck can we verify that they've typed in the correct password?”
We'll instead store a hashed form of the password. Then, when a user later types in the password on a form, we'll hash whatever they type, and see if the two hashes are equal.

php > echo hash('sha256', 'hello');
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
php > echo hash('sha256', 'helmo');
05c21a42da66f4e2d217e35b74ef9dc2d65c8d46f9aec0d6397a65dd3c766f21

(Yes, theoretically, there is tiny (but non-quite-zero!) chance that two different strings might happen to encrypt to the same value. In practice, I would wait to win the lottery nine times in a row ¹before I worry about two independently-chosen strings both happen to have hash-values that collide.)

Q1: If my form hashes the password client-side, and only sends the hash to the server to be verified, this is secure, right?
A1: No!
If an eavesdropper can overhear the hash being communicated, the server only sees/checks the hash to determine if a user knows the password, then such an eavesdropper would be able to fool the server!
So, even if using hashed passwords, be sure to use a secure (https) connection whenever sensitive information is transmitted.

Q2: Should you hash the password client-side, or server-side?
A2: server-side!
Although either approach protects against people guessing passwords, if your database were breached and an attacker glimpsed the hashed-passwords, you wouldn’t want them to be able to log in as another user. By having the password submitted to the server (over https of course), and having the server hash the string, it means that knowing the hash isn’t enough — an attacker would need to know some string which hashes to what was found in the database — and that’s exactly what secure hashes make difficult/impossible! (Of course, if an attacker has breached the database, you might have much bigger problems — did the attacker modify the database-contents, including changing other people’s passwords to hash('sha256','ha-ha, pwned!').)

Salting the hash

Of course, to help protect against brute-force dictionary attacks, you want to add a few extra "salt" characters to the password — say, 20 characters. And ideally, these should be different characters for each person (else, if an attacker found out the one salt you used, they could use that on every word in the dictionary and look for matches). … But it’s admittedly a bit of a hassle, to generate a salt for each user, and store that in the database as well as the hashed password.

Salting helps slow attacks on dictionary-based passwords, but is not a substitute for enforcing users to keep a good password &ala; xkcd.

Solution:

except, php on rucs...: Unfortunately, rucs’s old version of php is <5.5, so it does not support the functions below, so there you have to generate a salt, and store it, yourself.

The function password_hash does it for you: it returns a hashed password concatenated to a random salt. (See the format of the result.) Then later, when a user returns, you can call password-verify, giving it the previous string, and it returns a boolean value:

         php > echo password_hash("kittee",PASSWORD_BCRYPT);
         $2y$10$Pj/26IW2mmF7LrA7WZGKeOf7YMIX5EKT7h8bhoBCwQs67PB5DDhUi
         php > echo password_verify("kittee",'$2y$10$Pj/26IW2mmF7LrA7WZGKeOf7YMIX5EKT7h8bhoBCwQs67PB5DDhUi');
         1
         php > echo password_verify("doge",'$2y$10$Pj/26IW2mmF7LrA7WZGKeOf7YMIX5EKT7h8bhoBCwQs67PB5DDhUi');
         php > echo password_hash("kittee",PASSWORD_BCRYPT);
         $2y$10$Ije9mY4Mm9LwEFWSySGBmOGjzg1/Y6VLYLPnsmWVuWHzoYdiz5lyG

For more details, read the php docs: us.php.net/manual/en/faq.passwords.php.

¹ Why nine? Chances of winning the powerball lottery are about 1 in 292 million, which will approximate as 256Meg = 2^8*2^20 = 2^28. That's 28/4=7 hex digits. Sha256 returns strings with 64 > 7*9 hex digits. ↩

This page licensed CC-BY 4.0 Ian Barland
Page last generated Please mail any suggestions
(incl. typos, broken links)
to ibarlandradford.edu

securing passwords in a database

Securing the data stored in the database.

Salting the hash

securing passwords
in a database