| ITEC 325 |
| 2017fall |
| ibarland |
|
|
|
home—lects—hws
D2L—breeze (snow day)
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
|
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
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.
Solution:
except, php on rucs...:Unfortunately, rucs’s old verion of php does not support the functions below, so there you have to generate a salt, and store it, yourself.The function
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.
home—lects—hws
D2L—breeze (snow day)
| ©2017, Ian Barland, Radford University Last modified 2017.Nov.13 (Mon) |
Please mail any suggestions (incl. typos, broken links) to ibarland  radford.edu |
 |