Web Site Logon Persistence Cookie Scheme



1. Cookie is fragile. Cookies are vulnerable to theft and crash script attacks. We must accept that cookies are insecure.
2. Persistent login cookies enable them to authenticate through the website. This is the same as login with username and password.
3. It’s more dangerous to recover password design from login cookies than not.
4. Binding persistent cookies to IP makes them not persistent most of the time.
5. Users may want to persist cookies on multiple browsers and machines at the same time.


First, the cookie consists of a user name, a delimiter, and a large random number (128 bits are the ideal acceptable length). There is a table on the server that holds the relationship between the random number and the user name to verify that cookies are legal. If the random number and username provided by cookies correspond to those stored on the table and do not expire, the user can be logged in. Table structure:

Copy codeThe code is as follows:
id username token  expire_time
1 foo 598433213…..8766688 2012-09-21 00:00:00
2 bar 435435997…..4354564 2012-09-22 11:00:00

Sometimes, a user name may correspond to multiple random numbers. In addition, although unlikely, it doesn’t matter if two user names correspond to the same random number.

When a persistent cookie is authenticated, the random number used to log in is invalidated, and a new cookie (generating a new random number and updating records in the database) needs to be assigned to the user. The session lifecycle is then handled with a standard session management mechanism, and the newly set cookie is not checked until the session ends.

The server does not need to specifically prevent a previously used random number from being reused. The probability is very small, and nobody knows how to use it even if it happens.

When the user exits through the exit function, the random number in their current cookie expires. Users should also be able to choose to clear all persistent logins recorded by the system.

The database periodically cleans up those outdated records (a session-like GC mechanism).

The following functions are not allowed to be used by users logged in through cookies:

Copy codeThe code is as follows:
* Modify password
* Modify the user’s mailbox (especially if the password retrieval mechanism of the system is based on the mailbox)
* Sensitive information of any user
* Any function that needs to be paid


If a user’s login cookie is attacked, the attacker can use the functionality of the site as that user. This is unavoidable with cookies! Nevertheless, the attacker should not:

Copy codeThe code is as follows:
* Access to user sensitive information
* Spending User’s Money
* Reset user password
* Prevent users from receiving notifications from websites in the name of users
* Share stolen cookies to others

Recommended Today

Implementation of PHP Facades

Example <?php class RealRoute{ public function get(){ Echo’Get me’; } } class Facade{ public static $resolvedInstance; public static $app; public static function __callStatic($method,$args){ $instance = static::getFacadeRoot(); if(!$instance){ throw new RuntimeException(‘A facade root has not been set.’); } return $instance->$method(…$args); } // Get the Facade root object public static function getFacadeRoot() { return static::resolveFacadeInstance(static::getFacadeAccessor()); } protected […]