Uso de cookies para mantener la persistencia de un login

A mis alumnos, en la Práctica 9: PHP 2 (cookies y sesiones) les pido que implementen la típica opción de “recordarme” que existe en muchos sitios web. Las cosas que uno ve son muchas veces sorprendentes, pero pocas veces veo algo que realmente sea correcto… el guardar directamente el nombre de usuario y la contraseña en una cookie no es muy seguro 🙂

Sobre este tema no hay mucha información. He intentado averiguar cómo lo hacen sitios web como Google o Facebook, pero no encuentro información sobre ello. ¿Alguien lo sabe?

Lo mejor que he encontrado es el artículo Persistent Login Cookie Best Practice. La solución que propone es fácil de entender e implementar:

The cookie should consist of the user’s username, followed by a separator character, followed by some large random number (128 bits seems mind-bogglingly large enough to be acceptable). The server keeps a table of number->username associations, which is looked up to verify the validity of the cookie. If the cookie supplies a random number and username that are mapped to each other in the table, the login is accepted.

At any time, a username may be mapped to several such numbers. Also, while incredibly unlikely, it does not matter if two usernames are mapped to the same random number.

A persistent cookie is good for a single login. When authentication is confirmed, the random number used to log in is invalidated and a brand new cookie assigned. Standard session-management handles the credentials for the life of the session, so the newly assigned cookie will not be checked until the next session (at which point it, too, will be invalidated after use).

The server need not make the effort of deliberately trying to avoid re-assigning random numbers that have been used before: the chance of it happening is so low that even if it did, nobody would know to make use of it.

When a user logs out through some deliberate logout function, their current cookie number is also invalidated. The user also has an option somewhere to clear all persistent logins being remembered by the system, just in case.

Periodically, the database is purged of associations older than a certain time-period (three months, perhaps: the size of the table would be far more an issue than any possibilities of collision in a 128 bit random space).

The following user functions must not be reachable through a cookie-based login, but only through the typing of a valid password:

• Changing the user’s password
• Changing the user’s email address (especially if email-based password recovery is used)
• Any access to the user’s address, payment details or financial information
• Any ability to make a purchase