11

Whenever I connect to security.stack.exchange, I am automatically logged in. I haven't allowed the browser to store my password. When I delete all cookies stored by the security.stack.exchange, I have to login by myself by entering username and password. Therefore, I concluded stack.exchange must be storing either a unique identifier or passwords in cookies which enable the automatic login.

When I checked cookies stored by Stack Exchange, I found the content of cookie named "security user" containing t="something"&s="something". Is this my username and password? Are the passwords saved in the cookie encrypted?

Using chrome browser, I found there are 3 cookies stored by stackexchange.
i. "gauthed"
ii. "security user" containing t=""&s=""
iii. "sgt" containing id

Deleting the cookie "sgt" which I believe stores my unique identifier, i am still logged in automatically. Therefore, I am suspicious about the cookie "security user".

Also, if I haven't allowed my browser to store my password then why should a website store the login information without my consent. Is this a right behaviour?

  • 3
    Why would the actual password be stored in a cookie? You want some kind of identifier there but I see no reason to use the password for that. – Hennes Nov 13 '14 at 4:15
  • 1
    Why do you go from speculating about a UID or password, then settle entirely on a password? Why haven't you also advanced thoughts about the UID? – schroeder Nov 13 '14 at 16:11
  • 1
    @Hennes While this is not how SE does it, there are sites that do in fact store credentials in cookies as a part of their "Remember Me" function. In plain-text in some cases, even. So, while ultimately not the case here, it's not an entirely unreasonable question. – Xander Nov 13 '14 at 17:27
  • 1
    "Remember Me" is more and more switching to "localStorage" than cookies as HTML5 becomes more used. Many are using that method and storing the credentials in plain text from the mistaken belief that is it more secure than a cookie. Tokens and server side sessions are preferable always. – tremor Nov 14 '14 at 14:50
20

Usually, the password isn't stored in the cookie. You login to example.com with your username and password, these are verified to belong to you (typically by hashing your password and checking the hash of your password matches with the hash for a user with that username), and the server issues you a long random number token as a secret identifier for you.

Say they choose 24 random characters from 62 characters (26 uppercase letters, 26 lowercase letters, 10 numbers). They store this identifier in their database as being valid and associated with you. Every time you make a request while logged in - you send the cookie to your website. Every time there is a request sent in with this identifier, they look up if its associated with a valid logged-in user, and if it is they give the information about that user.

There are 6224 ~ 1043 ~ 2142 possibilities. If your website has a billion (10^9) signed in users at any moment who were issued tokens, you'd have to try roughly 10^37 possibilities until you'd be lucky enough to randomly guess one. (If each try takes 1 nanosecond, it would take you about 1011 billion years before you were lucky to guess a valid token).

Your session cookie is typically only valid for a certain amount of time, which will also be stored in the server side database.

There are other variations on this theme, e.g., using HMAC (hash message authentication codes) with a stored timestamp based on a server-side secret. That is when you login the server gives you a timestamp as well as a strong hash of that timestamp and your username that is combined with a server side secret. That is you the server calculates h=HMAC(secret + timestamp + username) when you login, gives you back the calculated h -- and then you send (h, username, and timestamp) as your login information. (And the server takes your username and timestamp, recalculates h and compares it to the h you gave, and makes sure the timestamp is still valid and not very old).

Now I am not particularly familiar with the particulars of how stackexchange does it (e.g., what the t=...&s=.... part of the .security.stackexchange.com), but its probably a variation on this scheme. That is it does not encrypt your username or password in a recoverable way -- it either is stored in a database or is based on one-way hash function that relies on a server-side secret.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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