3

  1. What steps must be followed to send password securely from the user registration page (i.e. client side) to the server over a non encrypted channel (http) when the user registers for the first time on the website? (We assume that there exists an intruder in between client and server)

  2. should the password be encrypted with algorithm like AES (requires private key to be shared between client and server which might not be safe) or hashed using SHA2 on the client side before sending it to the server for further hashing using PBKDF2 or bcrypt.

A. Sinha
  • 377
  • 1
  • 3
  • 12
  • 9
    This really is where TLS is for. Why ain't you using HTTPS? Let's Encrypt for example offers it for free. – O'Niel Feb 11 '16 at 16:07

2 Answers2

14

The only safe method for a website to transfer a password to the server is using HTTPS/SSL. If the connection itself is not encrypted, an ManInTheMiddle can modify or strip away any JavaScript sent to the client. So you cannot rely on client side hashing.

You cannot setup a secure connection between client and server on your own, because there is no already shared information. This is like inventing a secret language while the bad guy is listening. That's what SSL is for, if you get an SSL cert for your website from a public CA, then the browsers have built in root certificates for these CA which they use to validate your website. Based on that, the client and server can set up a secure connection.

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
martinstoeckli
  • 5,149
  • 2
  • 27
  • 32
  • "the browsers have built in certificates, which act as an already shared secret" ... uhh, what? Your website needs its own SSL cert, which can be _verified_ using the built-in certificates. But the the build-in root certs do not in any way act as a shared secret. – Mike Ounsworth Feb 11 '16 at 16:31
  • @MikeOunsworth - Todays browsers contain a list of root certificates, which are installed together with the browser. Only with those known root certificates, the browser is able to verify a derrived certificate of your website. If the root certificate where not known to the browser before the connection is up, there would be no way to verify the certificate, because you do not have a secure connection (that's why self signed certificates are not trusted). – martinstoeckli Feb 11 '16 at 16:34
  • Correct, but that's not what you said in your Answer. Your answer says that you _already_ have a shared secret because of the pinned roots, that's .... _misleading_ because you still need to go get yourself a cert. – Mike Ounsworth Feb 11 '16 at 16:38
  • @MikeOunsworth - Well i changed it to _information_, maybe that's indeed more understandable. – martinstoeckli Feb 11 '16 at 16:44
  • ....Making it more generic isn't what I had in mind. I also made an edit. Feel free to revert if you don't like it. – Mike Ounsworth Feb 11 '16 at 16:47
2

The answer here is that it shouldn't be.

The password should be hashed (and salted, and any other algorithms to taste) on the client side, and that hash should be passed to the database. The password should not leave the client-side.

If you want to prevent that hash from being intercepted, then HTTPS or similar to encrypt the channel is required.

Jozef Woods
  • 1,247
  • 8
  • 7
  • 5
    Everything client-side (especially in web-applications) can easily be altered. Security mechanisms like hashing shouldn't be relying at the client-side, but at the server-side. TLS should be used. Besides that, when using a bad architecture you have the risk of the client-side hashed password becoming the actual plain-text password. – O'Niel Feb 11 '16 at 16:13
  • @O'Niel I am performing hashing on the server side as well but the question is about secure transmission of the password in the absence of https. – A. Sinha Feb 11 '16 at 16:24
  • 3
    The problem is that when you hash client-side (hash("pass")) == e.g "ssap", is what you send to the server instead of "pass". When you then do hashing on the server you actually have: hash(hash("pass")) (-> partly client-&server-side) which equals: hash("sapp"). If the attacker can intercept your client-side hash you still have the same security as when you'd use no client-side hash, because the client-side hash just become your new plain-text. But this depends on your architecture and implementation of course. CHECKING if it was hashed would solve a lot for example.TLS should be used anyhow.. – O'Niel Feb 11 '16 at 16:35