0

I am creating a PHP website where users, among other things, can login and do administrative stuff. For their passwords i use password_hash($password) and to later verify with it, I use password_verify($password, $pass_from_db).

Since PHP is a server-side language, the password, before reaching the server is, in both cases, vulnerable for sniffing, and since they are cleartext, easy to take and use by man-in-the-middle attacking. Since I am going to use Ajax JS, I figured I would use a JavaScript encryption first, and then send the JavaScript encrypted value over the internet, and then create the password hash on the encrypted value like this:

HTML | password = "1234" | -> JS | encrypt("1234") = "ASU'2j3)k" | -> PHP | password_hash("ASU'2j3)k") = "AlD23J'#sC5"P" | -> Inserted in db

HTML | password = "1234" | -> JS | encrypt("1234") = "ASU'2j3)k" | -> PHP | password_verify("ASU'2j3)k", "AlD23J'#sC5"P" - 'Gotten from db') | ACCEPTED

Is this a good idea, or should I just send the password as cleartext?

Tayler
  • 3
  • 2

1 Answers1

3

You can, but you shouldn't. It doesn't increase security, since the client side encrypted password becomes the point of attack.

The other problem with client side encryption is that if you aren't using an encrypted channel to deliver the code, there is no way to prevent it from being tampered with en route - an attacker could simply modify it to send the raw password to them as well as the encrypted one to you.

The best practice for this situation is to use an encrypted channel to send the authentication details - https, in other words. This ensures that only your server can read the password, and then you can check it in your server side code.

Matthew
  • 27,263
  • 7
  • 89
  • 101