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在所有的最坏情况。在这种情况下，或许令人惊讶的是，在传输密码之前（用盐）对密码进行哈希处理，实际上可能比无所事事好一点。原因如下：它不能击败马洛里（在密码学中，一个可以操纵交流的人），但至少它不会让夏娃（一个只能听的人）阅读明文密码。如果我们假设Eves比Mallorys更常见（？），那么这可能是值得的。但请注意，在这种情况下，您应该再次将密码再次（使用不同的盐）进行散列，然后再与数据库值进行比较。

Answer 2

如果SSL不是一个选项，然后很显然你不够关心安全;）

但严重的是 - 就像你提到的，密码的客户端加密是不是一个好主意。事实上，这是一个非常糟糕的。您不可能不可信信任客户端插孔 - 如果攻击者设法更改JS代码（通过XSS或通过线路发送时），那么您的MD5 /任何散列函数只会通过明文？更不用说，你应该使用一个好的，强大的，盐渍的加密方法，比如bCrypt--在客户端和前面提到的只是很慢的东西，并没有增加应用程序的安全性。

你可以尝试绕过一些问题：通过一些安全的方式发送哈希库（如果这可能首先，我们现在不必打扰所有这些，我们会吗？），通过不知何故共享服务器和客户端之间的共同秘密，并使用它加密... 但底线是：尽可能使用HTTPS（在GWT很难混合HTTPS和HTTP）和理由（如果用户很愚蠢，因为您的非安全相关应用和他的银行账户使用相同的密码，那么他/她很可能在其他一些网站上使用了相同的密码，其中任何一个都可能导致劫持密码）。其他方式只会让你认为你的应用程序比它更安全，并且使你不那么警惕。

Answer 3

考虑使用SRP。

但是，如果一个中间的人向你发送邪恶的javascript，而不是simpy发送你的密码的副本给攻击者服务器，这仍然没有帮助。