但是,由于票房系统是基于浏览器的,因此必须在客户端对使用Javascript的客户端进行哈希处理,然后与之前下载的将调用数据进行比较.
但是,当尝试对数字进行散列时,散列总是与创建数据库行时所使用的散列不同(使用VB.NET和sql Server 2008 R2).例如,如果数据库中的CC编号恰好是4444333322221111,则.NET生成的哈希值将变为xU6sVelMEme0N8aEcCKlNl5cG25kl8Mo5pzTowExenM =.
但是,当我使用任何可用的Javascript SHA-256哈希库时,产生的哈希值总是为NbjuSagE7lHVQzKSZG096bHtQoMLscYAXyuCXX0Wtw0 =.
我假设这是某种Unicode / UTF-8问题,但无论我尝试什么,我都无法得到相同的哈希,它开始让我发疯.有人可以提供任何建议吗?
这里可以提供一些见解.请转至http://www.insidepro.com/hashes.php?lang=eng并在“密码”框中插入不带引号的“4444333322221111”.然后,向下滚动到SHA-256部分.
您可以看到有四个结果,其中两个是我发布的哈希码(第二个从顶部是Javascript哈希,最下面一个是sql哈希).根据该页面,底部哈希结果使用base 64字符串生成,并将密码设置为unicode格式.
我已经研究了这个并尝试了许多不同的函数来将密码编码为unicode格式,但无论我尝试什么小调整或我做的其他函数,我都无法得到它来匹配我需要的哈希码.
我目前正在研究在服务器端调用SHA-256函数时使用的参数.
更新:
所以为了确保我没有疯狂,我在调试时运行了我用于立即窗口中的CC编号的Hash方法.同样,结果与以前一样.你可以在这里看到截图:http://i.imgur.com/raEyX.png
解决方法
当您处理两个不受信任的实现时,最好找到另一个独立的实现,并选择与第三个匹配的实现正确.要么是find some test vectors,要么单独验证实现.
编辑:
一个快速实验表明,从.NET获得的SHA-256哈希与hext字符串3400340034003400330033003300330032003200320032003100310031003100匹配 – 小端16位字符.确保传入ASCII.