Java GWT/GWT Ext中密码字符串的md5哈希？

我目前正在尝试修改一个现有的GWTEXT应用程序，即在其MySql数据库中使用纯文本密码

我的计划是使用md5哈希，因为使用MySql函数可以很容易地修改现有密码，我还希望为GWT Ext端找到一个简单的解决方案。但正如我发现的，GWT不支持java.security，而且似乎没有任何其他实现可以用于在客户端将密码字符串更改为md5哈希

到目前为止，我找到的唯一“解决方案”是通过JSNI重新实现md5方法，如下所述：

Ext JS已有一个用户扩展，但我找不到任何适用于GWT Ext的扩展：

有人知道解决这个问题的更优雅/简单的方法吗？也许我应该用别的东西而不是md5来确保密码是加密的

干杯

---

弗兰克

就个人而言，我认为你做错了。我不会在客户端散列密码（这就是GWT）。如果你散列你的密码，毫无疑问你会想盐它，否则你将容易受到攻击。如果您在客户端对其进行hash+salt，您的salt将可供您的用户访问

如果我是你，我会在服务器端对你的密码进行hash+salt操作。这将允许您使用标准Java代码执行MD5哈希

我的2美分

---

-JP

另一个可能适合你需要的想法是零知识认证。（即，服务器永远不需要知道用户的纯文本密码。）

基本上，当设置初始密码时，客户机将用户密码散列N次（其中N是一个较大的数字，如1000），然后将最终散列与N一起发送到服务器。服务器存储散列和N

稍后，当用户想要进行身份验证时，服务器告诉客户端N-1，客户端将用户键入的密码散列N-1次并发送到服务器。服务器对接收到的散列再进行1次散列，并（希望）获得存储的散列。然后服务器存储N-1散列和N-1编号

每次用户进行身份验证时，服务器都会减少存储的N并保存上一个哈希

当N降至0时，用户必须选择并设置新密码

服务器必须确保它从不要求相同的迭代，否则容易受到重播的攻击。您无法从客户端强制执行该条件，因为客户端（尤其是浏览器）无法可靠地跟踪最后N个。您可以使用以下方法在客户端生成哈希：

String getSHA1for(String text) {
  SHA1Digest sd = new SHA1Digest();
  byte[] bs = text.getBytes();
  sd.update(bs, 0, bs.length);
  byte[] result = new byte[20];
  sd.doFinal(result, 0);
  return byteArrayToHexString(result);
}

String byteArrayToHexString(final byte[] b) {
  final StringBuffer sb = new StringBuffer(b.length * 2);
  for (int i = 0, len = b.length; i < len; i++) {
    int v = b[i] & 0xff;
    if (v < 16) sb.append('0');
    sb.append(Integer.toHexString(v));
  }
  return sb.toString();
}

String getsha1（字符串文本）{
SHA1Digest sd=新的SHA1Digest（）；
字节[]bs=text.getBytes（）；
标准差更新（bs，0，bs.长度）；
字节[]结果=新字节[20]；
sd.doFinal（结果为0）；
返回byteArrayToHexString（结果）；
}
String byteArrayToHexString（最终字节[]b）{
最终StringBuffer sb=新StringBuffer（b.长度*2）；
for（int i=0，len=b.length；i

您不应使用md5或其他哈希函数进行密码加密。请参见所需的。它包括许多标准的加密内容。

如果他在客户端执行类似cram-md5的操作，客户端计算hmac（md5哈希加上nonce salt）并将其发送到服务器，这是一个不错的方案。缺点是服务器需要明文密码来检查hmac。彩虹攻击的优点是，以前不知道这一点。我还通过在服务器端进行加密解决了这个问题，但我的想法是，我想在将密码发送到服务器之前对其进行加密，因为我们目前只使用http，不使用https。GWT是客户端和服务器端。除此之外，这篇文章是一个很好的建议。不要在客户端散列它。看一看。非常有趣的想法，以前从未想过。不适合当前的解决方案，但我会记住它以备将来参考，谢谢：-）有趣的想法，所以我花了一些时间考虑它，但它很容易受到中间人攻击。在身份验证请求中，服务器发送一些数字M。攻击者向客户端发送（M-1），然后接收回散列（M-1）。攻击者再次尝试进行身份验证，从服务器接收质询（M-1），并使用哈希（M-1）进行响应。攻击者现在已通过身份验证。是的，听起来确实有问题。我的第一个想法是要求服务器在向客户机发出质询后不要重用M。然而，更大的问题仍然存在，Mallory可以告诉客户端M-100，从客户端收集散列（M-100），然后使用截获的散列登录多达100次。我得去看看我第一次遇到这个项目是不是发现了同样的问题，处理了它，还是放弃了零知识，我想你总是容易受到中间人攻击。键盘记录员也是。还有醉酒后的密码自白。到目前为止，我们只能通过合理的编码努力来提高标准。这个问题已经有将近11年的历史了；-）我现在遇到了完全相同的问题。希望不再尝试使用md5哈希密码——这是我随着时间的推移学到的一件事；-）不适用于密码。我想要一个唯一的和固定大小的文件签名。不担心对手和我作对。我最初移植了一些使用SHA1的代码，但几乎任何哈希都可以工作。如果（客户端）GWT支持更新、更好、更安全的散列，我相信我也能做到这一点。