SHA1 哈希值的微小差异
我正在从事的一个项目使用 Apache Shiro 作为安全框架。密码经过 SHA1 哈希处理(无盐,无迭代)。登录受 SSL 保护。但是,应用程序的其余部分不受 SSL 保护。在这种情况下(无 SSL),应该有一个用户可以更改密码的表单。 由于直接传输它不是一个好主意,因此应该在客户端上对其进行哈希处理,然后传输到服务器。由于客户端是基于 GWT (2.3) 的,我正在尝试这个库 http://code.google。 com/p/gwt-crypto,它使用来自 bouncycastle 的代码。 然而,在许多情况下(不是全部),两个框架生成的哈希值相差 1-4(?) 个字符。 例如,
"fe7f3cffd8a5f0512a5f1120f1369f48cd6f47c2"
两个实现都对“happa3”进行哈希处理,而
"fb3c3a741b4e07a87d9cb68f3db020d6fbfed00a"
Shiro 实现和
"fb3c3a741b4e07a87d9cb63f3db020d6fbfed00a"
gwt-crypto 实现则仅对“happa”进行哈希处理(第 23 个字符不同)。 我想知道是否存在“正确”/标准 SHA1 哈希,以及其中一个库是否存在错误,或者我对它们的使用是否存在缺陷。 我的第一个想法是由于不同的传输机制(RPC 与 Post)导致的不同编码或奇怪的转换有关。但据我所知(这也是我最困惑的地方),如果只有一位的差异,SHA1 哈希值很可能会完全不同。所以不同的编码不应该是这里的问题。 我在客户端(GWT)上使用此代码进行散列:
String hashed = toHex(createSHA1Hash("password"));
...
private String createSHA1Hash(String passwordString){
SHA1Digest sha1 = new SHA1Digest();
byte[] bytes;
byte[] result = new byte[sha1.getDigestSize()];
try {
bytes = passwordString.getBytes();
sha1.update(bytes, 0, bytes.length);
int val = sha1.doFinal(result, 0);
} catch (UnsupportedEncodingException e) {}
return new String(result);
}
public String toHex(String arg) {
return new BigInteger(1, arg.getBytes()).toString(16);
}
在服务器(Shiro)上使用此代码:
String hashed = new Sha1Hash("password").toHex()
afaics 在幕后执行非常相似的操作(快速查看源代码)。 我在这里错过了一些明显的事情吗?
编辑:似乎 GWT 代码由于某种原因无法本机运行(即仅在开发模式下)并且默默地失败(尽管它确实可以编译)。必须找出原因......
编辑(2):“int val = sha1.doFinal(结果,0);”是造成麻烦的行,即如果存在,整个代码不会在本机(JS)中运行,而只能在开发模式下运行(结果错误)
A project I am working on uses Apache Shiro as a security framework. Passwords are SHA1 hashed (no salt, no iterations). Login is SSL secured. However, the remaining part of the application is not SSL secured. In this context (no SSL) there should be a form where a user can change the password.
Since it wouldn't be a good idea to transmit it plainly it should be hashed on the client and then transmitted to the server. As the client is GWT (2.3) based, I am trying this library http://code.google.com/p/gwt-crypto, which uses code from bouncycastle.
However, in many cases (not all) the hashes generated by both frameworks differ in 1-4(?) characters.
For instance "happa3" is hashed to
"fe7f3cffd8a5f0512a5f1120f1369f48cd6f47c2"
by both implementations, whereas just "happa" is hashed to
"fb3c3a741b4e07a87d9cb68f3db020d6fbfed00a"
by the Shiro implementation and to
"fb3c3a741b4e07a87d9cb63f3db020d6fbfed00a"
by the gwt-crypto implementation (23rd character differs).
I wonder whether there is a "correct"/standard SHA1 hashing and whether there is a bug in one of the libraries or maybe my usage of them is flawed.
One of my first thoughts was related to different encodings or strange conversions due to different transport mechanisms (RPC vs. Post). To my knowledge though (and what puzzles me most), SHA1 hashes should differ completely with a high probability if there is just a difference of a single bit. So different encodings shouldn't be the issue here.
I am using this code on the client (GWT) for hashing:
String hashed = toHex(createSHA1Hash("password"));
...
private String createSHA1Hash(String passwordString){
SHA1Digest sha1 = new SHA1Digest();
byte[] bytes;
byte[] result = new byte[sha1.getDigestSize()];
try {
bytes = passwordString.getBytes();
sha1.update(bytes, 0, bytes.length);
int val = sha1.doFinal(result, 0);
} catch (UnsupportedEncodingException e) {}
return new String(result);
}
public String toHex(String arg) {
return new BigInteger(1, arg.getBytes()).toString(16);
}
And this on the server (Shiro):
String hashed = new Sha1Hash("password").toHex()
which afaics does something very similar behind the scenes (had a quick view on the source code).
Did I miss something obvious here?
EDIT: Seems like the GWT code does not run natively for some reason (i.e. just in development mode) and silently fails (it does compile, though). Have to find out why...
Edit(2): "int val = sha1.doFinal(result, 0);" is the line that makes trouble, i.e. if present, the whole code does not run natively (JS) but only in dev-mode (with wrong results)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
您可以测试这个版本:
我在客户端 sha 生成中使用它,并且运行良好。
You could test this version:
I'm using it in my client side sha generation and it worked well.