我尝试设置TLS-SRP协议，但对我而言无效。
Haaalp！有人吗？
#1 楼
当我了解SRP时，被告知由于可能侵犯EKE专利，因此部署不多。网络计算公司在2002年这样说：标准组织已经进行了几次尝试，诱使朗讯谈论其EKE专利-徒劳无功。即使朗讯对此话题保持沉默，也很少有厂商愿意使用SRP。为了进一步解决这一问题，SRP网站发布了一项新专利，声称它也涵盖了SRP。
SRP网站却声明了
SRP是专门为解决该地区现有专利而设计的，它使每个人都可以使用强大而不受阻碍的密码身份验证技术，该技术可以用于多种用途。
猜想，我想说专利是最初问题的一部分，而且这种影响一直持续到今天。专利是限制部署的唯一原因，还是主要原因是超出我的范围。
评论
$ \ begingroup $
TLS-SRP早已成为RFC标准。缺乏实现。 2002年的参考文献可能太旧了。
$ \ endgroup $
–史密斯（Smit Johnth）
13年5月5日在18:02
$ \ begingroup $
@SmitJohnth RFC 5054的状态为“信息”。这不是IETF标准！
$ \ endgroup $
– Erwan Legrand
15-10-27在17:36
$ \ begingroup $
顺便说一下，TLS-SRP（RFC 5054）泄漏了用户名，因为它是作为ClientHello消息的一部分以明文形式发送的。
$ \ endgroup $
– Erwan Legrand
15年10月27日在17:38
$ \ begingroup $
@ErwanLegrand，除了将对话包装到受公钥保护的通道（并依赖于PKI）之外，没有其他方法可以以纯文本形式发送它。
$ \ endgroup $
–史密斯（Smit Johnth）
17 Mar 24 '17 at 18:04
#2 楼
问题是，SRP仅在键入密码的一侧以受信任的方式实现时才有用。当您开始从服务器通过HTTPS进行加密时，有两件事变成了薄弱的安全链接：
没有理由希望用户不要输入密码，除非绿色锁是在相应域名的左侧；
证书链（实际上可以绕开：从合法CA获得流氓证书并不难；甚至使流氓CA假装拥有如果您注意到恶意证书，则应真诚地颁发恶意证书，这需要格外注意。如果某个主要CA被发现以不正当手段误发行了30000份证书，包括针对www.google.com和www.gmail.com的证书，信任证书链还是安全剧院？）。更新：另一个示例。
用JavaScript实现的SRP速度很慢（至少在缺少带有JIT JavaScript的客户端上）；它在Java中是可以接受的，但是在浏览器中对Java的支持从未变得普遍。更糟糕的是，一旦客户端计算机受到某种恶意软件的侵害，假想的标准化SRP客户端界面可能会成为恶意软件收集登录凭据的便捷目标（通过大量的Web界面，恶意软件通常会可靠地从其他用户输入中筛选登录凭据） 。
客户端计算机上的SRP不提供两因素身份验证。
与通过HTTPS发送密码的做法相比，只有在假设服务器或HTTPS受到损害后，SRP的好处才存在。
更新：标准化的SRP无法防止服务器端数据泄漏；有了这些数据，就可以测试密码的有效性，从而使字典中的密码搜索令人担忧（以及技术进步/使用ECC积极地危害了安全性）。为了解决服务器数据泄露的威胁（这是标准安全要求的一部分），SRP将需要有针对性地基于慢速的基于密码的密钥派生功能（例如PBKDF2，Bcrypt，Scrypt，Argon2，Balloon）来代替，而不是快速哈希。盐和安全性参数来自何处，并没有通过RFC5054或ISO / IEC 11770-4：2006进行标准化（未检查最新版本），并且没有促进少数SRP客户端的互操作性。
更新：在注册时如何建立服务器端数据尚未标准化，无论是AFAIK还是HTTPS可能是薄弱环节的另一个领域。
由于所有这些原因，浏览器中的SRP从未捕获，也未下载从服务器或内置到浏览器中。如果有足够的资金用于安全性，则将进行两因素身份验证。否则，业务决策者现在需要一种可以在任何地方运行且具有顺畅的用户体验的东西，而SRP没有业务案例。
评论
$ \ begingroup $
1）2）您的意思是SRP的javascript实现，对吧？那是一个不好的解决方案。实际上有TLS-SRP标准，可惜它太糟糕了。 5）“只有在您假设服务器或https受到损害后，SRP的好处才存在。” -还不够吗？
$ \ endgroup $
–史密斯（Smit Johnth）
17 Mar 24 '17 at 17:58
$ \ begingroup $
@Smit Johnth：1）2）是的，实际上SRP的javascript实现不是一个很好的解决方案。是的，TLS-SRP很好，但实际上没有使用。也许部分原因是，如3）中所述，它的API会成为SPoF。 5）是的，但是AFAIK没有人因为没有规定SRP而被解雇，当时人们因为不安全的真实理由而被解雇，而绝大多数Web都没有HTTPS和可通过的密码管理器更好，其他任何事情都会减少潜在的用户群。
$ \ endgroup $
–fgrieu♦
17 Mar 24 '17在18:14
$ \ begingroup $
“ AFAIK没有处方SRP没有人被解雇”-您刚刚描述了它不受欢迎的事实，而不是原因。 3）不要。
$ \ endgroup $
–史密斯（Smit Johnth）
17年7月11日在17:11
$ \ begingroup $
“与通过HTTPS发送密码的做法相比，只有在假设服务器或HTTPS受到损害后，SRP的好处才存在。” -它也可以防止网络钓鱼（既不泄露用户密码，也不可以伪造服务器针对客户端进行身份验证）
$ \ endgroup $
–史密斯（Smit Johnth）
17年7月12日在20:38
$ \ begingroup $
您的许多异议也适用于其他选择。在此未提及的SRP的一个优点是，它可以通过暴露请求日志或其他流量监视功能来防止服务器端意外暴露密码。
$ \ endgroup $
– Elroy Flynn
20年1月28日在16:43
#3 楼
也许它没有在TLS中广泛使用，但实际上已部署在Apple iCloud（Apple安全白皮书中的第49页），1PassWord（1PassWord安全白皮书中的第57页），ProtonMail（在此博客中）等用于身份验证的目的。 />评论
$ \ begingroup $
我不知道你写什么。在ProtonMail中如何使用？作为Js SRP？它是有用的。
$ \ endgroup $
–史密斯（Smit Johnth）
17年7月11日在22:01
$ \ begingroup $
@SmitJohnth博客写得很清楚。如果您想了解它，则应进行检查。
$ \ endgroup $
– 9f241e21
17年7月11日在22:15
$ \ begingroup $
我没有看到它，但是没有其他方法可以像使用js一样。
$ \ endgroup $
–史密斯（Smit Johnth）
17年7月12日在11:28
$ \ begingroup $
@SmitJohnth github.com/mozilla/node-srp
$ \ endgroup $
– 9f241e21
20年1月22日在6:48
#4 楼
尽管我认为随着OpenSSL随附的其他专利和SRP的到期，这种情况最近正在改变，但主要的问题之一是与现有身份验证数据库的兼容性。NT OWF，unix crypts，目录服务器哈希..etc除明文密码（例如，在磁盘上可逆加密的明文）以外的所有内容均与SRP不兼容。如果您泄漏盐分并匹配存储的哈希，可以确保您可以让SRP客户端执行加密，但这会将哈希的重要性提升为等同于纯文本密码。 （例如“传递哈希”）
我个人对SRP感到非常兴奋，我们计划了一些计划利用TLS-SRP的项目。
评论
$ \ begingroup $
什么是专利？ OpenSSL中的TLS-SRP对我不起作用（请参阅问题中的链接），我无处无法获得帮助。
甚至不用提Windows NT auth，它在15年前就很烂，现在却成倍增长计算能力。
$ \ endgroup $
–史密斯（Smit Johnth）
13年5月21日在21:49
$ \ begingroup $
好吧，如果您询问有关身份验证数据库的信息，那么您可能是内部人员和组织，并且可能会获得一个或多个ssl证书甚至一个CA。 SRP对于孤独的服务器很有用，因为获得签名的SSL证书会很昂贵或复杂。
$ \ endgroup $
–史密斯（Smit Johnth）
13年5月22日在2:44
$ \ begingroup $
@SmitJohnth SRP具有额外的优点（与使用服务器证书进行的传统RSA或DH密钥交换相比），客户端也将自动进行身份验证，并且您不需要其他步骤即可进行客户端身份验证。
$ \ endgroup $
–PaŭloEbermann
13年5月23日在21:43
$ \ begingroup $
@PaŭloEbermann我认为您的帖子不属于这里:)
$ \ endgroup $
–史密斯（Smit Johnth）
13年5月24日在1:27
$ \ begingroup $
@SmitJohnth不，我的评论是对您的评论的回应。 SRP不仅适用于“我负担不起SSL证书”的情况，还具有其他优点（但仅适用于有限的用户组）。
$ \ endgroup $
–PaŭloEbermann
13年5月24日在19:12
#5 楼
答案很可能是投资回报率。实施SRP需要花费时间和金钱。您所支付的费用会得到什么？您还可以问为什么我们不使用SCRAM（RFC 7677）。还是为什么客户端X.509证书没有得到更广泛的使用。我相信您需要进行一些威胁分析才能理解这一点。 （从现在开始，我假设由TLS提供安全的网络通信。）
问题：在哪种情况下，更好的密码协议可提供额外的安全性？
答案：更好的密码协议如果服务器不可靠，则可以防止非法使用密码。
问题：但是，如果服务器受到威胁，为什么还要担心密码保密？
回答：因为使用同一密码来访问其他有价值的资源。
但是……自1990年代后期（Schneier-PasswordSafe）甚至更早以来，密码管理器已经解决了这个问题！ />
现在，让我们来看另一种威胁：假设客户端系统受到威胁。
问题：SRP是否可以缓解这种威胁？
答案：它确实不是。
问题：目前可以广泛使用的解决方案可以缓解这种威胁吗？
答案：是的。 （Google身份验证器，暴雪身份验证器，SMS验证码-如果智能手机不是用于访问宝贵资源的设备-硬件令牌...）
因此，我想答案是肯定的动力不足，无法实施更好的密码协议。
编辑：我正要忘记这一点！愚蠢的密码协议不会泄漏用户名（仍然假定使用普通的TLS），而TLS-SRP却会。因此，总结一下答案：切换到TLS-SRP不会减轻现有威胁，也不会减轻另一种威胁。
#6 楼
为了有用，它需要在浏览器中实现，以便用户在JavaScript不可访问的区域（例如URL栏）中输入密码。而且没有人这样做。还有一个巨大的行业试图阻止和处理网络钓鱼。迄今为止，网络钓鱼是当今安全问题的最大根源。 SRP可以杀死网络钓鱼死亡，因此有许多人对此表示反对。
#7 楼
几年后，这个问题可能不再有效，因为现在有一些实现。这是一个用于PHP + JS的示例，它既具有说明性，又具有功能性。我不能证明它是否有什么好处，但是考虑到它实现了协议的最新版本（SRP-6a），我想值得一看。
这里还有另一个，同样适用于PHP ，而且还很新。
评论
$ \ begingroup $
除非在浏览器中，否则无用。不得在JavaScript中实现。关键是不信任恶意站点。
$ \ endgroup $
–可伸缩
17年11月17日在5:24
$ \ begingroup $
AWS Cognito支持并鼓励SRP，并提供Javascript（NodeJ和浏览器端）实施，并且还提供.Net Core和Python模块。
$ \ endgroup $
– Elroy Flynn
20年1月28日在16:33
评论
SRP的作者Tom Wu曾经来过这里。好奇他会说什么。有关如何在SRP上使用OpenSSL的信息，请参阅Matthew Arcus于2014年中发布的博客，网址为matthewarcus.wordpress.com/2014/05/10/srp-in-openssl