11

I am in a bit of confusion as we have been asked to AES encrypt passwords before sending it to the server. The whole website communicates over HTTPS with the server and uses secure cookies.

AFAIK, HTTPS uses an SSL 128 bit encryption (could be 256 bit, not sure) and this happens at the Transportation Layer. I am assuming as long as the client is not compromised, an attack at Presentation or Application layer is not possible. Thus, once SSL encrypted, I think information will reach the server safely.

So is it still required to encrypt valuable information such as passwords at the client side before sending it to the server?

S.L. Barth
  • 5,486
  • 8
  • 38
  • 47
Flying Gambit
  • 213
  • 1
  • 2
  • 4
  • 8
    This has been covered many times before e.g. [this](http://security.stackexchange.com/questions/53594/why-is-client-side-hashing-of-a-password-so-uncommon) and [this](http://security.stackexchange.com/questions/4936/what-to-transfer-password-or-its-hash) – paj28 Aug 10 '16 at 08:40
  • @paj28 I searched with keywords 'HTTPS' , 'encryption' and 'password' before posting this question. – Flying Gambit Aug 10 '16 at 08:52
  • 2
    Keep in mind that there are so many HTTPS certificates around that some prime collision is likely to happens, but breaking HTTPS certificates GCD is not something common humans would do, so unless you run a site with ultra secure requirements (military, government, bank) you are fine with A CORRECTLY CONFIGURED HTTPS. – CoffeDeveloper Aug 10 '16 at 09:47
  • 2
    Also, HTTPS allows many protocols (SSL1-3/TLS1.0-1.2) and a large number of ciper suites. The exact cipher used is based on agreement between the client and server. It can be weaker than "128 bit". – billc.cn Aug 10 '16 at 12:25

4 Answers4

19

Encrypting the password before sending it over HTTPS probably doesn't add more security.

Consider: how is the password encrypted by the sender, and how is it decrypted by the receiver?
If you use a symmetrical algorithm, then how did they negotiate the key? If the key is built into the client, anyone who reverse engineers the client will have access to it.
If you use an asymmetrical (i.e. public-key) algorithm, either to encrypt the key or to negotiate a key for a symmetrical algorithm... you're just doing the same that SSL/TLS is doing for you.

Simply use the highest available version of TLS, with the longest key that your server and clients both have available.

Just for completeness: HTTPS uses SSL/TLS. It originally stood for "HTTP over SSL". Nowadays SSL has been found vulnerable, and you should use its successor TLS.

On the server, you make a hash of (password + salt value). There is a lot of information about how to do safe web-based authentication on Stack Overflow's Definitive Guide to Form-Based Website Authentication.

S.L. Barth
  • 5,486
  • 8
  • 38
  • 47
  • 4
    And just for completeness: Passwords need to be cryptographically protected (not encrypted - e.g. bcrypt) before storage, but that is on the server. – AviD Aug 10 '16 at 07:19
  • Does this also mean that there is no need to take a hash of input password and compare against the existing ones in database ? – Flying Gambit Aug 10 '16 at 07:33
  • @FlyingGambit That's what you do on the server. You also add salt. I've updated my answer, added a link to Stack Overflow's canonical question about website authentication. – S.L. Barth Aug 10 '16 at 07:37
  • No need to discuss any encryption details here. The script used to do the encryption is downloaded via HTTPS. If the HTTPS connection is compromised, the attacker can do anything to the password. – billc.cn Aug 10 '16 at 12:28
  • 1
    [TLS is essentially a marketing name change. It's SSL v3.1+ internally.](http://security.stackexchange.com/a/5127/24065) – OrangeDog Aug 10 '16 at 13:15
5

Generalising Frederics answer a bit, there could be a need for encryption of the password at the client if the solution does not use HTTPS end-to-end in the credentials data flow.

Some reasons for not using end-to-end HTTPS are:

  • The HTTPS is terminated at some edge server such as a load balancer or reverse proxy, with plain HTTP between the edge server and the final destination server (Frederics situation would be another example of this).
  • The requests are held at rest at some point in their flow, such as in a message queue for load-levelling

In this case, it could make sense to use message level encryption as you describe.

Mike Goodwin
  • 2,151
  • 1
  • 11
  • 13
2

I have seen such requests from clients who were sold the concept of end-to-end encryption for the passwords.

The setup is the following: there is a dedicated server that validates the passwords and other credentials, and nothing else. The server that hosts the application delegates the authentication to that dedicated server, passing the encrypted credentials.

The HTTPS encryption stops at the application server, but the encrypted credentials are still protected until they reach the authentication server.

Now I'm not sure that makes a whole lot of sense, but as I said I've met clients who request such a thing.

Frédéric Dumont
  • 121
  • 2
1

Usually a software architecture consists of a frontend, a middleware (for business logic) and a backend (e.g. database) and all those components process the password. An attacker who has compromised one of those components would be able to intercept passwords.

One mitigation is to encrypt passwords. With public key encryption the following scenario would be possible:

  • the backend creates a public and private key
  • the public key will be included into the form where the user enters his password
  • when the user submits the form a JavaScript code encrypts the password using the public key
  • the frontend receives the encrypted password, sends it to the middleware which sends it to the backend
  • only the backend can decrypt it

Thus, an attacker who compromised the frontend or middleware cannot see the plaintext password.

DanielE
  • 701
  • 4
  • 10
  • If its an offline attack, cant the attacker just get the password field value from console ? – Flying Gambit Aug 10 '16 at 08:16
  • I'm talking about an attacker in your internal network who could for example attach to processes on servers to intercept data. This is not an offline attack as the attacker uses your system to get the passwords. – DanielE Aug 10 '16 at 09:57