我目前正在为我的一个网站开发一个更好的登录例程,我想安全地将登录数据传输到服务器.关于这个主题有几篇文章和帖子,但他们经常对如何完成这些文章和帖子有不同的看法.
从SSL开始,漂亮的每个人都在同一页面上:你应该使用SSL,我这样做.然后有人说:"这就够了,使用SSL,你可以发送用户名和PW作为明文".我不同意.其他人说它应该仍然是哈希.我读了几篇文章,我觉得人们关心登录例程的不同方面,并建议只处理其安全方面的机制.
所以我想知道的是,如果我到目前为止所阐述的例程是足够的,太多或太少.我将尝试解释为什么我选择实现某个功能以及我尝试涵盖的安全方面:
服务器和客户端之间的通信应该始终是https:// - 尽管如此,我读了几篇文章警告SSL是"没有银弹",但这是一个好的开始.
许多评论确实拒绝了PW.使用散列,将其与数据库中的HASHed PW进行比较只会将PW从用户输入更改为HASH - 攻击者仍然可以通过简单地获取HASH来访问.我同意.但是(这是我的意思是人们阅读安全的不同方面)那些声称它比发送明文更好的因为在那种情况下只有你的系统,而不是其他具有相同PW的系统会受到损害(当然,除非他们也使用哈希PW).所以我会在通过SSL发送之前实现密码的HASHing.
假设SSL无法隐藏我们发送给服务器的数据,攻击者会读取HASHed PW.我可以考虑调整此方案的安全性的唯一方法是使用事先由服务器发送的密钥加密(例如,AES CBC)客户端HASHed PW,并且具有短的有效期.密钥必须随机生成.像这样,服务器可以解密数据,然后将HASH与数据库中的HASH进行比较.
把它们加起来:
- >客户希望通过SSL进行登录 - >服务器返回键 - > PW的客户方哈希 - >用密钥和随机IV德HASH的客户方加密 - >服务器与密钥(存储在$ _SESSION解密数据,具有到期时间戳)并将HASH与其DB中的HASH进行比较(如果到期时间戳仍然有效).
这会是一个好方法吗？或者这太多了？(可以有太多安全措施吗？)或者您有其他替代解决方案吗？