byte passwordByte[] = password.getBytes();
MessageDigest md = MessageDigest.getInstance("SHA-512");
byte passwortHashByte[] = md.digest(passwordByte);
BitSet bs = new BitSet(passwortHashByte.length * 8);
int i = 0;
for (byte b : passwortHashByte) {
for (int j = 7; j >= 0; j--) {
if ((1 << j & b) != 0) {
bs.set(i);
}
i++;
}
}
System.out.println(bs.toString() /* z. B. */);
System.out.println( );```
und dann z. B. mappen auf Null bis Semikolon, A bis Z und a bis z (12, 26 und 26 = 64 = 6 Bit).
Allerdings scheint mir die Methode von Slaters Link besser zu sein:
StringBuffer hexString = new StringBuffer();
for (int i=0;i<mdbytes.length;i++) {
hexString.append(Integer.toHexString(0xFF & mdbytes**));
}
System.out.println("Hex format : " + hexString.toString());```[/QUOTE]
Sowas meinte ich in etwa. Das ist auch die Ausgabe, die man bei diversen Online Hashrechnern erhält.
Mein Ziel ist es, das ganze in die DB zu speichern. Ich würde dann jetzt den String im Hexformat in die DB speichern.
Danke allen ;)
byte passwordByte[] = password.getBytes();
MessageDigest md = MessageDigest.getInstance("SHA-512");
byte passwortHashByte[] = md.digest(passwordByte);
for (byte b : passwortHashByte) {
System.out.println(String.format("%8s", Integer.toBinaryString(0xFF & b)).replace(' ', '0'));
}```
The vorletzte Zeile is so wichtig, man sollte sie sich memorieren. :mad:
@Threadersteller: Diese Funktionalität gibt es fertig in der Apache Commons Bibliothek: [%29"] DigestUtils.sha512Hex(byte)](DigestUtils (Apache Commons Codec 1.9 API)[)
Buggy. Integer.toHexString() erzeugt keine führenden Nullen für bytes zwischen 0 und 15.
Richtig geht es so:``` public String toHex(final byte bytes) {
final StringBuilder builder = new StringBuilder(bytes.length * 2);
for(final byte b : bytes) {
builder.append(String.format(„%02X“, b));
}
Sehe ich absolut nicht so. Entweder nimmt man für Datenbanken die hexcodierte Variante, weil es die Standarddarstellung ist. Das hat den Vorteil, dass man die Werte in der Datenbank direkt lesen kann. Außerdem hat sie den Vorteil, dass sie effizient (de)codiert werden kann.
Die Alternative ist, ein binäres Feld einer festen Länge zu verwenden (Typ Binary: http://dev.mysql.com/doc/refman/5.6/en/binary-varbinary.html), wenn man keinen Wert auf lesbare Felder legt. Damit spart man gegenüber der hexcodierten Variante 50% Speicherplatz und gegenüber der Base64-codierten immerhin noch 33% (32 vs 24 vs 16 Byte bei MD5). Außerdem muss man gar nicht mehr codieren, was am effizientesten ist.
Mit einem Binary-Feld kann man auch die Hexdarstellung benutzen, zumindest MySQL versteht hexcodierte Binärfelder als Eingabe (als String der Form 0xabcdef) und kann auch hexcodiert ausgeben (HEX(feldname)).
[QUOTE=cmrudolph]Sehe ich absolut nicht so.[/QUOTE]Jedem das Seine. Woher weiss man denn immer, dass die DB-Implementation unbedingt immer Binärdaten speichern kann? Richtig, gar nicht. Z.B. wenn man in eine XML basierte DB speichern will, ist Base64 die günstigste alternative zwischen Binär und Zeichensatz. Auf Lesbarkeit kommt es bei Binärdaten ohnehin nicht an, schon gar nicht bei Password-Hashes. Kennst du diese Seite hier? DB gehackt, MD5-HexStrings entführt und los gehts. Bei Base64 hat man evtl. noch Mühe drauf zu kommen, was das sein könnte.