我正在使用“ password_hash”和“ password_verify”函数为我的PHP网站上的新身份验证系统工作。
但是，许多帖子建议使用“令牌”系统进行持续身份验证。
- 将password_hash存储在cookie中是不安全的吗？如果是，为什么？ （据我了解，不可能使用此PHP函数“解码”密码）
- 如果以前的解决方案是可以接受的，是否有任何方法可以比较同一字符串的2个哈希？ （“ password_hash”函数每次称为新字符串））
我也想在我的电子邮件中单击“仪表板”按钮时自动使用login用户 - “
非常感谢您的开明帮助！ :-)
I am working on a new authentication system for my PHP website, using "password_hash" and "password_verify" functions.
However, many posts recommend using a 'token' system for persistent authentication.
- Is it unsafe to store the password_hash in a Cookie? If yes, why? (so far as I understand, it is impossible to 'decode' a password hashed with this PHP function)
- If the previous solution is acceptable, is there any way to compare 2 hashes of the same string? ("password_hash" function will generate a new string every time it is called)
I would also like to auto-login users when clicking on the "Dashboard" button in my e-mails - through a link like "[email protected]&pass_hash=XXX"
Thanks a lot for your enlightened help! :-)
发布评论
评论（1）
是的，它是不安全的。或者至少比不这样做的安全。如果将哈希揭露给用户，则可以实现带外蛮力强迫。即，用户可以离线攻击密码。此外，如果密码不经常更改，则可以复制和认证cookie的内容。
您永远都不应该直接比较两个进行身份验证的哈希，您应该只使用
password_verify（）的返回值。如果要“保留用户登录”，则通常会根据第一个请求进行身份验证，开始会话，然后将会话的存在用作后续请求的身份验证。 （然后在一定程度的不活动之后自动启用会话。）
是的，这是非常不安全的。在此设计中，哈希本质上与密码没有什么不同。世界上的任何人都可以单击链接，并且可以将其登录为用户，而无需知道密码。并且无法保证电子邮件安全，因此此设计与仅通过电子邮件发送了其中包含普通密码的链接的不安全。
任何自动登录的东西都是不安全的。只需嵌入到目标页面的裸露链接，并使该页面使用户登录。
这是代码气味。实际上，没有人真正希望闲置的会话持续几个月，尤其是在为您提供身份验证的现代密码管理器中。
Yes, it's unsafe. Or at least, less safe than not doing it. If you expose the hash to the user, it enables out-of-band brute forcing. I.e., the user can attack the password offline. In addition, if the password doesn't change often, it allows the contents of the cookie to be copied and authenticated with.
You shouldn't ever be directly comparing two hashes to authenticate, you should only be using the return value of
password_verify().If you want to "keep the user logged in", you'd generally authenticate on the first request, start a session, and then use the existence of the session as authentication for subsequent requests. (And then auto-expire the session after some amount of inactivity.)
Yes, it's very unsafe. In this design, the hash is essentially no different than the password. Anybody in the world can click the link and they're logged in as the user, without having to know the password. And email can't be guaranteed to be secure, so this design is just as insecure as just emailing somebody a link with the plain password in it.
Anything that automatically logs in is insecure. Just embed a bare link to the target page and have the page make the user log in.
This is a code smell. Nobody realistically expects an idle session to last a few months, especially with modern password managers that fill in the authentication for you.