how to encrypt password at client side when implemented MD5halsh salted algorithm on server side

Question

I have implemented an md5 hash salted algorithm.

Using this algorithm I have saved the hashed password and salt value to the database. then on login page retrieved the salt value of login user, get the byte of password add the salt value and computed hash and matched the result with the saved password and it is working perfectly but I am still able to see my password value in clear text at client side.

How can I encrypt the password value at client side along with md5 hash salted algorithm?

Answer 1

You do it right way. You won't be able hash password on client-side without knowing salt (and passing salts to client is not a good idea). If you want that data sent by client was secure, use ssl .

Note: If you use ssl client will still be able to see my password value in clear text because data will be encrypted only before sending.

Answer 2

You can use data protection API (DPAPI) to store password on the client side securely. Use SafeString class, to store password in memory and, as @PLB already mentioned, use encrypted connection.

Answer 3

If you are worry for password which you are typing in text box. Then change TextMode of textbox as Password

Like this

<asp:TextBox ID="txtPassword" runat="server" TextMode="Password"></asp:TextBox>

Answer 4

There are many different ways to solve this, the easiest I can come up with right now is to use some kind of challenge; the server sends a value the client has to use as a salt. The server ensures that the value is unique, hasn't expired, and only used once (this makes sure a replay attack isn't possible.)

This makes sure that a plain text password isn't sent, only a hashed one. The server can trust (trust as much as when doing plain text auth anyway) the client to not simply resend some old hash since the clear text password is needed to compute the hash with the "one-time-salt".

Another, more sophisticated (and secure) way is to generate a RSA-keypair from the password where the server has the public key, and the client the private. The client also has a copy of the servers public key. The user enters the password, and only the correct password will get the correct rsa-key.

The user then encrypts the requests with the server's public key, and then signs the requests with the user's private key. Only the server can then decrypt the requests, and the server can verify that the sender really is the right user by verifying the sign with the user's public key. And the opposite for the response. To add some security you should add some unique "salt" as I wrote earlier to ensure replay attacks are impossible.