GWT/Javascript客户端密码加密

Question

GWT/Javascript客户端密码加密

securitygwtencryptionauthorizationclient-side

15

我正在实现我的gwt应用程序中的授权，目前它是按以下方式完成的：

用户通过在表单中输入凭据来注册，并将它们以明文形式发送到服务器。
服务器代码使用BCrypt哈希接收到的密码，并将哈希放入数据库中。
当用户登录时，他的密码以明文形式发送到服务器，服务器会检查它是否与存储的哈希匹配。

现在。让我烦恼的是，事实上我正在以明文形式将密码发送到服务器，我一直在想，如果我使用的应用程序这样做了我的（用于所有种类）密码，我肯定不会很高兴，但在客户端加密它并不能真正为我赢得什么，因为攻击者可以像使用明文密码一样使用哈希密码。

我整天在谷歌这个问题，似乎互联网对此有一致的看法 - 客户端密码加密无法带来任何好处。这篇文章, 这篇文章和这篇文章只是我找到的几个讨论和页面的例子，但还有许多其他的，都在说同样的话。

鉴于所有这些，这个问题可能看起来有点不必要，但我希望在某个地方，有人会给我另一个答案。

如果在这一点上没有ssl选项，我该怎么做才能放心？有什么可以做的吗，或者实施某种客户端加密-服务器解密方案只是费时无用的劳动？

- Mia Clarke

3个回答

5

如果SSL不是一个选择，那么你显然不够关心安全 ;)

但是说真的 - 就像你提到的，客户端加密密码不是一个好主意。事实上，这是一个非常糟糕的主意。你不能信任客户端 - 如果攻击者设法通过XSS或通过网络篡改JS代码，使你的MD5/其他哈希函数只传递明文密码怎么办？更不用说你应该使用一个好的、强大的、盐值加密方法，比如bCrypt - 客户端上的速度很慢，就像之前提到的，它并没有增加应用程序的安全性。

你可以尝试绕过其中一些问题：通过某些安全手段发送哈希库（如果一开始就可能这样做，我们就不必现在麻烦了），通过某种方式共享服务器和客户端之间的共同秘密并使用它进行加密... 但最重要的是：尽可能使用HTTPS（在GWT中很难混合HTTPS和HTTP）并且有正当理由（如果用户愚蠢到在你的非安全相关应用程序和银行账户中使用相同的密码，那么他/她很可能在许多其他网站上使用相同的密码，其中任何一个都可能导致密码被劫持）。其他手段只会让你认为你的应用程序比它实际上更安全，并让你变得不那么警惕。

- Igor Klimer

1

考虑使用SRP。

但如果中间人发送恶意JavaScript并将您的密码副本发送到攻击者的服务器，这仍然无法解决问题。

- CodesInChaos

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Chris Lercher · Accepted Answer

对于登录，SSL应该是您的选择，即使在此时。如果仅用于登录，则不需要昂贵的SSL服务器群，但至少可以保护（用于一切的）密码，尽管剩余通信未受到保护^[*]。这可能意味着您需要为仅一个登录服务器购买证书，这可以根据证书供应商而节省大量资金。

对于GWT，如果您无法承担加密所有通信的费用，由于同源策略的限制，您将不得不将登录放在单独的页面上。

如果仍然不是一个选项，您可以考虑通过OpenID登录，就像stackoverflow一样。

没有任何安全通信可以在不安全媒体上进行，除非有一些预共享的秘密 - 通常由浏览器中安装的根证书提供（顺便说一下，有趣/可怕的是，浏览器甚至整个操作系统通常都是通过HTTP下载的）。其他系统，例如PGP，依赖于以前建立的对“信任之网”的信任，但这只是另一种形式的预共享秘密。没有其他办法。

^{[*] 对于所有内容使用SSL - 不幸的是 - 会带来额外的实际问题：1）页面加载要慢得多，特别是如果页面上有许多元素。这是由于SSL引起的往返和产生的延迟，即使使用最快的SSL服务器群也无法解决。通过保持活动连接可以缓解该问题，但不能完全消除。2）如果您的页面包括来自外部非HTTPS网站的元素（例如用户插入的图像），许多浏览器将显示警告 - 这些警告对于安全站点通常不可接受，并且非常模糊关于真正的安全问题。}

一些额外的想法（不是建议）

让我们暂时假设最坏的情况，即您根本无法使用SSL。在这种情况下，也许令人惊讶的是，在传输密码之前对其进行哈希处理（加盐），实际上可能比什么都不做更好。原因如下：它不能击败Mallory（在密码学中，可以操纵通信的人），但至少不会让Eve（只能听取的人）读取明文密码。如果我们假设Eve比Mallory更常见，那么这可能是有价值的（？）但请注意，在这种情况下，您应该在与数据库值进行比较之前再次对密码进行哈希处理（使用不同的盐）。