0

I am setting up a website to help people with certain niche interests find each other. It is being done purely as a voluntary project, there is no money involved (on either side), nor is there much personal information stored. The only interesting data we store is the postcode, email address and password (hashed) of each user. All that would be gained by having access to these is the ability to change the user's postcode, which seems to me to be of little benefit to anyone.

However, it has been pointed out that many people use the same password everywhere, so if someone could access the data, they would be able to try the same email/password combination on other sites. Whilst this seems like a small, and probably futile task, we want to reassure our users that we are protecting them.

If we run the site over SSL, then when they register or log in, is there any great benefit in hashing their password in Javascript before sending it to the server? On the other hand, are we exposing anything we shouldn't by doing the hashing in Javascript, where it's open for anyone to see, as opposed to on the server, where it's only visible to people with access to the server (in which case we have other security issues)?

P.S. Please note that I'm not a security expert in any way, so please don't assume any prior knowledge. If I've missed some obvious point, please clarify it or ask for more details, rather than downvoting as a bad question. I did search around, but haven't really found anything that answers this question (although I learnt a lot of other things along the way!)

P.P.S. Please note that this question is specifically related to the register and log in process. There are obviously questions of database security, etc, but they are being dealt with separately.

schroeder
  • 123,438
  • 55
  • 284
  • 319
Avrohom Yisroel
  • 715
  • 1
  • 6
  • 9
  • 1
    Possible duplicate of [https security - should password be hashed server-side or client-side?](https://security.stackexchange.com/questions/8596), [Encrypted password over SSL](https://security.stackexchange.com/questions/135526/), [What to transfer? Password or its hash?](https://security.stackexchange.com/questions/4936/), [Is it safe to send clear usernames/passwords on a https connection to authenticate users?](https://security.stackexchange.com/questions/64631/). – Steffen Ullrich May 28 '17 at 15:01
  • 1
    I'll note, before others do, you should not be encrypting passwords, but hashing them – schroeder May 28 '17 at 15:02
  • @schroeder Thanks for the clarification. We are actually using hashing, but in my naivety, I called it encrypting. I'll edit my question to suit. – Avrohom Yisroel May 28 '17 at 15:47
  • @SteffenUllrich Thanks for the links. I looked at one or two of them, but I think I must have read them too quickly, and thought they didn't apply. Between those and the answer given by lights0123, I have my answer. – Avrohom Yisroel May 28 '17 at 15:51

1 Answers1

1

There is generally no reason to encrypt passwords client-side. Let's consider a situation without SSL first, but with password encryption:

Bob is logging in to his account. He goes to the login page, enters his username and password, and logs in. As Eve is monitoring the exchange, she does not see the password, as it is encrypted.

This would only happen, however, if Eve is only monitoring the connection (which is almost never). Here's what would actually happen if Eve could modify the connection:

Bob is logging in to his account. He goes to the login page. However, Eve intercepts this request and removes the encryption code. Bob enters his username and password, and logs in. As Eve is monitoring the exchange, she does see the password, as it is not encrypted. To make Bob not suspect anything, she forwards the request with the encrypted password to the server and returns the session token to Bob.

In this situation, we can see that encryption is useless when the encryption code can be compromised. It would be useful, however, when the application's code can be trusted (e.g. delivered by a CD and signed by the developer) and the data is exchanged over an insecure connection (i.e. without SSL). This isn't the case with a website over HTTP.

What if this was done over SSL? Well, there would still be no point in encryption client-side. The attacker wouldn't be able to see the exchange, and if it was compromised, then the attack shown above could be used. Also, this raises a point of rolling your own crypto: yes, you aren't making the algorithms yourself, but you are using encryption somewhere where it is done elsewhere. Also, people who have JS disabled or have browsers without the crypto API, the whole thing would not work. The point of how JS may be insecure isn't that serious, as unless specific HTTP headers are sent, JS would be able to grab the password anyways.

lights0123
  • 443
  • 2
  • 6