Is encryption of passwords needed for an HTTPS website? [duplicate]

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.