うーん.. 2 つの値を連結すると、何か問題が発生する可能性があると思います。ハッシュは、暗号化バージョンと同様に 、実際にはバイト配列を使用する必要があります。 、残念ながら CF9 の hash() 関数はそれをサポートしていません - 文字列のみです。 (十分に文書化されていませんが、CF11 でサポートされています)。 CF9 の純粋な CF 回避策があるかどうかはわかりません。ただし、当面は Java を直接使用できます:
<cfscript>
thePassword = "[email protected]";
base64Salt = "+muo6gAmjvvyy5doTdjyaA==";
// extract bytes of the salt and password
saltBytes = binaryDecode(base64Salt, "base64");
passBytes = charsetDecode(thePassword, "UTF-16LE" );
// next combine the bytes. note, the returned arrays are immutable,
// so we cannot use the standard CF tricks to merge them
ArrayUtils = createObject("java", "org.apache.commons.lang.ArrayUtils");
dataBytes = ArrayUtils.addAll( saltBytes, passBytes );
// hash binary using java
MessageDigest = createObject("java", "java.security.MessageDigest").getInstance("SHA-1");
MessageDigest.update(dataBytes);
theBase64Hash = binaryEncode(MessageDigest.digest(), "base64");
WriteOutput("<br />theBase64Hash= "& theBase64Hash &"<br/>");
WriteOutput("DBPassword= nfcqQBgeAm0Dp1oGZI0O70Y6DvA= <br />");
</cfscript>
更新:
さらに調べてみると、純粋な CF ソリューションはないと思います。 UTF-16LE エンコーディングは問題の一部にすぎません。もう 1 つの問題は、DNN が各文字列を個別にデコードすることです。 、両方が単一としてデコードされた場合とは異なるバイトを生成する可能性があります 文字列 (以下の比較を参照)。 2 番目のパスワードの場合はそうです。これが、最終的なハッシュが異なる理由です。 hash
以来 はバイト配列を受け入れません。この仕事に適したツールではないと思います。 MessageDigest
バイト配列の比較
old| new |
1 | -6 | -6 |
2 | 107 | 107 |
3 | -88 | -88 |
4 | -22 | -22 |
5 | 0 | 0 |
6 | 38 | 38 |
7 | -114 | -114 |
8 | -5 | -5 |
9 | -14 | -14 |
10 | -53 | -53 |
11 | -105 | -105 |
12 | 104 | 104 |
13 | -3 | 77 | **
14 | -1 | -40 | **
15 | 68 | -14 | **
16 | 0 | 104 | **
17 | 84 | 68 | **
18 | 0 | 0 |
19 | 33 | 84 | **
20 | 0 | 0 |
21 | 64 | 33 | **
22 | 0 | 0 |
23 | 49 | 64 | **
24 | 0 | 0 |
25 | 50 | 49 | **
26 | 0 | 0 |
27 | | 50 | **
28 | | 0 | **
- 古い => charsetDecode( theSalt &thePassword, "UTF-16LE")
- 新しい => ArrayUtils.addAll( saltBytes, passBytes );