GWT / JavaScript客户端密码加密 [英] GWT/Javascript client side password encryption
问题描述
我实施我的GWT应用程序的授权，而且目前它在以下方式进行：
I'm implementing authorization in my gwt app, and at the moment it's done in the following fashion:
- 用户注册时，把他的证件的形式，我以明文形式向服务器发送。
- 服务器code使用散列的BCrypt接收到的密码，并把散在数据库中。
- 当用户登录时，他的密码以明文发送到服务器，即检查其对存储的哈希。
现在。这是困扰我关于这个事情是，我发送密码到服务器中明确的事实，我一直以为我不会很高兴，如果我使用的应用程序这样做，我（的用用户资格一切实物）的密码，但在客户机上进行加密就不会真正赚到我什么，因为攻击者可以只使用哈希密码，因为他们会清楚的。
Now. The thing that's bothering me about this is the fact that I'm sending the password to the server in the clear, I keep thinking that I wouldn't be very pleased if an application I was using did that with my (use-for-everything-kind) password, but encrypting it on the client wouldn't really earn me anything, since the attackers could just use the hashed password as they would the clear one.
我一直<一个href=\"http://www.google.be/#hl=nl&source=hp&q=gwt+client+password+encryption&aq=f&aqi=&aql=&oq=&gs_rfai=&fp=989bd28e744ddd6\">googling整天为这个，似乎互联网是相当一致的，当谈到这一点 - 显然没有什么是从客户端密码加密上涨。 这，的这个和这仅仅是讨论的几个例子和页面我来用，但也有很多很多，都说同样的事情。
I have been googling all day for this, and it seems the Internet is quite unanimous when it comes to this - apparently there is nothing to be gained from client side password encryption. This, this and this are just a few examples of the discussions and pages I've come by, but there are many, many more, all saying the same thing.
这个问题，在这所有的光，似乎有点多余，但我希望在某个地方，某个人，将有另一个答案给我。
This question, in light of all this, might seem a bit unnecessary, but I am hoping that somewhere, someone, will have another answer for me.
我能做些什么， 如果SSL不是在这一点上的，以缓解我心中这个选项？有什么工作要做，还是会实现某种客户端加密服务器 - 解密 - 方案只是费时微弱死马踢？
What can I do, if ssl isn't an option at this point, to ease my mind about this? Is there anything to be done, or will implementing some sort of client-encrypt-server-decrypt-scheme just be time-consuming feeble dead-horse-kicking?
推荐答案
有关登录，SSL应该是你的选择，即使在这一点上。如果它只是登录，你不需要昂贵的SSL农场，但至少你保护（使用换的一切实物）的密码，即使它是明确的，那剩下的通信是不安全的 [ *] 。这可能意味着，你需要购买的只是一个登录服务器的证书，它可以再次为您节省了很多钱，这取决于证书供应商。
For login, SSL should be your option, even at this point. If it's just for login, you don't need an expensive SSL farm, but at least you protect the (use-for-everything-kind) password, even though it's clear, that the remaining communication isn't secured [*]. This may mean, that you need to buy a certificate for just one login server, which can again save you a lot of money, depending on the certificate vendor.
有关GWT，如果您不能负担所有通信进行加密，你必须把登录一个单独的页面上，由于同源策略的限制。
For GWT, if you can't afford to encrypt all communication, you'll have to put the login on a separate page due to Same Origin Policy constraints.
如果仍然不是一个选项，你可以考虑一下通过的OpenID登录中，就像计算器一样。
If that still isn't an option, you can think about logging in via OpenID, just like stackoverflow does.
有不能的任何的安全在不安全的媒体在未经沟通的部分的pre-共享的秘密 - 通常是由安装在浏览器中根证书提供（顺便说一句，这很有趣/恐怖的浏览器，甚至整个操作系统通常是通过HTTP下载）。其它系统，例如PGP，依靠previously建立了信任在网络信任，但这是$只是另一种形式p $ p-共享秘密。有没有办法解决它。
There can't be any secure communication over insecure media without some pre-shared secret - usually provided by the root certificates that are installed in a browser (BTW, it's funny/scary that browsers and even entire operating systems are usually downloaded via HTTP). Other systems, e.g. PGP, rely on previously established trust in a "Web Of Trust", but this is just another form of pre-shared secrets. There's no way around it.
[*]使用一切SSL - 遗憾的是 - 带有更多的实际问题：1）网页的加载速度慢了很多，特别是如果你在页面上的元素。这是由于SSL诱导往返所得的延迟，你不能用柜台甚至最快的SSL农场。问题是缓解，但保持连接没有完全消除。 2）如果你的页面包括来自国外，非HTTPS网站的元素（如使用者插入的图像），许多浏览器会显示警告信息 - 这是对真正的安全问题很模糊，因此通常是一个安全的网站不可接受
一些额外的想法（不推荐）
让我们假设了片刻，即可以不使用SSL在所有的最坏情况。在这种情况下，也许令人惊讶的，发射前散列密码（与盐），实际上可能会有点比什么都不做要好。这里的原因是：它不能击败马洛里（在密码学中，谁可以操纵通信的人），但至少不会让平安夜（一个人谁只能听），阅读明文密码。这可能是值得的东西，如果我们假设前夕比Mallorys更常见（？）但请注意，在这种情况下，你应该散列密码的再次的（不同的盐），相比之前与数据库的价值。
Let's assume the worst case for a moment, i.e. that you can't use SSL at all. In that case, maybe surprisingly, hashing the password (with a salt) before transmitting it, may actually be a bit better than doing nothing. Here's the reason: It can't defeat Mallory (in cryptography, a person who can manipulate the communication), but at least it won't let Eve (a person who can only listen) read the plaintext password. This may be worth something, if we assume that Eves are more common than Mallorys (?) But note, that in that case, you should hash the password again (with a different salt), before comparing it with the database value.
这篇关于GWT / JavaScript客户端密码加密的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
