I was reading this question about Session ID Hijacking

and it gave a lot of answers about stealing Session IDs. I have been thinking about this for awhile, but is there a benefit to using Session IDs over re-logging in with a UN/PW combo, or vise-versa? It seems to be that the issue with Session IDs is that it could be guessed, as well as it sometimes is shown to the user in the URL line with the Type of Session i.e., JSESSIONID for Java server sessions.

I am curious if re-sending UN/PW information to log in would be "safer" or not? I would assume that since it's already being sent once, that storing it in an application/cookie, and then reusing it later could be beneficial, but maybe that leaves the PW/UN being open to stealing as well?

My question is, is there a benefit to either approach? Would one work better or not? Thanks.

2 Answers 2


Resending your username and password is a much greater security risk and has no benefits over session ids (or some variation of access tokens) that I can see.

Losing a password has greater impact

Here's why: If your session id is hijacked, your attacker will have access to your session, which is bad enough. But if he gets your username and password, he can impersonate you to the service for as long as he wants (because usually passwords don't expire, unlike sessions), he can reset your password and lock you out of the service etc. Also, since a lot of people reuse passwords on other sites, getting your password might also compromise your accounts on countless other sites. He can't do any of that if he only has the session id. So it's better to expose the short-lived, localized session id to risk than the long-lived username and password.

Ideally, the password would never be transmitted over the network at all (there are schemes which avoid sending the password, and most browsers and web servers are capable of using the simpler ones (google digest authentication, for example), but unfortunately, developing this technology has been neglected in favor of implementing server-side login systems using nice-looking login screens, which require transmission of the password.)

Session hijacking is (should be...) hard

Stealing a session id isn't so easy. Guessing session ids is very difficult (trillions of times more difficult than guessing the average password) if the application generating them is doing it right. Session ids should be created as long random strings using a crypto-strength random number generator; and since most sessions are only valid for a few hours at most, there isn't much time to make a lot of guesses. Passing session ids as GET parameters in the URL is a problem, yes, but this should be done only to degrade gracefully when the user's browser doesn't accept cookies. Most session ids are passed using cookies which live in the header of an http request.

Federated authentication and authorization

Finally, resending the username and password is often simply impossible, since they might not be available. If you use federated authentication an authorization systems such as OpenID/OAuth, you don't have access to the user's credentials; you just get an access or id token (or both), which are a kind of notarized letter to prove that you are who you say you are and should be given access to a certain resource. Again, the access tokens are only valid for a few minutes up to an hour, and only for a specific resource, so even if an access token was stolen, the damage someone could do with it would be limited.

With OAuth, you can request a special kind of token called a renewal token which you can use to get a new access token without the need to have the user log in again when the old access token expires. So this comes close to your question about resending the login credentials, because if the renewal token is stolen, the attacker gets almost indefinite access to the service the token is meant for. But note that even when a renewal token (which is typically kept out of the reach of user agents by a server) is stolen, this doesn't compromise the user's password and all the other sites he uses his account for.

Restful APIs

Unlike websites that allow a user to sign in, APIs are often stateless. So the client must authenticate with every request he makes to the API. This can be done by sending the username and password every time you make a request, but many APIs solve this by having a client first get an access token using his credentials, an then use the access token to access the API. OAuth is a perfect example for this. So again, the password is only sent once per "session" to get an access token.


Because of captcha.

If sending password is allowed and expected, what protect hackers from trying out your credentials?

  • Welcome to the community. Would be please kindly elaborate what role CAPTCHA here plays?.. Commented May 27, 2023 at 17:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .