Jump to content

Is sha512 an acceptable encryption algorithm for passwords?


DeX

Recommended Posts

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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)?

Link to comment
Share on other sites

 


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.

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.