GWT / GWT-Ext中密码字符串的md5哈希？答案

【问题标题】：md5 hash for password string in GWT/GWT-Ext?GWT / GWT-Ext中密码字符串的md5哈希？
【发布时间】：2010-11-17 08:10:11
【问题描述】：

我目前正在尝试修改现有的 GWT-Ext 应用程序，该应用程序在其 MySql 数据库中使用纯文本密码。

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

到目前为止，我发现的唯一“解决方案”是通过 JSNI 重新实现 md5 方法，如下所述： http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/ad09475a9944c9f8

Ext-JS 有一个现有的用户扩展，但我找不到 GWT-Ext 的任何内容： http://extjs.com/forum/showthread.php?p=133516

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

干杯弗兰克

【问题讨论】：

标签： java javascript gwt md5 gwt-ext

【解决方案1】：

你想要gwt-crypto。它包括许多标准的加密货币。

【讨论】：

这个问题已经有将近十一年的历史了；-)
我现在遇到了完全相同的问题。
希望不再尝试使用 md5 哈希密码 - 这是我随着时间的推移学到的东西之一 ;-)
不适用于密码。我想要一个独特且固定大小的文件签名。不担心对手对我不利。我最初移植了一些使用 SHA1 的代码，但几乎任何哈希都可以工作。如果（客户端）GWT 支持更新、更好、更安全的哈希，我相信我也可以让它为我工作。

【解决方案2】：

您不应该使用 md5 或其他散列函数来加密密码。见http://codahale.com/how-to-safely-store-a-password/

【讨论】：

【解决方案3】：

您可以使用gwt-crypto 在客户端生成SHA-1 哈希值：

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();
}

【讨论】：

【解决方案4】：

另一个可能满足您需求的想法是零知识认证。（即服务器永远不需要知道用户的明文密码。）

基本上，在设置初始密码时，客户端会对用户的密码进行 N 次哈希（其中 N 是一个较大的数字，如 1000），然后将最终哈希与 N 一起发送到服务器。服务器存储哈希和 N .

稍后，当用户想要进行身份验证时，服务器告诉客户端 N-1，客户端将用户输入 N-1 次的密码散列并发送到服务器。服务器在收到的哈希上再做 1 个哈希，并且（希望）获得存储的哈希。然后服务器存储 N-1 个哈希和 N-1 个数字。

每次用户认证时，服务器都会递减存储的N并保存之前的hash。

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

服务器必须确保它永远不会要求相同的迭代，否则它很容易受到重放的影响。您不能真正从客户端强制执行该条件，因为客户端（尤其是浏览器）无法可靠地跟踪最后一个 N。

【讨论】：

非常有趣的想法，以前从未想过。不太适合当前的解决方案，但我会记住它以供将来参考，谢谢:-)
有趣的想法，所以我花了一些时间思考它，但它很容易受到中间人攻击。在身份验证请求中，服务器发送一些数字 M。攻击者将 (M-1) 发送给客户端，并接收回哈希 (M-1)。攻击者尝试再次进行身份验证，从服务器接收挑战（M-1）并以哈希（M-1）响应。攻击者现已通过身份验证。
是的，这听起来确实是个问题。我的第一个想法是要求服务器在向客户端发起挑战后不要重用 M。然而，更大的问题仍然是马洛里可以告诉客户端 M-100，从客户端收集哈希（M-100），然后使用截获的哈希登录多达 100 次。我得去看看我第一次遇到这个问题的项目是否发现了同样的问题并处理了它或者放弃了零知识认证。
我认为你总是容易受到中间人攻击。键盘记录器也是。还醉酒告白密码。到目前为止，我们只能通过合理的编码工作来提高标准。

【解决方案5】：

就个人而言，我会说你做错了。我不会在客户端散列密码（这就是 GWT）。如果你对你的密码进行哈希处理，你无疑会想给它加盐，否则你将容易受到rainbow 攻击。如果您在客户端对其进行哈希 + 加盐，您的用户将可以访问您的盐。

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

我的 2 美分。

-JP

【讨论】：

如果他在客户端执行类似 cram-md5 之类的操作，客户端计算一个 hmac（md5 哈希值加上一个 nonce salt）并将其发送到服务器，这不是一个糟糕的方案。缺点是服务器需要明文密码才能检查hmac。
关于彩虹攻击的好点，以前不知道这个。我还通过在服务器端进行加密来解决它，但我的想法是，我想在将密码发送到服务器之前对其进行加密，因为我们目前只使用 http 而没有 https。
GWT 是客户端和服务器端。除此之外，这篇文章是很好的建议。不要在客户端散列它。看看owasp.org/index.php/Hashing_Java。