Persistent login refers to a mechanism for continuous authentication between browser sessions. In other words, a user who is logged in today will still be logged in tomorrow, even if user sessions expire between visits.
The presence of persistent logins reduces the security of your authentication mechanism, but it increases usability. Instead of troublesome users to authenticate each time they visit, provide the option to remember the login.
Figure 7-2. Attacker gaining unauthorized access by replaying user’s cookies
From what I've observed, the most common flawed permanent login scheme is to save the username and password in a cookie. The temptation to do this is understandable - instead of prompting the user for a username and password, you can simply read them from the cookie. The rest of the verification process is exactly the same as a normal login, so this scenario is a simple one.
However, if you do store your username and password in cookies, please turn off this feature immediately and read the rest of this section to find some ideas for implementing a more secure solution. You will also need to require all users who use this cookie to change their passwords in the future because their authentication information has been exposed.
Permanent login requires a persistent login cookie, often called an authentication cookie, because cookies are the only standard mechanism used to provide stable data across multiple sessions. If the cookie provides permanent access, it poses a serious risk to the security of your application, so you need to make sure that the data you save in the cookie can only be used for authentication for a limited period of time.
The first step is to devise a method to mitigate the risk posed by captured persistent login cookies. While cookie capture is something you want to avoid, having a defense-in-depth process is best, especially since this mechanism can make your validation form less secure even when everything is working fine. In this way, the cookie cannot be generated based on any information that provides a permanent login, such as the user's password.
To avoid using the user's password, you can create an identity that is only valid for one-time verification:
CODE: <?php $token = md5(uniqid(rand(), TRUE)); ?>
You can save it in the user's session to associate it with a specific user, but this doesn't help you stay logged in across multiple sessions, which is a big deal. Therefore, you must use a different method to associate this identity with a specific user.
Since the username is less sensitive than the password, you can store it in a cookie, which can help the authenticator determine which user ID was provided. However, a better approach is to use a secondary identity that is difficult to guess and discover. Consider adding three fields to the data table that stores usernames and passwords: a second identity (identifier), a permanent login identification (token), and a permanent login timeout (timeout).
mysql> DESCRIBE users; +------------+------------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +------------+------------------+------+-----+---------+-------+ | username | varchar(25) | | PRI | | | | password | varchar(32) | YES | | NULL | | | identifier | varchar(32) | YES | MUL | NULL | | | token | varchar(32) | YES | | NULL | | | timeout | int(10) unsigned | YES | | NULL | | +------------+------------------+------+-----+---------+-------+
## By generating and saving a secondary identity and permanent login ID, you can create a cookie that does not contain any user authentication information.
CODE: <?php $salt = 'SHIFLETT'; $identifier = md5($salt . md5($username . $salt)); $token = md5(uniqid(rand(), TRUE)); $timeout = time() + 60 * 60 * 24 * 7; setcookie('auth', "$identifier:$token", $timeout); ?>
When a user uses a permanent login cookie, you can determine whether it meets several criteria. Check:
CODE: <?php /* mysql_connect() */ /* mysql_select_db() */ $clean = array(); $mysql = array(); $now = time(); $salt = 'SHIFLETT'; list($identifier, $token) = explode(':', $_COOKIE['auth']); if (ctype_alnum($identifier) && ctype_alnum($token)) { $clean['identifier'] = $identifier; $clean['token'] = $token; } else { /* ... */ } $mysql['identifier'] = mysql_real_escape_string($clean['identifier']); $sql = "SELECT username, token, timeout FROM users WHERE identifier = '{$mysql['identifier']}'"; if ($result = mysql_query($sql)) { if (mysql_num_rows($result)) { $record = mysql_fetch_assoc($result); if ($clean['token'] != $record['token']) { /* Failed Login (wrong token) */ } elseif ($now > $record['timeout']) { /* Failed Login (timeout) */ } elseif ($clean['identifier'] != md5($salt . md5($record['username'] . $salt))) { /* Failed Login (invalid identifier) */ } else { /* Successful Login */ } } else { /* Failed Login (invalid identifier) */ } } else { /* Error */ } ?>
You should adhere to three aspects to limit the use of permanent login cookies.
##l Cookie needs to expire within one week (or less)
l Cookie It is best to only use it for one verification (delete or regenerate after a successful verification)
l Limit the cookie to expire within a week (or less) on the server side
If you want the user to be remembered indefinitely, as long as the user visits your application more frequently than the expiration time, simply regenerate the identifier after each verification and set a new cookie. Can.
另一个有用的原则是在用户执行敏感操作前需要用户提供密码。你只能让永久登录用户访问你的应用中不是特别敏感的功能。在执行一些敏感操作前让用户手工进行验证是不可替代的步骤。 最后,你需要确认登出系统的用户是确实登出了,这包括删除永久登录cookie: 上例中,cookie被无用的值填充并设为立即过期。这样,即使是由于一个用户的时钟不准而导致cookie保持有效的话,也能保证他有效地退出。
以上就是PHP安全-永久登录的内容,更多相关内容请关注PHP中文网(www.php.cn)!CODE:
<?php
setcookie('auth', 'DELETED!', time());
?>