Password encryption at client side [duplicate]

Possible Duplicate:
About password hashing system on client side

I have to secure the passwords of my web site users. What I did was use MD5 encryption hashing in server side. But the problem is the passwords remain in plain text until it arrives at the server, which means that the password can be captured using traffic monitoring. So what I want is to use a client side password encryption/hashing mechanism and send the encrypted/hashed password. Can anybody tell what is the way to do this?

Solution 1:

This won't be secure, and it's simple to explain why:

If you hash the password on the client side and use that token instead of the password, then an attacker will be unlikely to find out what the password is.

But, the attacker doesn't need to find out what the password is, because your server isn't expecting the password any more - it's expecting the token. And the attacker does know the token because it's being sent over unencrypted HTTP!

Now, it might be possible to hack together some kind of challenge/response form of encryption which means that the same password will produce a different token each request. However, this will require that the password is stored in a decryptable format on the server, something which isn't ideal, but might be a suitable compromise.

And finally, do you really want to require users to have javascript turned on before they can log into your website?

In any case, SSL is neither an expensive or especially difficult to set up solution any more

Solution 2:

You need a library that can encrypt your input on client side and transfer it to the server in encrypted form.

You can use following libs:

• jCryption. Client-Server asymmetric encryption over Javascript

Update after 3 years (2013):

• Stanford Javascript Crypto Library

Update after 4 years (2014):

• CryptoJS - Easy to use encryption
• ForgeJS - Pretty much covers it all
• OpenPGP.JS - Put the OpenPGP format everywhere - runs in JS so you can use it in your web apps, mobile apps & etc.

Solution 3:

I would choose this simple solution.

Summarizing it:

• Client "I want to login"
• Server generates a random number #S and sends it to the Client
• Client
  • reads username and password typed by the user
  • calculates the hash of the password, getting h(pw) (which is what is stored in the DB)
  • generates another random number #C
  • concatenates h(pw) + #S + #C and calculates its hash, call it h(all)
  • sends to the server username, #C and h(all)
• Server
  • retrieves h(pw)' for the specified username, from the DB
  • now it has all the elements to calculate h(all'), like Client did
  • if h(all) = h(all') then h(pw) = h(pw)', almost certainly

No one can repeat the request to log in as the specified user. #S adds a variable component to the hash, each time (it's fundamental). #C adds additional noise in it.

Solution 4:

This sort of protection is normally provided by using HTTPS, so that all communication between the web server and the client is encrypted.

The exact instructions on how to achieve this will depend on your web server.

The Apache documentation has a SSL Configuration HOW-TO guide that may be of some help. (thanks to user G. Qyy for the link)