我正在编写一个 Java EE 应用程序，它允许新用户自己注册，然后通过 Internet 登录。我将凭据存储在一个数据库中。
现在，有几种方法可以做到这一点，例如：
阅读一些文章，似乎安全远程密码协议（SRP）是要走的路。
但是随后阅读其他一些文章，似乎这仅用于某些低级层，例如 TLS/SSL 本身。
我仍然认为，建议在应用程序级别使用安全远程密码协议。
这个对吗？还是有一些很好的理由说明应用程序级别不需要这样做？
有一些权衡需要考虑。首先，当且仅当客户端正确验证服务器的 SSL 证书时，通过 SSL 链接发送原始密码是相当安全的。但是，即使执行了正确的 SSL 证书验证，将原始密码发送到服务器也不是完全理想的。被黑的服务器可能会暴露用户的密码。由于密码经常在其他地方重复使用，这种暴露具有潜在的严重影响。
SRP 的一个优点是它避免了这两个问题。用户的密码永远不会离开他们的机器，并且不需要正确的 SSL 证书验证。SRP 的相互验证属性使 SSL 证书变得多余。事实上，一些应用程序利用这一点来完全避免与正确的 SSL 证书管理相关的麻烦。他们只是在服务器上使用匿名的自签名证书仅用于数据加密目的，并将身份验证留给应用程序级 SRP。
具体到您的问题，我认为 SRP 对低级和应用程序级使用的适用性确实取决于您的应用程序。它在这两个领域都可以很好地发挥作用，但它最适合使用的地方实际上归结为您正在使用的特定设计约束集。
人们应该使用 SRP over TLS/SSL，因为它们是免费的。
如果您的用户通过网络注册或重置他们的 SRP 密码验证器，那么您需要加密连接；因为验证者应该保密，以免受到离线暴力攻击。TLS/SSL/HTTPS 非常适合这个。它们非常成熟，加密所有数据，并提供服务器证书保护，试图确保浏览器不会与欺骗服务器通信。
SRP 意味着您的用户进行身份验证的密码不会跨网络。如果您的用户通过公司网络代理使用公司提供的计算机，那么 HTTPS 可能会被解密和监控。Hearbleed 漏洞还表明配置良好的 HTTPS 可能会出现问题。笔记本电脑制造商故意在他们出售的带有Superfish的笔记本电脑上破坏 HTTPS，以便他们可以将广告注入加密页面。法国政府部署的根证书可能遭到破坏窥探员工。即使有完美的加密设置，应用程序也可能会意外地将密码泄露到日志中；而 SRP 使用随机输入进行一次性密码证明。因此，SRP 保护密码不离开客户端机器，这本质上比让密码进入两台机器上的内存（可能泄露的地方）更安全。
结果是人们应该同时使用 SRP 和 HTTPS/TLS/SSL。