MD5, SHA-1 und SHA-256: einen Hash auswählen

Ein Hash fasst eine Datei oder Nachricht in einer kurzen Zeichenfolge zusammen, doch dieses Wort beantwortet noch keine Sicherheitsfrage. MD5, SHA-1 und SHA-256 haben unterschiedliche Geschichten und Eigenschaften. Eine Übereinstimmung kann eine veränderte Übertragung erkennen, wenn der erwartete Wert von einem vertrauenswürdigen Herausgeber stammt. Sie beweist nicht allein, wer die Datei veröffentlichte, schützt keine Passwortdatenbank und macht einen unsignierten Download nicht authentisch. Vor der Algorithmuswahl müssen diese Aufgaben getrennt werden.

Das Problem

Eine kryptografische Hashfunktion erhält Bytes beliebiger Länge und liefert einen Digest fester Länge. Sie ist deterministisch: Dieselben Bytes ergeben denselben Wert. Sie soll außerdem so wirken, dass eine Änderung der Bytes den Wert schwer vorhersehbar verändert. Das macht Hashes für Integritätsprüfungen, Build-Artefakte und Signaturen nützlich. Es bedeutet nicht, dass alle Algorithmen einem absichtlichen Angreifer gleich gut standhalten.

MD5 erzeugt 128 Bit, SHA-1 erzeugt 160 Bit. RFC 6151 und RFC 6194 beschreiben Kollisionsangriffe und raten von beiden ab, wenn Kollisionsresistenz zählt. Eine Kollision bedeutet, dass zwei verschiedene Eingaben mit demselben Hash konstruiert werden können. SHA-256 gehört zur in FIPS 180-4 festgelegten SHA-2-Familie und ist unter diesen drei die übliche Wahl für eine neue allgemeine Integritätsprüfung. Das ist weder Herkunftsauthentisierung noch sichere Passwortspeicherung.

Die erste Frage lautet daher nicht, welche Hexadezimalzahl am stärksten aussieht, sondern welche Entscheidung sie tragen soll. Versehentliche Beschädigung erkennen, einen Passwortprüfwert speichern, die Freigabe einer Version durch einen Herausgeber belegen und ein Dokument signieren sind verschiedene Probleme. Jedes überschreitet eine andere Vertrauensgrenze und benötigt meist eine andere Konstruktion um die Hashfunktion herum.

Praktisches Beispiel

Angenommen, ein Projekt veröffentlicht `tool-4.2.zip` und den SHA-256-Wert auf seiner offiziellen HTTPS-Release-Seite. Berechnen Sie nach dem Download SHA-256 über die geladenen Bytes und vergleichen Sie jedes Zeichen mit dem Wert dieser vertrauenswürdigen Seite. Bei einer Abweichung stoppen Sie: Die Datei kann unvollständig, verändert oder eine andere Version sein. Bei Übereinstimmung entsprechen die lokalen Bytes den Bytes, die die veröffentlichte Referenz beschreibt.

Diese Aussage hat eine entscheidende Bedingung. Kann ein Angreifer sowohl ZIP als auch Prüfsumme auf der Seite ersetzen, entsteht weiterhin eine Übereinstimmung. Der Vergleich beweist nicht die Identität des Herausgebers; er beweist Gleichheit mit der beschafften Referenz. Eine Prüfsumme aus einem unbekannten Mirror, einer unsignierten Nachricht oder einem Suchtreffer besitzt keine unabhängige Autorität. Beziehen Sie Metadaten über einen vom Herausgeber kontrollierten Kanal und prüfen Sie dessen Identität getrennt.

Bei Passwörtern ist die Lage anders. Ein Dienst darf nicht einfach MD5, SHA-1 oder SHA-256 eines Passworts speichern. Schnelle allgemeine Hashes erlauben nach einem Datenleck viele Offline-Versuche. Passwortspeicherung benötigt ein dafür geschaffenes Verfahren mit Salt und anpassbaren Rechen- oder Speicherkosten, das der Dienst auswählt und konfiguriert. Einen Download zu vergleichen ist keine Passwortspeicherung.

Vorgehensweise

