GWT / Javascript客户端密码加密

Question

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

1. 用户通过将其凭据放入表单中进行注册，然后将其以明文形式发送到服务器。
2. 服务器代码使用BCrypt对接收到的密码进行哈希处理，并将哈希值放入数据库中。
3. 当用户登录时，他的密码将以明文形式发送给服务器，并根据存储的哈希值进行检查。

现在。令我困扰的是，我正在将密码发送到服务器，我一直认为如果我使用的应用程序与我一起使用，我会不会很高兴（use-for-所有类型的密码，但在客户端加密它并不能真正赢得任何东西，因为攻击者可以使用散列密码，因为它们是明确的密码。

我整天都在googling这一点，看来互联网是非常一致的 - 显然客户端密码加密没有任何好处。 This，this和this只是我所讨论的讨论和网页的几个例子，但还有很多甚至更多的人都在说同样的事情。

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

我可以做什么， 如果此时ssl不是一个选项 ，为了让我放松心情？有什么可以做的，或者实施某种类型的客户端加密服务器解密方案只是耗费时间的虚弱死马？

Answer 1

对于登录，即使在此时，SSL也应该是您的选择。如果它仅用于登录，则不需要昂贵的SSL服务器场，但至少可以保护（使用所有类型）密码，即使很明显，其余的通信也不受保护 ^{[ *]} 。这可能意味着，您只需要为一个登录服务器购买证书，这可以再次为您节省很多钱，具体取决于证书供应商。

对于GWT，如果您无法负担加密所有通信的费用，则由于同源策略限制，您必须将登录设置在单独的页面上。

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

在没有某些预共享密钥的情况下，不能通过不安全的媒体进行任何安全通信 - 通常由浏览器中安装的根证书提供（BTW，浏览器甚至整个操作系统通常都是通过HTTP下载的，这很有趣/可怕。其他系统，例如PGP依赖于先前在"Web Of Trust"中建立的信任，但这只是另一种形式的预共享秘密。没有办法解决它。

^{[*]遗憾的是，对所有内容使用SSL会带来额外的实际问题：1）页面加载速度要慢得多，尤其是如果页面上有许多元素。这是由于SSL引起的往返和由此导致的延迟，即使是最快的SSL服务器场也无法解决这个问题。问题得到缓解，但保持活动连接并未完全消除。 2）如果您的页面包含来自外部，非HTTPS站点的元素（例如用户插入的图像），许多浏览器将显示警告 - 这些警告对于真正的安全问题非常模糊，因此对于安全站点而言通常是不可接受的。}

一些额外的想法（不是推荐）

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

Answer 2

如果SSL不是一个选项，那么你显然不太关心安全性;）

但严肃地说 - 就像你提到的那样，密码的客户端加密并不是一个好主意。事实上，这是一个非常糟糕的。你不能信任客户端杰克 - 如果攻击者设法改变JS代码（通过XSS或通过线路发送），那么你的MD5 /任何哈希函数只是通过明文传球？更不用说你应该使用一个好的，强大的，加盐的加密方法，比如bCrypt - 在客户端上运行缓慢的东西，就像之前提到的那样，并没有增加应用程序的安全性。

您可以尝试绕过其中的一些问题：通过一些安全的方式发送哈希库（如果首先可能的话，我们现在就不必为此而烦恼了，不是吗？），不知何故在服务器和客户端之间共享一个共同的秘密并将其用于加密...... 但最重要的是：尽可能使用HTTPS （在GWT中很难混合使用HTTPS和HTTP）和< em>对齐 （如果用户愚蠢到使用与非安全相关的应用程序和他的银行帐户使用相同的密码，那么他/她很可能使用相同的密码许多其他网站，其中任何一个都可能导致劫持密码）。其他方法只会让您认为您的应用程序比它更安全，并使您不那么警惕。

Answer 3

考虑使用SRP。

但如果中间人发送恶意javascript而不是simpy将密码副本发送给攻击者服务器，那仍然无济于事。