Are passwords stored in the cookie? encrypted?

Question

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?

Answer 1

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 62²⁴ ~ 10⁴³ ~ 2¹⁴² 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 10¹¹ 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.