Hm.. Myslím, že se něco může pokazit, když jsou tyto dvě hodnoty zřetězeny. Hašování by mělo skutečně používat bajtové pole, jako u verze pro šifrování
, ale bohužel
Aktualizace:
Když se rozhlédnu dále, nemyslím si, že existuje čisté řešení CF. Kódování UTF-16LE je pouze částí problému. Dalším problémem je, že DNN dekóduje každý řetězec samostatně , což může produkovat jiné bajty, než když jsou oba dekódovány jako jeden řetězec (viz srovnání níže). V případě vašeho druhého hesla ano, a proto je konečný hash jiný. Od
Porovnání bajtového pole <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>
hash
nebude akceptovat bajtová pole, nemyslím si, že je to ten správný nástroj pro tuto práci. MessageDigest
je správná cesta. 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 | **