Di solito, la password non è memorizzata nel cookie. Accedi a esempio.com con il tuo nome utente e password, questi sono verificati per appartenere a te (in genere l'hashing della tua password e il controllo dell'hash della tua password corrisponde all'hash per un utente con quel nome utente), e il server ti rilascia un gettone numero casuale lungo come identificativo segreto per te.
Diciamo che scelgono 24 caratteri casuali da 62 caratteri (26 lettere maiuscole, 26 lettere minuscole, 10 numeri). Conservano questo identificatore nel loro database come valido e associato a te. Ogni volta che effettui una richiesta mentre sei loggato, invii i cookie al tuo sito web. Ogni volta che viene inviata una richiesta con questo identificativo, cercano se sono associati a un utente con accesso valido e se forniscono le informazioni su tale utente.
Ci sono 62 possibilità 24 ~ 10 43 ~ 2 142 . Se il tuo sito web ha un miliardo (10 ^ 9) registrati negli utenti in qualsiasi momento che sono stati emessi token, dovresti provare circa 10 ^ 37 possibilità finché non sarai abbastanza fortunato da indovinarne uno a caso. (Se ogni tentativo richiede 1 nanosecondo, ti richiederebbero circa 10 11 miliardi di anni prima di essere fortunato a indovinare un token valido).
Il tuo cookie di sessione è in genere valido solo per un certo periodo di tempo, che verrà anche memorizzato nel database lato server.
Esistono altre varianti su questo tema, ad esempio utilizzando HMAC (codici di autenticazione dei messaggi hash) con un timestamp memorizzato basato su un segreto lato server. Quello è quando accedi al server ti dà un timestamp così come un hash strong di quel timestamp e il tuo username che è combinato con un segreto sul lato server. Questo è il server che calcola h = HMAC (segreto + timestamp + nome utente) quando effettui il login, ti restituisce l'h calcolata e quindi invii (h, username e timestamp) come informazioni di accesso. (E il server prende il tuo nome utente e il timestamp, ricalcola h e lo confronta con quello che hai dato, e si assicura che il timestamp sia ancora valido e non molto vecchio).
Ora non ho particolare familiarità con i particolari di come lo fa stackexchange (ad es., quale parte t=...&s=.... della .security.stackexchange.com ), ma probabilmente è una variazione su questo schema. Cioè non crittografa il tuo nome utente o password in modo recuperabile: o è memorizzato in un database o è basato su una funzione hash unidirezionale che si basa su un segreto lato server.