Is my PHP security algorithm efficiently storing user credentials?

Question

This question is about the specific programming problem that I have - I want to make sure that my code (and software algorithm) is sufficient to store user credentials in the database.

// Get a 32 character salt like '69Mt6nexL1rsjWnu011S53MpB/WmT4Vl' $passwordSalt = Security::generateBase64Salt(); $user = new User(); $user->setUsername($_POST['username']); // $_POST['password'] comes in as a 128 character string // Client side javascript is used to sha512 the string before sending it over POST // see http://pajhome.org.uk/crypt/md5/ // This prevents novice eavesdroppers from capturing the raw password in plaintext $user->setPassword( hash('sha512', $passwordSalt.$_POST['password']) ); $user->setPasswordSalt($passwordSalt); $user->save(); 

Here's the database entry for the specific password:

Password:

69a78a7586a111b8a567b2d4f42f93f01fb59d337f7fa3c35949a66b246095778c1fa01ff4026abace476091e1e9a183bbdec1c31b12ce3f786921895c98cf6f

Salt:

69Mt6nexL1rsjWnu011S53MpB / WmT4Vl

Questions:

• Are there any inherited flaws with this algorithm?
• Is it possible to save the salt in the same database and table as the salt + password hash?
• Will it have a large password with 128 characters due to logon performance issues (for a few seconds) if I have several hundred thousand users in the table?
• Can I change this data to create an initial password?

For pleasure:

I will receive PayPal for you $ 5 if you can provide me with the original password using the salt and salt hash + password.

Answer 1

Are there any inherited flaws in this algorithm?

It is not open to rainbow attacks (due to random salt). Sha512 is a fairly new algorithm, but currently it has no known collisions, so it is probably pretty safe. The way your passwords are stored well. The verification process is also important (limiting attack speed using bruteforce) and blocking servers from attacks from other angles that may try to access the database. If an attacker could gain access to the database, he could probably quickly extract simple passwords, but any complex password would probably be outside of a simple brute force attack (even if he had direct access to hashes).

Is it possible to save the salt in the same database and table as the salt + password hash?

You pretty much have to keep them together if you want to verify passwords (suppose you want to). The main reason for salting a password is to remove the possibility of a rainbow attack. Often this data is even stored in the same column as the hashed password, using a character to separate them.

Will having a large 128-character password cause login performance problems (for a few seconds) if I have several hundred thousand users in the table?

Check how much time (in seconds) it takes to verify the password ( hash('sha512', $salt.$password_attempt ) ). Find the inverse of this number and probably close to how many password attempts you can process per second on the processor core.

Can I change this data to create an initial password?

Yes, but it will take a lot of effort, since you use random salt, rainbow tables will no longer work, and sha512 requires enough CPU to run and has no known collisions. If the password were pretty simple, you could guess it. If you are worried about changing the hashing, a low score for password complexity might be a good idea (checking it for a dictionary, whether it contains upper / lower / digits / characters).

Answer 2

All that Kendall said, and ..

.. Skip the hashing you do on the client side in javascript. Instead, simply acquire an SSL certificate and place your credentials on top of https. Protects you from novice listening devices, as well as experienced intruders.

And besides, as soon as you use the hash on the client side, it will become your password. If the eavesdropper holds a hashed password, it can send it to your server and everything will work.