从我在网站上看到的很多帖子中,由AJAX或传统表单执行的登录都是彼此安全的.(重新:登录/会话cookie,Ajax和安全性 Ajax登录和javascript cookie,这样安全吗？)
我的问题是:
如果我在将用户的密码(通过客户端/ javascript哈希库)散列到服务器之前对其进行哈希处理,那么我是否会增加人们的安全性？
如果我放置一个表单令牌(一个基于随机,另一个基于时间),这是否涵盖了CSRF攻击？
在这之后我会覆盖所有的基地吗？这种形式会安全吗？
rook.. 5
实际上这可能是一个重大的安全问题.密码被散列的原因是计划失败的一种方法.攻击者可能会获得对数据存储的访问权限(sql注入),然后获取哈希值.如果您只是使用哈希登录,则攻击者不必破解恢复的哈希以获得对应用程序的访问权限.
重播攻击也是一个问题.如果我在身份验证期间嗅探哈希,是什么阻止我重放该请求进行身份验证？
使用消息摘要功能进行身份验证的协议为客户端提供一个nonce,用作一次性salt.微软的SMB NTLM身份验证就是一个很好的例子,但它遇到了很多问题.
使用SSL,而不仅仅是登录.OWASP A9声明必须永远不要在不安全的通道上泄露会话ID.如果您只是在几毫秒之后泄露真实的身份验证凭据,那么所有关心密码的人都会如此.
大多数人没有为登录实施CSRF保护.毕竟攻击者必须首先知道密码,所以"会话骑行"是一个没有实际意义的点.
实际上这可能是一个重大的安全问题.密码被散列的原因是计划失败的一种方法.攻击者可能会获得对数据存储的访问权限(sql注入),然后获取哈希值.如果您只是使用哈希登录,则攻击者不必破解恢复的哈希以获得对应用程序的访问权限.
重播攻击也是一个问题.如果我在身份验证期间嗅探哈希,是什么阻止我重放该请求进行身份验证？
使用消息摘要功能进行身份验证的协议为客户端提供一个nonce,用作一次性salt.微软的SMB NTLM身份验证就是一个很好的例子,但它遇到了很多问题.
使用SSL,而不仅仅是登录.OWASP A9声明必须永远不要在不安全的通道上泄露会话ID.如果您只是在几毫秒之后泄露真实的身份验证凭据,那么所有关心密码的人都会如此.
大多数人没有为登录实施CSRF保护.毕竟攻击者必须首先知道密码,所以"会话骑行"是一个没有实际意义的点.
京公网安备 11010802040832号 | 京ICP备19059560号-6 