5

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?

Thanks.

btw the script i'll be using to encrypt to md5 is here: http://www.webtoolkit.info/javascript-md5.html

Mark Henderson
  • 68,316
  • 31
  • 175
  • 255
Mickwaffle
  • 51
  • 1
  • 2

4 Answers4

4

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

Chris S
  • 77,337
  • 11
  • 120
  • 212
  • ROT and XOR is not encryption, it's closer to a kind of encoding – hookenz Dec 07 '10 at 01:34
  • @Matt, how are XOR and ROT not encryption? – Chris S Dec 07 '10 at 01:36
  • @Chris S The algorithm or cipher does not use a key. That's why I call it an encoding. – hookenz Dec 07 '10 at 01: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 07 '10 at 01:50
  • @Chris. I concede that you could call it super trivial encryption. But few people would dare to use either operation as a form of encryption. It'd be broken quicker than you could add 1+1. It's barely better than being in the clear. – hookenz Dec 07 '10 at 02:06
  • 1
    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 07 '10 at 08:20
2

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: http://en.wikipedia.org/wiki/Salt_(cryptography)

hookenz
  • 14,132
  • 22
  • 86
  • 142
  • You know Server Fault doesn't use SSL, right? Are you saying they shouldn't do that either? – Chris S Dec 07 '10 at 01:38
  • That's a bit different, they use OpenID. – hookenz Dec 07 '10 at 01:42
  • How specifically is that different? – Chris S Dec 07 '10 at 01: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: http://www.windley.com/archives/2006/04/how_does_openid.shtml – hookenz Dec 07 '10 at 01: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 07 '10 at 08:18
  • As a user of your site, I do not want to trust you with my plain text password. I don't know if you are storing the passwords securely, filing them away for later use by teams of crackers or publishing them on twitter! – Steven Shaw Aug 04 '14 at 23:30
1

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.

Andreas Wong
  • 219
  • 3
  • 10
  • 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 07 '10 at 01:25
  • @Mickwaffle, don't take short cuts. Especially where other peoples data is concerned. – hookenz Dec 07 '10 at 01: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 07 '10 at 06:00
1

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.

Gopoi
  • 547
  • 5
  • 21