Are there any severe concerns of sending the user's login and password with each HTTPS request?

Question

Due to certain requirements/constraints, I'm wondering about sending user login and password with each request.

This somehow doesn't feel very good to me, though I think for my particular case, it could make sense: it would reduce the number of HTTP requests , reduce the latency and simplify frontend code.

Here is the situation:

• Traffic to server comes from a mobile app
• All the traffic goes through HTTPS
• We keep user credentials encrypted in the device storage to log users in automatically on each app boot
• Server side session timeout is very low (few minutes) and is beyond my control
• The DB is beyond my control; I can not add anything to the DB easily and quickly (it would be quite a challenge to get a DB field if e.g. I wanted a long-lived session token)
• The traffic in the app usually happens in batches
• The typical traffic batch within the session timeout is just a few HTTPS requests
• Since the traffic comes from mobile app, sending "keep session alive" requests is not always possible; if the user kills an app and relaunches a few minutes later (or minimizes for a few minutes), there's no possibility to keep the session, and I need to relogin the user.

So, the typical traffic pattern currently is:

#USER OPENS THE APP
POST /autologin    -> response: [ok, here's the new sessionid]|[auth failure, maybe the password changed since]
#SUPPOSING AUTH WAS OK; USER BROWSES AROUND THE APP
POST /someAction1
POST /someAction2
POST /someAction3
#USER IDLE FOR A FEW MINUTES
POST /keepSession
...
#USER MINIMIZES THE APP
#USER RELAUNCHES THE APP, MAYBE SEVERAL MINUTES LATER, MAYBE NEXT DAY
POST /someAction4  -> response: sessionTimeout
POST /autologin    -> response: [ok, here's the new sessionid]|[auth failure, maybe the password changed since]
#SUPPOSING AUTH WAS OK; USER BROWSES AROUND THE APP
POST /someAction4
...

So anyway, on average, I have to send the login request quite often once the session expires; significant percentage of requests are login requests.

If I send login and password in each request, I can

• get rid of /autologin requests at the boot
• get rid of /keepSession requests every few minutes while user is active
• get rid of /action -> /autologin -> /action combo in case of session expired; down from 3 request to just 1

I could just always send both the sessionid and login+password, then on backend reuse sessionid if still valid, otherwise create a new session using the login and password, and do whatever I wanted within the same HTTP call, without the need to play ping-pong between frontend and backend.

To sum up, from my perspective:

Cons:

• I'd have to take care on backend to not accidentally log user credentials in multiple request handlers, not just a one (login handler)
• it could increase the number of requests with login and pass in payload maybe by a factor of N =~ 4,

Pros:

• overall number of HTTP requests done by server decreased by some 20%+
• no need for frontend logic to maintain the user session; just shoot every request with credentials. If it fails due to auth issue, log out the user.

Knowing that the traffic is HTTPS encrypted, are there any severe downsides to my always-send-login-and-pass aproach?

Answer 1

Unless you build in your own security mechanism (which is generally ill-advised) you'll be relying on the security of SSL to protect the authentication. Generally this is done with some form of token that if captured can be used to replicate the login. So an attacker that can break SSL can also capture your session key, and take over your existing session.

There's a couple differences between a session key, and a username/password. The first is that the session key will eventually time out, while a username/password lives for a much longer time. Generally this is considered a minor security advantage because an attacker merely has to be timely in using the captured session key. A larger difference is that the password can be used to authenticate again when a critical action is taken, such as transferring money in the account, or changing the password. In this case capturing just the session isn't useful, since the attacker would need to capture the password as well.

Even in a session key secured scenario, the username/password is still sent once per session. If the attacker can completely break the SSL session, then he can capture the initial username/password exchange.

Now, breaking SSL doesn't have to mean a complete break. There are potential partial break scenarios where a break of SSL might be more vulnerable to sending the username/password many times vs just once per session.

The bottom line is that using a session key is a bit more secure (if done correctly) than sending username/password every time. You need to balance this security with the rest of your backend needs. But understand that no matter what you're doing, you're still relying on the security of SSL.

Answer 2

In addition to @Steve Sether's answer, most modern browsers are able to detect MITM attacks which may be used to compromise the session key by checking the certificate(s) of the server.

If you use TLS and allow only valid certificates then the approach described does not impact security. Also, the session key and your web session are two different things meaning that the lifespan of the session key is independent of the web application session created between the app and the server.

The session key ensures forward security in a sense that compromising the current key is not useful in decrypting future or previous sessions. Thus you could reinitialize the TLS session at the average rate of which the web session expires and send the username/password at half that rate for safety.

Answer 3

Sounds like a bad idea to me.(the below is just my opinion)

If you are sending the username/password with every HTTP(s) request, there is a chance that some bits in the encrypted data might not change. so, I'd assume that if enough HTTPS requests(in the thousands or even millions) are captured, then there is a chance for an attacker to impersonate a client.

If you compare an unencrypted HTTP HEAD request sent by a client with another one sent by the same Client to the same server, they are not that different at all. so, if an attacker can capture enough of these in the HTTPS Stream, though encrypted the attacker can still guess the other bits and craft his own packet to impersonate the client.

This is also one of the reasons why one must expire cookies after a period of time, so that it is hard for an attacker to collect enough requests that are similar.