I'm writing a mobile app & web service combo that requires user to login. The web service will be using SSL, so are there any reasons against sending the user name and password in every web request?

I know some sites generate a token after the user logs in, that they can use for authentication, but the token seems equivalent to the username/password pair - so I'm not sure there's much point in doing that.

Am I about to make a big mistake in terms of security?

2 Answers 2


The major mistake you are doing is increasing the opportunity to grab that username/password pair. Even the way SSL works, once authentication has been established, you negotiate a session key for the current collaboration.

The session key is a very important concept, as it can help determine what is a valid session or not. Take the following scenario for example:

  • User logs in on one machine, does some stuff and then has to leave it. Stupid him, he forgot to lock the terminal and the session is still active.
  • User then logs in on a second machine, and does some more stuff.
  • Nefarious user stumbles upon the first machine, and tries to do stuff.

If you use the username/password combo for every request the server can't detect which machine is which--particularly if they are behind the same firewall/gateway. Using a session key that is negotiated each time the user logs in the server can detect which session is which. In fact, when it is properly implemented, the old session key is invalidated so that any future requests using that session key fail.

For your session keys make sure that the following apply:

  • It is unique for every username/password combination
  • It is unique for each authenticated session
  • Old session keys are invalidated and no longer used. (recycling is only OK when the client session mechanisms will fail anyway. I.e. the cookie expires and the server session expires).

This allows a user to move from one machine to another (logging in fresh on each machine), while doing your diligence to prevent someone stealing their session.


Well usually the token is a md5 hash made from the username, the password, a hidden phrase, and sometimes the date.

Tokens are more secure and cannot be intercepted, specially if they are reissued with each page impression, as the hidden phrase could be the last seen field from the user database that is updated on each impression so its a rolling authentication.

  • It is no better than username/password if the date is not encoded in there. I.e. the token must be at least as unique as each session. If it changes with each request, all the better. Commented Mar 14, 2011 at 17:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.