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.