Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a simple login form where a user enters their username and password. When php receives the vars via POST, it encrypts the password to md5, then compares it with the database records.

My question is: would it be more secure to encrypt the password with javascript in the browser, before the variables are sent? I know it isn't a foolproof method, but would this prevent people network sniffing my passwords? Or does this make the passwords more vulnerable in any way?


btw the script i'll be using to encrypt to md5 is here:

share|improve this question

Using JavaScript to hash the password before sending over the wire is the very least I would expect. It would be nicer yet if you used CRAM-MD5, HTTP Digest, or SSL (experts have spend thousands of hours pouring over the security implications of these protocols).

You absolutely must use salt. If you do not the passwords are easily reversed using rainbow tables. A very simple salt that works fairly well, have the server send a random salt with the page. MD5 the password, then MD5 the first hash and the salt together. On the server side you can store the MD5 password, and run a quick MD5 on the stored hash and the salt from the page; compare and authenticate appropriately. This sort of salt is known as a nonce. You should also add a long realm salt to both the original password and the one stored on the server.

So a "good" way to go (short of SSL and the others mentioned above) is:

A = MD5 ( Password + Realm)
B = MD5 ( A + Nonce)

Send B over the wire. Keep A stored on the server. When setting A in the first place use a simple reversible encryption like ROT or XOR. Personally I would consider anything less than this irresponsible because so many users foolishly use the exact same password for darn near everything (even Jeff - site founder - has done this).

share|improve this answer
ROT and XOR is not encryption, it's closer to a kind of encoding – Matt Dec 7 '10 at 1:34
@Matt, how are XOR and ROT not encryption? – Chris S Dec 7 '10 at 1:36
@Chris S The algorithm or cipher does not use a key. That's why I call it an encoding. – Matt Dec 7 '10 at 1:47
@Matt, Say what?! Both XOR and ROT need keys. ROT commonly uses 13, but I didn't specify that, it could be specified by the something that changes, like the length of the username for example. XOR would need some sort of key, it can't operate on a single input. – Chris S Dec 7 '10 at 1:50
Trying to build your own encryption is almost never a good idea. Ninety-nine times out of one hundred you would be better off just using https. – Zoredache Dec 7 '10 at 8:20

No. Don't do this. Force the use of SSL in the login screen then you'll know that the username/password are encrypted when sent.

Then, when the password is received by your PHP application, it can MD5 or SHA1 hash the password and store that.

To login, hash the received password and compared with the hashed stored password. If they match you allow the user through.

By the way, to prevent a dictionary attack on your password database you will want to "salt" the password before hashing. See:

share|improve this answer
You know Server Fault doesn't use SSL, right? Are you saying they shouldn't do that either? – Chris S Dec 7 '10 at 1:38
That's a bit different, they use OpenID. – Matt Dec 7 '10 at 1:42
How specifically is that different? – Chris S Dec 7 '10 at 1:44
@Chris, Server Fault does not store the password it's stored on an openid server e.g gmail or one of the others. When you authenticate you're logging in initially via that system which is normally over SSL The exchanges that occur authenticate you with your website. See: – Matt Dec 7 '10 at 1:59
I am saying they SE should be converting to HTTPS when possible. From a security standpoint I would be extremely happy if everyone started using https for everything. Yes, there are some performance issues, but if Google can handle SSL for everything, shouldn't everyone else be able to handle it? – Zoredache Dec 7 '10 at 8:18

If you use salt on your hash, the sniffer can easily visit your page and obtain your hash from your javascript. Also, md5 is not exactly secure in the sense that it's not collision proof. So don't do this, just use SSL if it's really sensitive.

share|improve this answer
well, its not reeeealy sensitive, but i would like some sort of security so no-one could just see all the passwords, would encrypting them using md5 help my cause some what? – Mickwaffle Dec 7 '10 at 1:25
@Mickwaffle, don't take short cuts. Especially where other peoples data is concerned. – Matt Dec 7 '10 at 1:37
First, if you salt the hash and a "sniffer" can get the salt from the page, then you're doing salt wrong. Salts should be random and unique every time. Second, everyone says md5 is horrible because it isn't collision proof. While I'll grant that the sha algorithms are now better, to me it sounds as if very few people understand just what 'collision' means in a practical sense. – Slartibartfast Dec 7 '10 at 6:00

It's not not secure from people sniffing the network.

Just think about it when user need to connect there javascript hashes their password and send them to the server. The server compares it to the database.

A sniffer would only have to sniff the password and send it to the server so this is as secure as clear text password.

As others said I recommend SSL/TLS tunnels to be establish to connect to your server.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.