Encrypting data in POST

Question

I want to create a authentication mechanism in which the client side is JavaScript and it fetches the password and username from the client and post it to the CGI Perl script.

The problem is that the username and password is free text. I want to make it encrypted or hashed but at the CGI I want to check it so I need the password again.

Any ideas?

Answer 1

You might want to consider using an https connection. This solves your problem with having to encrypt/decrypt data yourself (but instead requires some effort to set up).

Answer 2

This is in response to comments suggesting client-side encryption, not HTTPS.

---

It is important to consider what you are protecting from whom.

Server side

Server side hashing is important to buy time should the database be compromised.

From the view of the server/the CGI script, you receive some form of authentication token, which you want to validate.

Comparing the token with stored plaintext is dangerous, if somebody else can access the plaintext database. This is insecure if somebody else has physical access to the server, access to backups, or can run software on the server. Even then, faulty configuration or unknown exploits could expose the plaintext passwords.

Therefore, some kind of (non-reversible) hashing has to occur on the server side. MD5 is not a viable solution. Actually, no “fast” hashes (incl. the SHA algorithms) provide good protection any more: they are opimized for fast and secure integrity validation, not for making password cracking as difficult as possible. This can be mitigated by repeated hashing/key stretching (see WP article). It is also important to include random “salt”. Do not consider “optimizing” here.

Transportation

Transportation encryption protects against snoopers.

The secret access token has to be transferred securely from the client to the server. This is usually done via HTTPS.

If the password is hashed in the client, the hashed access token effectively becomes the secret that has to be protected. Visualization:

      CLIENT       | TRANSPORT  | SERVER
                   |            |
password => HaShEd | >>>>>>>>>> | verification that “HaShEd” is valid.
                             ^  | never sees “password”.
  snooper can see “HaShEd”   |  |
  can make malicious request |>>|

This is no different from an unencrypted password. Therefore, any pre-hashed access token has to be encrypted during transport, e.g. via HTTPS. If you use reversible encryption for the password, you have to securely transmit encryption keys. This is a solved problem with asymetric encryption, but if you just use HTTPS you don't have to think about all of this, it happens automatically.

Client-Side encryption

Encrypting on the client side is only sensible when you want to protect a secret from the server. A use case for this is uploading confidential files to a server. If they are encrypted on the client side, the server can be compromised without having the files compromised. For authentication, this does not provide any useful functionality.

All it can do is to lull the user in a false sense of security. The actual secret is just different from the access token the user knows.

---

Beyond passwords, password-less authentication schemes can be used. The most important of these is OpenID (as used with stackoverflow), where you trust a third party identity provider (e.g. Google, Facebook, GitHub) to authenticate the user. You never see the secret, but only get a yes/no message from the identity provider.