我正在编写一个Java EE应用程序，它允许新用户注册自己，然后通过Internet登录。我将凭证存储为数据库。
现在，有几种方法可以做到这一点，例如：
阅读一些文章，似乎可以采用安全远程密码协议（SRP）。
然后阅读其他一些文章似乎只是在一些低层次上使用，例如例如TLS / SSL本身。
我仍然认为，建议在应用程序级别使用安全远程密码协议。
这是对的吗？或者是否有一些很好的理由说明为什么在应用程序级别不需要这样做？
答案 0 :(得分：1)
需要考虑一些权衡因素。首先，当且仅当客户端正确验证服务器的SSL证书时，通过SSL链接发送原始密码才是相当安全的。但是，即使执行了正确的SSL证书验证，将原始密码发送到服务器也不是完全理想的。被黑客入侵的服务器可能会泄露用户的密码。由于密码经常在其他地方重复使用，因此这种暴露可能会产生严重影响。
SRP的一个优点是它可以避免这两个问题。用户的密码永远不会离开他们的机器，并且不需要正确的SSL证书验证。 SRP的相互身份验证属性使SSL证书冗余。事实上，一些应用程序利用这一点来完全避免与正确的SSL证书管理相关的麻烦。他们只在服务器上使用匿名的自签名证书，仅用于数据加密，并将身份验证保留到应用程序级SRP。
特别是对于您的问题，我认为SRP对低级别与应用程序级别使用的适用性实际上取决于您的应用程序。它可以在两个竞技场中很好地运行，但是它最适合的地方可以归结为您正在使用的特定设计约束。
答案 1 :(得分：0)
人们应该使用SRP而不是TLS / SSL，因为它们是免费的。
如果您的用户通过网络注册或重置其SRP密码验证程序，则需要加密连接;因为验证者应该保密，这样它就不会遭受离线蛮力攻击。 TLS / SSL / HTTPS非常适合这种情况。它们已经很好地建立，加密所有数据，并提供服务器证书的保护，以确保浏览器不与欺骗服务器通信。
SRP表示用户通过身份验证的密码不会通过网络。如果您的用户使用公司提供的计算机通过公司Web代理，那么HTTPS可能是decrypted and monitored。 Hearbleed错误还表明配置良好的HTTPS可能存在问题。笔记本电脑制造商故意在他们销售的笔记本电脑上使用Superfish来破坏HTTPS，这样他们就可以将广告注入加密页面。根据{{3}}可能会损害根证书以窥探员工。即使使用完美的加密设置，应用程序也可能意外地将密码泄露到日志中;而SRP使用随机输入进行一次性密码证明。因此，SRP保护密码不会离开客户端计算机，而客户端计算机本身就比在两台计算机上进入内存（可能泄漏的地方）更安全。
结果是人们应该同时使用SRP和HTTPS / TLS / SSL。