我目前正在PHP set_save_session_handler()中实现自己的会话处理程序，一切都按我希望的方式工作，现在我正在处理如何实现自动登录功能。
在进行谷歌搜索时，我看到了许多过时的错误提示，例如将密码作为单独的cookie进行哈希处理，而将较长的过期日期添加到会话cookie中通常被标记为不良做法。
PHP manual（和其他几个来源）声明将一次哈希密钥实现为自动登录密钥。
开发人员不得使用寿命长的会话ID进行自动登录，因为这会增加会话被盗的风险。自动登录功能应由开发人员实现。
使用setcookie（）将安全的一次性哈希密钥用作自动登录密钥。使用比SHA-2更强大的安全哈希。例如。 SHA-256或更高版本，带有来自random_bytes（）或/ dev / urandom的随机数据。
如果用户未经身份验证，请检查一次自动登录密钥是否有效。在有效的情况下，对用户进行身份验证并设置新的一次性安全哈希密钥。自动登录密钥只能使用一次，即永远不要重复使用自动登录密钥，始终要生成一个新的自动登录密钥。
自动登录密钥是使用寿命很长的身份验证密钥，应尽可能地对其进行保护。使用path / httponly / secure / SameSite cookie属性对其进行保护。即除非需要，否则永远不要发送自动登录密钥。
对于我来说，短暂的会话Cookie可以最大程度地减少会话劫持绝对是有意义的，如果您仍然拥有其他自动登录cookie，那么被劫持的会话cookie不会是世界末日。
但是关于永久性自动登录cookie的额外风险似乎几乎为零。这可以像会话cookie一样强行使用，对吗？还是这与生成的会话ID的熵有关？ （如果是这样，PHP 7是否具有对会话ID的正确CSPRING支持可以解决此问题？）
关于使用永久性登录cookie，如今在我看来，您有很多安全工具可用于最小化会话劫持（session_regenerate_id()，samesite cookie属性，CSP等）。在我看来，与具有自动登录键的数据库表相比，您还可以更好地控制会话数据库表（InnoDB，而非MEMORY）中的已启动会话。
tl;博士
是什么使单独的持久性自动登录密钥比持久性会话cookie更安全？难道不能以阻止使用持久会话cookie的方式完全劫持自动登录密钥吗？