PHP 中的哈希和安全措施
我已经阅读过有关如何使用散列在网站中实现安全性的内容，并且我并没有创建像银行或存储信用卡这样非常敏感的东西。但是，我想知道最佳实践。我的网站有一个 AES 256 的 TLS 证书
主要问题：
1.) 通过会话再次发送经过哈希处理的密码似乎是我能想到的保持会话相当安全的唯一方法。在我看来，我并不真正关心用户是否找到该值，但我会关心用户是否找到某种方式来查看数据库并确切地知道我的加密算法是什么。
2.) 我应该在对密码进行哈希处理之前完全删除我的算法，还是应该使用不同的哈希方法？
在 bcrypt 之前或之后使用 sha512 是否可以，因为就碰撞和暴力而言，这两种方法都是合理的？
I have read about how to implement security into a website using hashing, and I am not creating something terribly sensitive like a bank or storing credit cards. I would, however, like to know the best practices. My site has a TLS cert with AES 256
Main issues:
1.) Sending the hashed password hashed again through the session seems to be the only way I can think of to keep the session fairly secure. In my opinion, I don't really care if the user finds that value, but I would care if the user found some way to see the database and knew exactly what my encryption algo was.
2.) Should I just completely take out my algorithm prior to hashing the password, or should I use different hashing methods?
Is it okay to use sha512 prior or after bcrypt, since both of these are sound as far as collisions and brute force?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
就我个人而言，我只是在登录时使用 SHA512 密码进行存储和比较，并且为了进行会话跟踪，我存储了
hash('sha512', $username.$salt.$password);密钥，该密钥存储在会话并与数据库中的用户密钥进行比较以验证其会话。我还没有遇到任何与此相关的安全问题，除非您知道用户的用户名、密码和用户盐（显然不应该存储在数据库中），否则不可能伪造密钥，所以应该是只要有人无法访问您的数据库和代码，就安全（在这种情况下，您会遇到比保护用户密码更大的问题；））
Personally I just SHA512 passwords for storage and comparison upon login, and for session tracking I store a key of
hash('sha512', $username.$salt.$password);, this key is stored in the session and compared against the user's key in the database to authenticate their session.I've yet to come across any security issues with this, it shouldn't be possible to forge a key unless you know the user's username, password and their user salt (which obviously should not be stored in the database) so it should be secure as long as someone doesn't get access to both your database and your code (in which case you've got bigger issues than protecting user passwords ;))