安全登录和安全页面检查PHP的最佳实践

我想了解一些人对以下方面的看法：

• 为网站上的每个安全页面查询数据库，以便在会话/cookie和数据库值之间进行加密和加密的代码检查，这是好的/最佳的做法吗

或

• 依赖加密会话和cookie（其中密钥和值都是加密的）是否是好的/最佳实践

因此，用户id和访问级别要么从每个安全页面上的数据库中提取，要么从加密的会话/cookie值对中提取

---

结论

这就是我选择要做的：

登录

验证用户名和md5（密码）是否在数据库中且正确

开课

会话存储加密密钥和值对：用户id、管理员、访问级别

通过连接远程IP和远程用户代理以及配置加密密钥来创建访问密钥，对每个密钥进行加密，将字符串连接在一起，然后再次加密

使用加密密钥将此值存储在db和会话中

用户现在已登录

页面验证：

我将选择两个页面用户访问验证级别：

低优先级安全任务，例如详细列表、上载图像、选择查询

高优先级安全任务，如删除和更新

低优先级页面检查：

只需检查加密会话密钥的存在情况以及用户id、访问级别和访问密钥的存在情况

高优先级页面检查：

查询数据库中的会话访问密钥匹配，并为用户id、访问级别重新设置会话值

附加：

---

我将添加一个IP记录功能，该功能将跟踪DB中的IP以进行登录尝试，如果该IP登录失败超过10次，则该IP将被禁止。

当然不会从Cookie中进行。会话cookie应该是一个完全没有意义的伪随机的gobbledygook blob。这个gobbledygook是存储在服务器端的会话的id。该会话数据可以存储在数据库或文件系统中（PHP会话默认情况下是这样）。您使用用户存储的凭据对用户进行一次身份验证，然后为他打开一个会话，并存储他的用户id以及此会话中需要的任何其他内容。然后，用户通过其无意义的会话cookie和属于它的数据进行识别和身份验证。不多也不少

不过，对于偶尔检查会话中的数据是否仍与数据库同步，有一个参数需要提供。比如说，用户具有特定的“访问级别”，当用户进行身份验证时，您将其存储在会话中。现在您可以更改数据库中用户的访问级别；会话仍将具有该数据的旧副本，用户仍将能够访问可能不再允许访问的级别。根据规范数据库存储验证此数据的频率取决于您。

您可以将“敏感”数据放入Cookie中，许多系统都使用它，例如CodeInMonitor

要将风险降至最低，请确保正确实施加密

如果加密正常，那么会话cookie加上数据库查找与cookie中存储的值之间没有太大区别

在这两种情况下：

如果可能，请使用HTTPS

仅使用HTTP_-only cookies，因此会话cookie不会显示在document.cookie中

删除可能显示cookie信息的任何“反射”页面，phpinfo（）页面就是一个很好的例子

确保将IP地址的某些部分添加到混合中，可能还添加了用户代理

---

如果有人设法抓取了cookie或会话cookie，它就不能模拟用户，除非它知道用户代理，并且可以从该IP或IP类发送HTTP请求。

会话和cookie不是一回事！加密会话数据没有什么用处，而且在客户端存储用户凭据非常不安全。我认为这不是一个良好实践的问题，而是一个web身份验证如何工作的问题。你永远不需要复制密码。登录一次，信任你的会话数据。在更改帐户/提升的安全操作时确认密码。当数据库和会话可用时，使用cookies获取敏感信息就像购买保险箱并将昂贵的珠宝放在上锁的抽屉中。是的。但是如果我们谈论的是“logged_in”=1和“access_level”=9，我认为这是安全的，并且根据系统的不同，它可以为您节省大量的SQL查询。存储密码（哈希/盐或非哈希/盐）这不是一个好主意。@DuppyWeb特别是“access_level=9”时，您不会将此信息提供给客户端。这使任何具有必要技能的人都可以随时升级其访问级别。@deceze是的，如果有人有技能破解正确实现的AES，那么你就不走运了。@DuppyWeb有可能以某种方式泄露加密密钥（*cough*heartbleed*cough*），这意味着攻击者不需要破坏任何东西，只需以与您相同的方式加密他想要的任何东西。这可能会失败的可能性太多，而将所有数据服务器端保留在一个会话中失败的可能性要小得多。