没有SSL的安全认证

Question

我想到了一个没有SSL的认证系统似乎相当安全。我忽略了一些重要的事情吗？

1. 用户点击登录页面
2. 服务器生成用于传输的盐（t-salt）并将其存储在会话中
3. 服务器将t-salt作为加载
的登录页面的一部分发送给用户
4. 用户输入用户名和密码并点击提交
5. 浏览器MD5加密密码和t-salt
6. 浏览器将用户名和MD5（密码+ t-salt）发送到服务器
7. 服务器使用用户名（*）从数据库中检索密码，请参阅下面的注释
8. 服务器MD5加密从步骤7检索到的密码以及步骤2中存储在会话中的t-salt
9. 服务器比较步骤6和步骤8中的两个MD5
10. 如果它们相同，则登录成功通过验证
11. 服务器从会话中删除t-salt（在步骤2中添加）以防止潜在的重放攻击

*请注意，步骤7中检索到的密码不能单向加密（通常的做法），以便步骤8工作。但是，双向加密系统仍可用于在数据库级别保护密码。 （嘿，这带来了允许更加用户友好的密码恢复过程的附带好处。）

除了上面的说明之外，这个方案的优点和缺点是什么？

Answer 1

这对于中间人攻击是敞开的。没有什么能阻止攻击者嗅探链接并从服务器＆gt;客户端获取盐，或者从客户端＆gt;服务器获取哈希密码，并重播任何一个。

每次尝试后失效并生成一个新的盐会阻止简单的重放，但它会归结为竞争条件 - 攻击可以在用户之前提交他们的登录尝试吗？即使这样，由于攻击者坐在中间，他们可能会中断用户的链接，捕获盐渍密码，并自己提交并捕获会话。

Answer 2

你发送t-salt和哈希算法algorythm。计算哈希中的密码不会花费很长时间。

我认为你应该重新考虑SSL。

Answer 3

虽然我认为你的意图是好的，但问题的实际情况是你的方法根本没有提供安全保障。正如其他人所指出的那样，任何合理能力的黑客都能够拦截通过线路传输的数据并执行重放攻击。更不用说通过网络传输的任何数据都是未加密的，这会将用户的潜在敏感信息暴露给任何人。

Answer 4

这个问题在于你假设SSL纯粹是关于加密的。看看SSL is not about encryption。在此基础上，您的方案在第1步中分崩离析，因为您无法保证在登录页面加载时它实际上来自您认为具有的网站并且未被篡改。

这种情况有许多先例，Tunisian government harvesting usernames and passwords是一个很好的例子，你可以对这种攻击方式持开放态度，因为你的登录页面甚至可以在浏览器出现之前被改变。

当然，您遇到Firesheep问题，因为您的身份验证持久性（我假设您通过Cookie执行）会在未加密的网络中前后转发。如果有人能够抓住它并重新发出请求（非常容易在公共wifi热点上完成），那么加密内部这些cookie并不重要，那么你就会遇到会话劫持问题

然后MD5中也存在已知的弱点，但即使使用更安全的散列算法也无法避免上述其他问题。花一点钱，做一些最小配置，并使SSL成为您登录过程的一部分。有关详细信息，请参阅OWASP Top 10 on Insufficient Transport Layer Security。

最后，SSL并非旨在成为灵丹妙药;它不会保护您免受键盘记录器的侵害，它不会保护您免受数据库侵犯，并且在他们泄露密码之前不会保护您免受某人whacking your end users over the head with a wrench的攻击。但它并不意味着做任何这些事情，它只是为了更多的防御 - 尽管是一个必不可少的 - 这是更广泛的安全战略的一部分。

Answer 5

要考虑的一件事是SSL不仅仅为整个数据流提供机密性和完整性保护（通过加密），它还提供了对服务器身份的一定程度的验证。

在您的示例中，我无法（我可以看到）客户端在提供密码之前验证他们是否正在与真实服务器通话，因为DNS欺骗攻击或其他一些MITM攻击会有效。

同样如上所述，可以非常轻松地强制用户密码，因为攻击者可以拦截来自服务器 - >客户端的盐，然后是哈希密码。 MD5是一种快速哈希算法，它可能是对标准用户密码的有效攻击。

Answer 6

经过身份验证时传输的数据不安全，实施自己的方案通常是个不错的主意。