Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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?

like image 345
dinesh senartne Avatar asked Nov 08 '10 06:11

dinesh senartne


People also ask

Should passwords be hashed client side or server side?

There have been discussions in the past about whether to hash on the client or on the server, and the general consensus is to hash on the server. If a hash is calculated on the client, the client authenticates to the server by submitting their hash. The server then compares the hash to the database entry.

Should password be encrypted in frontend or backend?

Frontend or Backend? The backend. If you only hash them in the frontend, you are vulnerable to a pass the hash attack. The reason that you hash passwords in your database is to prevent an attacker who already compromised your database from using those passwords.

Why is client side authentication a poor choice for security?

Since a web server can be connected to by anyone you cannot trust anything that comes in. Any security that might have happened on a client has to be done over, because some attacker might easily bypass that security.


1 Answers

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

like image 121
Gareth Avatar answered Sep 22 '22 04:09

Gareth