Is sha512 an acceptable encryption algorithm for passwords?

[DeX]

I'm writing a huge PHP secure login script for a heavily used website so I need to do 2 things securely:

a) transmit the password from the form to the webserver.

b) store the password in the database.

I'm using a JavaScript sha512 function I downloaded in order to encrypt the password prior to sending it to the webserver and I'm storing encrypted passwords in the database using hash("sha512", $password) as an encryption function.

 

Is this good enough? Is there a different encryption algorithm I should be using? The process I'll be using is encrypting with javascript, sending to the webserver, adding a salt and encrypting again for storage.

[vinny42]

There is no point in hashing (SHA is not encryption) the password before sending it to the webserver

for two reasons. one: the hacker can see the javascript and so he knows what you do to create the hash and can reverse-engineer it.

two: yes a hacker cannot see what the password was, but he doesn't have to because your webserver doesn't know the password either, it just needs the right hash

which the hacker can still sniff. the hash becomes the password.

 

If you want to be more secure you should use SSL because that encrypts the entire connection, making it impossible to sniff anything that is sent back and forth. (and then again it

doesn't matter if you hash the password or not

[Psycho]

I agree with vinny42, that if you need to secure the data between the form and the server. Trying to do it with JavaScript creates complexity that could cause breakages in your application. Plus, what if the user has JS turned off.

 

But, as for storing the password, you should NOT do a strait hash. If a malicious user gets the data they can create a "rainbow" table of common words and their hash to find matches. Instead, every password should have a "salt" a unique string for each user that is added to the password before it is hashed. Or, just use an existing hashing framework such as phpass (http://www.openwall.com/phpass/). This is an open source framework. So, many people have reviewed this code for potential flaws giving a higher level of confidence in the overall security of the process than you could do in a custom-built solution.

[Stefany93]

SHA512 is the best hashing function so far in my opinion. Just remember to always salt your passwords before storing them, even after hashing them. No matter what they tell you, without salting your hashed passwords are just a little more secure than plain text. 

[DeX]

Great, thanks, so I'll incorporate SSL, send the unhashed password, then salt and hash it on the server side.

Which things should I be salting with the password for best security? The IP? The browser session ID? Timestamp?

And lastly, should I be storing the salt in the database or should I just use the same method each time (for example every second letter of their name or something)?

[vinny42]

 

Which things should I be salting with the password for best security? The IP? The browser session ID? Timestamp?

 

None of the above, because they can all be predicted by the hacker.

Just like he/she can probably predict that your salt will be prepended or postfixed to the password...

 

 

should I be storing the salt in the database or should I just use the same method each time (for example every second letter of their name or something)?

 

The salt should be different for every user, otherwise finding one password means finding the salt and and finding the salt means you can create a new rainbox list and you'll have found a lot of other passwords aswel.

[DeX]

So just a random string generator for every salt and store it in the user table?

[vinny42]

That's probably good enough; if a hacker can get far enough into your system to get that salt, you've got much bigger security holes than the password :-)

[Psycho]

Hiding/securing the salt is unnecessary. The explanation of why would take a lot of content - but there's plenty of resources on this. The main thing is to ensure that the salt is unique to each user and that it will not change (e.g. don't use IP address unless you are using the original IP of the user and that it will never get updated in the DB).