我想到了一个没有SSL的认证系统，看起来相当安全。我是否忽略了重要的事情？没有SSL的安全认证
*注密码取回我步骤7不能被单向加密（如惯例）以使步骤8工作。但是双向加密系统仍然可以用于在数据库级别保护密码。 （嘿，这带来了允许更加用户友好的密码恢复过程的副作用。）
除了上面我刚才的说明，这个方案的优点和缺点是什么？
这是对中间人攻击的广泛开放。没有什么会阻止攻击者嗅探链接，并从服务器 - >客户端获取salt，或从客户端 - >服务器发送哈希密码，并重播。
在每次尝试后都会失效并生成一个新盐，以防止简单的重播，但这会导致竞争状态 - 攻击者是否可以在用户之前提交他们的登录尝试？即使在那时，由于攻击者坐在中间，他们可能会中断用户的链接，捕获密码，然后自己提交并捕获会话。
攻击者还可以在客户端机器上安装一个键盘记录器来获取他们的密码，除非我们要求所有用户使用硬件安全令牌并将他们的计算机锁定在盗窃中，否则无论采用或不采用SSL，我们都无法保护他们。防弹保险库。在某些时候，由于最终用户访问内容的性质和敏感性，我们必须认识到我们认为安全合理的阈值。没有SSL的认证，如果我们能够使其合理安全，对于某些系统仍然有价值。考虑到这一点，这有什么好处吗？ – OCDev
在路由器/交换机上，中间人更有可能。为什么杯子里的人在路上经过时，你可以把所有经过银行大门的人都挤在一起？滚动您自己的安全协议从来就不是一个好主意，特别是当有广泛使用/安全/审查的协议可用时。 –
您提到了广泛使用/安全/审查的协议。有没有不使用SSL？这曾经被试过吗？这并不是我完全憎恨SSL;我只是在探索我的选择，因为我将权益与风险进行权衡，并将它们与我手头的项目相匹配。 – OCDev
虽然我认为你的意图是好的，但事实是在你的方法中根本没有提供任何安全性。正如其他人所指出的，任何合理的黑客都将能够截获数据并执行重播攻击。这并不是说任何通过网络传输的数据都是未加密的，这会将用户的潜在敏感信息暴露给任何人。
感谢您提及重播攻击。我已经添加了第11步以防止它们。让我知道你可能会看到的其他弱点。至于通过网络传输的未加密数据，对于许多只使用SSL进行登录过程的系统也是如此。在这些情况下，我们假设内部数据（经过身份验证）不够敏感，不值得加密。 – OCDev
有一点需要考虑的是，SSL不仅为整个数据流提供机密性和完整性保护（通过加密），还提供了服务器身份验证的级别。
在您的示例中，客户端无法验证他们在提供密码之前是否正在与真实服务器通话，因为这样的DNS欺骗攻击或其他MITM攻击会很有效。
同样如上所述，可以非常轻松地暴力破解用户密码，因为攻击者可以拦截从服务器 - >客户端发出的盐，然后再次输入散列密码。 MD5是一种快速哈希算法，它可能是对标准用户密码的相当有效的攻击。
SSL取决于CA的完整性。事实表明，许多CA受到政府直接或间接的控制，使恶意政府发布自己的“amazon.com”SSL证书变得微不足道，并欺骗了其国内电信/ ISP范围内的所有人。 –
@Marc B：没错。我最近阅读了很长时间的关于坏CA的问题，并讨论了整个行业服务器身份的验证问题，所以SSL在这里没有给你任何额外的东西。 – OCDev
与安全事物一样，没有绝对的保护措施，只有那些可以减轻一些风险的措施。如果你的攻击者可能是国家级的，那么标准的SSL会变得可疑（尽管你可以通过使用你自己的CA作为一个可信任的root并删除所有其他的攻击来绕过这个），但是在那种情况下，我建议他们可以访问非常广泛的攻击。针对大多数人面对SSL的低层次攻击者（如果正确实施并且使用得当）将提供合理的保护级别。 –
这样做的问题在于您假定SSL纯粹是关于加密的。看看SSL is not about encryption。在此基础上，您的计划在步骤1中分崩离析，因为您无法确保登录页面加载时实际上来自您认为它具有的网站并且没有被篡改。
发生这种情况的先例很多，Tunisian government harvesting usernames and passwords是一个很好的例子，您可能会对这种攻击风格敞开大门，因为您的登录页面可能会在它碰到浏览器之前被更改。
那么当然你有Firesheep问题，因为你的身份验证持久性（我假设你通过cookie来做）会在未加密的网络上前后移动。不要紧，你在里加密这些cookies，如果有人能够抓住它并重发请求（很容易在公共的wifi热点上完成），那么你就有会话劫持问题。
然后在MD5中也有已知的弱点，但即使使用更安全的哈希算法也不会使您免于上述其他问题。花一点钱，做一些最低限度的配置，并使SSL成为您登录过程的一部分。有关更多信息，请参阅OWASP Top 10 on Insufficient Transport Layer Security。
最后，SSL不打算成为万能药;它不会保护您免受密钥记录器的侵害，它不会保护您免于破坏数据库，并且在您泄露密码之前，它不会保护您免于遭受某人whacking your end users over the head with a wrench的侵害。但这并不意味着要做任何这些事情，它只是为了增强防御能力 - 尽管它是必不可少的一部分 - 这是更广泛的安全策略的一部分。
刚刚使用SSL有什么问题？ – ceejayoz
从我看来，没有优势和很多弱点。这似乎是一个可怕的想法。以纯文本存储密码将比这更安全。您最好使用正常的身份验证方案：发送纯文本密码，salt并在服务器端对其进行哈希处理，然后与存储的密码哈希值进行比较，或使用SSL或两者兼而有之。 – netcoder
ceejayoz：使用SSL有什么问题是它是添加到系统的另一个组件。可以放到项目中的PHP库会更简单。 netcoder：以纯文本存储密码并不比以纯文本存储密码的替代方式更安全，并且可以用数学方法证明。 :)我对这里的行业教条不感兴趣，因为我正在努力学习和探索新的想法。我知道学术上正确的人没有发现这种有价值的东西，但我坚信，可能有一个聪明的解决方案，可能比我想象的更多。 – OCDev