How to safely include password in query string

Question

Is it possible to safely include a password in a query string for a c# asp.net site.

Few assumptions and things I know -

1. The site does not and will not have links/images/javascript/analytics to/from other sites. So no referrer links to worry about.
2. ALL communication with the web browser will be over https.
3. I know that the query string will remain in the history of the computer.
4. More than just the password/username is needed to login. So simply pasting the url back into the browser will not result in a login.

I know the site may be susceptible to cross site scripting and replay attacks. How do I mitigate these?

Given the above scenario, how should I include a password in a query string?

Please don't ask me 'why', I know this is not a good idea, but it is what the client wants.

Answer 1

SSL

You can safely send the password to a web server using a SSL connection. This encrypts all the communication between the client/server.

Hide In The Header

Basic authentication protocols place the user/password information in the HTTP request header. C# and many other web server languages can access this information, and use it to authenticate the request. When mixed with SSL this is very safe.

Register An Application Key

If none of the above is possible, then it's recommended that you create a unique key for each user. Rather then send their password this key is used. The advantage is that the key is stored in the database and can be removed. The user's password remains unchanged, but they must register again to get a new key. This is good if there is a chance someone could abuse their key.

Perform Hand Shaking

Hand shaking is where the client makes a request to the server, and the server sends back a randomly generated key. The client then generates a hash from that key using a secret, and sends it back to the server. The server can then check if the client knew the correct secret. The same thing can be done where the password is the secret instead and the client includes username details in the request. This can authenticate without ever sending the password.

Encrypt Password

If none of the above are possible options, then you could attempt to use JavaScript to encrypt the password before it's sent via an open URL. I found an open source version the AES block cipher. The project is called JSAES and supports 128 to 256 bit encryption. There might be other JS libraries that do the same thing.

Answer 2

It is generally not advisable to put secrets in a query string, which can then be book marked and copied, exposing the password at-rest in history files, cookies, etc.

To safeguard the password in this use-case, the best option would be to hash the password (one-way, not reversible). In this way, the actual password is not known in transit nor at-rest but... it implies that an attacker can still use said value to login to the server that would presumably compare the hash value to its store for authentication.

A better solution for the use-case of keeping the user session remembered for a reasonable period of time is a simple user-session token (which all application servers like Tomcat etc use).

In this case, the user authenticates with their password (over SSL) but it is never stored. The password is hashed on the server and then compared to a store of password hashes for the user account. If the hash matches, the user is authenticated.

On authentication, the server returns a limited time nonce (token) called a "session ID", which is then stored and re-sent in a browser cookie. As long as the session is valid, the user no longer must re-authenticate and the password is never stored. When the session timeout expires, the session ID token is no longer valid and the user must re-authenticate using the same process.

Two-factor authentication schemes (see Google authenticator) and systems are a much stronger security posture (stealing password is not enough and the keys auto-rotate on external systems) but do require semi-frequent access to the rotating key system, which inhibits a smooth user experience to some extent.