Für eine Download-Prüfung bestimmen Sie zuerst exakten Namen, Version und Herausgeber. Laden Sie möglichst vom offiziellen Release-Ort. Beschaffen Sie die Prüfsumme über einen zweiten vertrauenswürdigen Ort oder ein signiertes Manifest, wenn der Herausgeber eines anbietet. Bewahren Sie Dateiname und Digest zusammen auf, damit nicht versehentlich das ZIP 4.2 mit der Prüfsumme von 4.1 verglichen wird.

Berechnen Sie SHA-256 über die ursprüngliche geladene Datei, nicht über einen entpackten Ordner oder ein Dokument, das eine Anwendung geöffnet und erneut gespeichert hat. Kopieren Sie den vollständigen hexadezimalen Digest. Der Vergleich muss eine Differenz zurückweisen; er darf Bytes nicht stillschweigend kürzen, normalisieren oder ändern. Bei einem Unterschied löschen oder isolieren Sie den Download und beziehen ihn erneut. Ändern Sie nicht den erwarteten Wert, um ein positives Ergebnis zu erhalten.

Wenn stärkere Herkunftsnachweise nötig sind, folgen Sie den Signaturprüfanweisungen des Herausgebers. Eine digitale Signatur bindet Release-Daten an einen privaten Schlüssel; sie wird mit dem zugehörigen öffentlichen Schlüssel und einer Vertrauensentscheidung über diesen Schlüssel geprüft. Vergleichen Sie den Fingerabdruck des Schlüssels oder Zertifikats über einen vertrauenswürdigen Kanal, prüfen Sie die Signatur über die richtigen Metadaten und beachten Sie Widerrufe oder Schlüsselwechsel. Auch eine Signatur braucht korrekte Schlüsselverteilung und Richtlinien.

Technische Erklärung

Kollisionsresistenz fragt, ob ein Angreifer zwei verschiedene Eingaben mit demselben Digest finden kann. Präbildresistenz fragt, ob er zu einem Digest eine passende Eingabe finden kann. Zweitpräbildresistenz fragt, ob er zu einer bekannten Eingabe eine andere mit demselben Resultat finden kann. Diese Eigenschaften hängen zusammen, sind aber nicht austauschbar. Ein Protokoll sollte benennen, welche davon es braucht, statt die Digestlänge als universelle Bewertung zu behandeln.

Bekannte praktische Kollisionen machen MD5 und SHA-1 für neue kollisionssensitive Einsätze ungeeignet, etwa Zertifikate, signierte Artefakte und Dokumentabläufe. Ein Altsystem kann sie noch für Kompatibilität oder nicht sicherheitsrelevante Kennungen anzeigen; das ist keine Empfehlung. Für eine neue Dateiintegritätskonvention ist SHA-256 vorzuziehen, auch wenn ein bestimmtes Protokoll einen anderen standardisierten Algorithmus oder ein anderes Format verlangt.

Ein Digest enthält weder Datum noch Herausgebernamen noch die Zusage, eine Datei sei gefahrlos ausführbar. Schadsoftware kann einen korrekten SHA-256 haben, wenn der Angreifer auch die Referenz geliefert hat. Ebenso sagt eine gültige Signatur, dass ein bestimmter Schlüssel Daten signierte; sie ersetzt nicht die Prüfung, ob der Schlüssel zum erwarteten Herausgeber gehört oder ob die Software zur eigenen Umgebung passt.

Häufige Fehler

Ein häufiger Fehler ist, MD5 oder SHA-1 für akzeptabel zu halten, weil ein Werkzeug sie noch anbietet. Ihre Verfügbarkeit erhält Interoperabilität, nicht Sicherheitseignung. Ein anderer Fehler ist, SHA-256 direkt für Passwörter einzusetzen, weil es neuer als MD5 ist. Die Geschwindigkeit, die große Dateien schnell hasht, beschleunigt auch Offline-Passwortraten. Passwortverfahren fügen Salt und absichtliche Kosten hinzu; ihre Einstellung richtet sich nach Bedrohungsmodell und Hardware.

