{"id":3213,"date":"2014-01-21T09:00:24","date_gmt":"2014-01-21T08:00:24","guid":{"rendered":"https:\/\/blogs.ua.es\/pi\/?p=3213"},"modified":"2013-12-02T11:29:28","modified_gmt":"2013-12-02T10:29:28","slug":"uso-de-cookies-para-mantener-la-persistencia-de-un-login","status":"publish","type":"post","link":"https:\/\/blogs.ua.es\/pi\/2014\/01\/21\/uso-de-cookies-para-mantener-la-persistencia-de-un-login\/","title":{"rendered":"Uso de cookies para mantener la persistencia de un login"},"content":{"rendered":"

A mis alumnos, en la\u00a0Pr\u00e1ctica 9: PHP 2 (cookies y sesiones)<\/a> les pido que implementen la t\u00edpica opci\u00f3n 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\u00f1a en una cookie no es muy seguro \ud83d\ude42<\/p>\n

Sobre este tema no hay mucha informaci\u00f3n. He intentado averiguar c\u00f3mo lo hacen sitios web como Google o Facebook, pero no encuentro informaci\u00f3n sobre ello. \u00bfAlguien lo sabe?<\/p>\n

Lo mejor que he encontrado es el art\u00edculo\u00a0Persistent Login Cookie Best Practice<\/a>. La soluci\u00f3n que propone es f\u00e1cil de entender e implementar:<\/p>\n

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.<\/p>\n

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.<\/p>\n

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<\/em> session (at which point it, too, will be invalidated after use).<\/p>\n

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.<\/p>\n

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<\/em> persistent logins being remembered by the system, just in case.<\/p>\n

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).<\/p>\n

The following user functions must not<\/em> be reachable through a cookie-based login, but only through the typing of a valid password:<\/p>\n