1

I want to use MD5 function (JavaScript library) to hash password before send it to server during logging in to website and during registration proces.

I want to ask is it a secure method? I can't use https, and I wonder if this method will be safer?

If someone has some remarks about this I will be grateful for advices.

ppiatek
  • 13
  • 2
  • 4
    No amount of javascript crypto can stop an active attacker. You can only stop passive attackers, but your scheme is too bad for even that. – CodesInChaos Mar 07 '14 at 10:06
  • There's a comprehensive discussion of the risks on my site: http://pajhome.org.uk/crypt/md5/auth.html – paj28 Mar 07 '14 at 12:48

3 Answers3

1

No, it is not.

First, because MD5.

Second, because an eavesdropper can intercept the hash just like it can intercept the password, allowing them to send the same hash to the server to impersonate the user ("replay attack").

What you could do instead is have the server send an unpredictable, unique string to the client for each login attempt. This is called a "nonce" in cryptography. The client then creates a hash of the password together with that nonce. When nonces do not repeat and each nonce can only be used once, the hashes will not repeat either and replay attacks will be impossible.

But even that will not help when the attacker can not just eavesdrop but also manipulate the traffic. That would allow them to replace your javascript code with their own which sends the unencrypted password to them. No javascript-based scheme would protect you in that scenario.

Community
  • 1
Philipp
  • 48,867
  • 8
  • 127
  • 157
  • This does not help for the registration process. The server has to know the password. – DanielE Mar 07 '14 at 10:14
  • The nonce does not help for the login as well. An attacker could perform a MITM. He could intercept the nonce and replace the JavaScript in the server response by a script which does not hash the password. If the user submits the form the password is transmitted to the attacker. He computes the hash with the nonce and sends it to the server. The attack is not detected. – DanielE Mar 07 '14 at 10:35
  • @DanielE noted. – Philipp Mar 07 '14 at 10:45
1

Your scheme is trivially vulnerable to replay attacks, thus it is not even effective against passive attackers (eavesdroppers).

As already pointed to by others, HTTPS is required to defend against active attacks.

As far as passive attacks are concerned, SCRAM (RFC 5802) is a good password based authentication scheme and it appears it can be implemented in pure JavaScript.

Community
  • 1
Erwan Legrand
  • 401
  • 2
  • 13
0

For password hashing usually bcrypt is used because the time required to compute the hash can be adjusted and bcrypt automatically adds a random salt. Nevertheless, first I'm not aware of a JavaScript implementation of bcrypt, second, even those hashes can be attacked by statistical guessing attacks (try the most common passwords first).

I thought of asymmetric encryption here first. For each login/registration the server creates a unique public/private key pair and sends the public key to the client. The client encrypts the password with this key. Only the server which owns the private key can decrypt the password. But still authentication is missing. An attacker could eavesdrop the communication.

Without authentication, which is provided by HTTPs, it is not possible to secure the registration and login step.

DanielE
  • 701
  • 4
  • 10
  • When the server uses the same keypair for each login attempt, that scheme is vulnerable to replay attacks. – Philipp Mar 07 '14 at 10:10
  • The solution is simple. Generate a public/private key pair for each login. – DanielE Mar 07 '14 at 10:12
  • An active attacker that can send modified javascript to the client to make it leak the password on the way back. That's the problem with client side js crypto, you can't transmit the crypto code securely without having a secure channel in the first place. – Joan Charmant Mar 07 '14 at 10:23