Fehlerhaft ist auch, nur ein Digest-Präfix zu vergleichen, Groß- oder Kleinschreibung und Leerraum ohne Verständnis des Formats zu akzeptieren oder eine Textdarstellung statt der Binärdatei zu hashen. Das kann irreführende Treffer erzeugen oder Unterschiede verdecken. Verwenden Sie das vom Herausgeber dokumentierte Format, behalten Sie den vollständigen Wert und wiederholen Sie die Rechnung nach einem erneuten Download.

Veröffentlichen Sie nicht bloß eine Prüfsumme neben einem Download und nennen sie Signatur. Gegen zufällige Beschädigung hilft sie nur, wenn ihre Referenz bereits vertrauenswürdig ist. Wenn Herkunft zählt, veröffentlichen Sie überprüfbare Signaturen, klare Hinweise zur Schlüsselverteilung und Release-Schritte. Importieren Sie keinen Schlüssel aus Kommentaren, Tickets oder eingefügten Nachrichten ohne unabhängige Prüfung.

Wichtige Überlegungen

Hashing kann Informationen über Eingaben mit geringer Entropie verraten. Stammt ein Wert aus einer kleinen vorhersehbaren Menge, kann jemand Kandidaten hashen und Ergebnisse vergleichen. Behandeln Sie einen Hash nicht als Anonymisierung von Namen, E-Mail-Adressen, kurzen Kennungen oder Passwörtern. Salts, Zugriffskontrollen und Datensparsamkeit sind unterschiedliche Kontrollen für unterschiedliche Risiken.

Integritätsprüfungen benötigen zudem betriebliche Sorgfalt. Dokumentieren Sie in der Release-Automatisierung Algorithmus, vollständigen Digest, Artefakt, Version, Quell-URL und Datum. Erzeugen Sie die Prüfsumme, soweit möglich, aus reproduzierbarer Build-Ausgabe und schützen Sie den Veröffentlichungsweg. Testen Sie in einer Übung ein absichtlich verändertes Artefakt, damit ein Unterschied den Ablauf nachweislich stoppt. Das verringert Zufallsfehler, ohne zu behaupten, ein Hash allein authentisiere Software.

Nutzen Sie einen lokalen Hashgenerator nur für Material, das Sie verarbeiten dürfen. Für sensible Dateien ist ein geprüfter lokaler Betriebssystembefehl oder ein freigegebener interner Ablauf vorzuziehen. Ein Browserwerkzeug kann eine Berechnung zeigen, bescheinigt aber nicht die Herkunft seiner Eingabe, die Vertrauenswürdigkeit einer kopierten Referenz oder die Sicherheitsrichtlinie des Empfängers.

Grenzen

Dieser Leitfaden ist ein begrifflicher Vergleich. Er ersetzt weder das Prüfverfahren eines Anbieters noch eine kryptografische Begutachtung oder Incident Response. Er zertifiziert kein Release, keinen Schlüssel, keine Website, keinen Passwortmanager und keine Hashimplementierung. Standards und Angriffe entwickeln sich weiter; bei Systemen mit hohem Schadenspotenzial gelten aktuelle Herausgeberhinweise und Anforderungen des passenden Protokolls.

Er liefert auch keinen privaten Schlüssel, kein verwendbares Passwort und keine Anweisungen zum Umgehen von Prüfungen. Tritt bei benötigter Software ein Prüfsummenunterschied auf, bewahren Sie die von Ihrer Organisation verlangten Belege auf, kontaktieren Sie den offiziellen Herausgeber und nutzen Sie eine als gut bekannte Quelle. Verteilen Sie das verdächtige Artefakt nicht nur, damit andere es vergleichen können.

Checkliste

Wählen Sie SHA-256 statt MD5 oder SHA-1 für eine neue allgemeine Prüfsumme. Vergleichen Sie den vollständigen Digest der exakten Bytes mit einer Referenz aus einem vertrauenswürdigen Herausgeberkanal. Eine Übereinstimmung bedeutet Gleichheit mit dieser Referenz, nicht Identitätsbeweis. Nutzen Sie Signaturen und verifizierte Schlüssel, wenn Herkunft wichtig ist. Für Passwörter verwenden Sie ein adaptives Verfahren mit Salt, nie blankes MD5, SHA-1 oder SHA-256. Halten Sie Algorithmus, Artefakt, Version, Herkunft und Ergebnis zusammen fest und stoppen Sie bei jeder Abweichung.