JSON-Formatierer
JSON formatieren, prüfen und minifizieren, mit genauer Fehlerstelle.
Entwicklung
Hashtyp anhand des Formats bestimmen.
Die Länge ist der wichtigste Anhaltspunkt, aber sie ist nicht eindeutig.
| Länge (hex) | Wahrscheinliches Verfahren |
|---|---|
| 32 Zeichen | MD5, NTLM |
| 40 Zeichen | SHA-1 |
| 56 Zeichen | SHA-224 |
| 64 Zeichen | SHA-256 |
| 96 Zeichen | SHA-384 |
| 128 Zeichen | SHA-512 |
Ein 32 Zeichen langer Hexwert kann MD5 sein oder NTLM aus der Windows-Welt. Die Länge allein entscheidet das nicht — der Kontext tut es.
Manche Verfahren sind dagegen eindeutig, weil sie ein Präfix mitführen. Ein Wert, der mit $2y$ beginnt, ist bcrypt. $argon2id$ ist Argon2. $6$ deutet auf SHA-512-Crypt hin, wie es in Unix-Systemen verwendet wird.
Diese Präfixe enthalten meist noch den Kostenfaktor und den Salt, was sie sehr gut erkennbar macht.
Bei Base64-kodierten Hashes ändert sich die Länge, und dann hilft die Rückrechnung auf die Bytezahl.
Hier wird die Bestimmung praktisch relevant.
Wenn du in einer Datenbank Passwörter als MD5- oder SHA-1-Werte findest, ist das ein ernstes Problem. Diese Verfahren sind extrem schnell, und genau das macht sie für Passwörter ungeeignet: Eine handelsübliche Grafikkarte probiert Milliarden Kombinationen pro Sekunde durch.
Auch SHA-256 ist als Passwort-Hash ungeeignet, obwohl es kryptografisch nicht gebrochen ist. Der Grund ist derselbe: Es ist zu schnell.
Für Passwörter braucht es absichtlich langsame Verfahren mit einstellbarem Kostenfaktor. Das BSI und die einschlägigen Empfehlungen nennen dafür Argon2, bcrypt und scrypt, sowie PBKDF2 mit hoher Iterationszahl in Umgebungen, wo die anderen nicht verfügbar sind.
Argon2id gilt derzeit als beste Wahl für Neuentwicklungen.
Und ein Salt gehört immer dazu: ein zufälliger Wert pro Passwort, der verhindert, dass gleiche Passwörter gleiche Hashes ergeben und dass vorberechnete Tabellen funktionieren. Die genannten Verfahren erzeugen ihn selbst.
Findest du in einem Bestandssystem MD5-Hashes, ist der übliche Weg: beim nächsten erfolgreichen Login neu hashen und die alten Werte nach und nach ersetzen.
Ein paar Klarstellungen, die immer wieder nötig sind.
Ein Hash ist keine Verschlüsselung. Er ist nicht umkehrbar — es gibt keinen Schlüssel, mit dem man zurückrechnet.
Trotzdem können schwache Hashes "geknackt" werden, und zwar nicht durch Umkehrung, sondern durch Durchprobieren. Bei kurzen oder häufigen Passwörtern reicht dafür oft ein Nachschlagen in einer vorberechneten Tabelle.
Ein Hash sagt auch nichts über die Länge der ursprünglichen Eingabe: Ein Buchstabe und ein ganzes Buch ergeben denselben Hashwert-Umfang.
Für Dateiprüfsummen sind Hashes dagegen ideal, und dort ist SHA-256 die richtige Wahl. Deutsche Behörden und viele Softwareanbieter veröffentlichen Prüfsummen zu ihren Downloads, damit du die Unversehrtheit prüfen kannst.
Bei einer heruntergeladenen Datei lohnt der Vergleich wirklich — er kostet Sekunden und erkennt sowohl Übertragungsfehler als auch manipulierte Downloads.
Dieses Werkzeug arbeitet lokal in deinem Browser.
Nur wahrscheinlich. Viele Verfahren erzeugen gleich lange Werte; Präfixe wie $2y$ sind eindeutig.
Nein. Sie sind viel zu schnell und lassen sich massenhaft durchprobieren.
Argon2id, bcrypt oder scrypt. PBKDF2 mit hoher Iterationszahl, wenn nichts anderes geht.
Er verhindert, dass gleiche Passwörter gleiche Hashes ergeben und vorberechnete Tabellen wirken.
Nein, aber schwache Hashes lassen sich durch Durchprobieren knacken.
Nein.