How to Safely Store Passwords

[kicken]

Don't you mean 128 Byte Hash? 

 

It's a 64-byte hash value.  When you represent it as a hex string through, you need 2 characters per byte so you need 128 characters.

 

 

And, if I follow everyone's advice, then where are the "weak links" in protecting my User's Passwords?

 

With the proper hashing and salting it's unlikely that someone would be able to determine the password via the hash.  Past that it's just a matter of making sure you prevent a brute-force attack (eg, with a lockout after x attempts), try and get your users to use a non-obvious password (not much you can do there beyond a few rules such has must have letter and number), and make sure your code is secure by validating inputs and sanitizing things.

 

 

[doubledee]

Wow!  What an *intense* thread?!

 

After supper I am going to re-read everything we talked about and try to hopefully get my "create_account.php" and "log_in.php" and "change_password.php" scripts working with this new found knowledge?!

 

(Don't go to bed to early tonight!!)

 

Thanks everyone,

 

 

Debbie

 

[scootstah]

So based on everyone's comments, it sounds like hashing passwords using SHA512 correctly makes it pretty near impossible to hack the passwords??

 

Is that an accurate statement?

 

Not impossible, but very difficult. There is a considerable time and money investment needed to crack it. You would need to allocate a large amount of resources, and frankly script kiddies just aren't going to possess that. So unless you somehow become a huge target, you have nothing to worry about.

 

And, if I follow everyone's advice, then where are the "weak links" in protecting my User's Passwords?

 

If you had a website large enough that someone could gain something by attacking it, then they probably wouldn't first try to crack password hashes. Here's a couple of other ways they may gain entry to someone's account:

- Figure out a way to get malware onto your website which could infect users with key loggers and such

- Phishing or other social engineering to get people to give their password away

- Brute force or using a dictionary attack on the login

- SQL Injection

- Session hijacking

[kicken]

Something to consider if you want to go to the extra effort is having in addition to the password and salt columns, have a hash type column as well.  This way you can update your hash algorithm in the future when a newer better one gets implemented without having much impact on your users

 

So in your table you would have the columns:

passwordHash VARCHAR(or whatever size you want to use)

salt VARCHAR(salt size)

hashType VARCHAR(10)

 

Your passwordHash column stores the hashed password that you compare against.  The salt column stores your user-specific salt value, and your hashType column stores a value representing the hash algorithm in use (eg, 'sha512')

 

When you validate a login you would select the passwordHash, salt, and hashType columns, then use a switch statement to apply the appropriate hash before comparing the entered password to the stored hash.

 

This allows you to update your hash algorithim (say to sha1024 if it gets created) but still allow your current members to login using their current credentials and the old hash method.  Whenever someone does login, you can silently update their hash in the database to the newer algorithim by re-generating the hash using the value they entered.

 

[KevinM1]

I like using a unix timestamp as salt.  It's easy to generate, is useful in and of itself (it's not uncommon to want to know when a user registered for a site), and doesn't advertise itself as a salt column.  It's also generally unique for every user (unless you have two users who registered at precisely the same time, which is an incredibly rare phenomenon).  It's a nice solution for those small-to-moderate sized sites.

 

I've heard of this before, and think you have a good idea!

 

Dumb question, but how do I get the Unix Timestamp in PHP?

 

And how do I convert it to a format that is more agreeable with a Salt?  (e.g. 123456)

 

Lastly, is there a way to "guarantee" that a Salt or Hash is unique by possibly appending an incremental value on the end, or would I not want to do that?

 

Thanks,

 

 

Debbie

 

 

You wouldn't generate the timestamp in PHP, but rather in SQL during the user registration insert (escaping and validation left out for brevity):

 

$query = "INSERT INTO users ('username', 'password', 'date_joined') VALUES ('{$_POST['username']}', SHA2(CONCAT({$_POST['password']}, UNIX_TIMESTAMP()), 512), UNIX_TIMESTAMP())";

 

The password is built by concatenating the timestamp to the entered password:

 

CONCAT({$_POST['password']}, UNIX_TIMESTAMP())

 

In PHP, that would be:

 

$_POST['password'] . /*timestamp*/

 

That is then passed into MySQL's version of SHA-512.

 

UNIX_TIMESTAMP(), when used without arguments, returns the number of seconds since the epoch.  No tweaking required.  Even better, when returned from a SELECT query, it plays nicely with PHP's date/time functions.