Sicherheit von MD5 - Alternativen?

[andreask2]

Hallo!

Grad beim Lesen von MD5 Collision Source Code Released auf /. bin ich in den Kommentaren über folgenden Link gestolpert:

http://www.cits.rub.de/MD5Collisions/

Dort wird beschrieben, wie ohne großartige Rechenleistung 2 Postscript Dokumente (ein "Empfehlungsschreiben" und eine "Bestellung") mit demselben MD5 Hash erstellt werden konnten. Ich vermute mal, dass solche Sachen mit Hilfe des im Artikel beschriebenen Quellcode in Zukunft sogar noch einfacher/effektiver wird (mal abgesehen davon wie schnell die Rechenleistung für "bezahlbare Cluster" steigt...).

Diese Geschichte, zusammen mit den MD5 Datenbanken wie "MD5 Cracker" um "ge-hash-te" Passwörter auszulesen, die man ja auch recht einfach zusammenschalten kann, sollte man IMHO wirklich über Alternativen nachdenken.

Nicht dass diese Idee neu wäre, aber ich denke, dass viele Leute die Gefahr immer noch unterschätzen.

Ich hab grad mal ganz grob überschlagen, mal angenommen man setzt voraus, dass die Anwender maximal 8 Zeichen lange Passwörter verwenden, und aus 50 verschiedenen Zeichen wählen, dann hätte eine vollständige MD5-Datenbank aller möglichen Passwörter eine Größe im höheren Tera-Byte Bereich. Das ist heute durchaus bezahlbar. Für ein ordentliches Wörterbücher und sämtliche Passwörter bis zu 6 Stellen sollte auch ein Aldi-PC ausreichen.

Aber was sind die Alternativen? Bei SHA-1 ist man ja noch lange nicht so weit mit den Angriffen, aber vermutlich ist es auch hier nur eine Frage der Zeit.

Ich benötige Hash-Funktionen vor allem für Passwort-Hashs. Eine Passwort-Datenbank für SHA-1 um gehashte Passwörter zu bekommen sollte IMHO nicht viel aufwändiger sein als für MD5, dauert halt ein bisschen länger und benötigt etwas mehr Speicherplatz. Selbiges gilt für alle anderen Hash-Funktionen, der begrenzende Faktor ist ganz klar das "schlechte" Passwort. Mit langsameren und längeren Prüfsummen wird das ganze zwar erschwert, aber lediglich um ein paar Prozent, nicht exponentiell.

Gut, gegen solche Datenbanken könnte man jetzt einen Salt verwenden, allerdings was nimmt man als Salt? Haltet Ihr es für günstiger, den Salt aus dem Passwort zu verwenden, oder fest ins Script zu schreiben?

Im Moment überlege ich außerdem, welchen Algorithmus ich denn nun verwenden soll.

Folgende stehen zur Auswahl: http://de3.php.net/manual/en/ref.mhash. ... .constants

Im Moment tendiere ich zu SHA-256, was würdet Ihr empfehlen? Herr Schneier empfielt ja auch die SHA-2 Familie, an anderen Stellen habe ich aber gelesen, dass diese zwar theoretisch sicherer sind, aber "unproven" was auch immer man damit sagen will.


Grüße
Andreas

[captaincrunch]

Schau dir mal die aktuelle Diskussion dazu auf /. an:
http://it.slashdot.org/article.pl?sid=05/11/15/2037232

[andreask2]

Ah ja, so weit runter hatte ich noch nicht gelesen ;-)

Gut, was ich noch erfahren habe, war dass es sich beim oben verlinkten Angriff mit den beiden Dokumenten noch nicht um einen pre-image Angriff handelt, sondern die Angreifer brauchen Kontrolle über beide Dokumente.

Dann ist wohl SHA-256 sicher im Moment eine gute Alternative - wobei für Passwörter doch eigentlich auch SHA-1 noch ein paar Jährchen reichen müsste, oder? Denn die ganzen bekannten Angriffe helfen AFAIK kein bisschen, wenn es darum geht Passwörter aus Hashes zu errechnen. Und pre-image Angriffe - selbst wenn das möglich wäre - sind bei der Länge von typischen Passwörtern wieder so unwahrscheinlich, dass selbst solche Angriffe kein Problem darstellen (IMHO).

Die große Gefahr bleiben also Passwort-Datenbanken. Und hiergegen hilft wohl nur der Zwang zu guten Passwortern und ein Salt, der den Angreifer dazu zwingt, jeden Versuch erneut selber zu berechnen - er also keine bestehende Datenbank mit vorausberechneten Hashes verwenden kann.

Die Letzte Frage die sich mir noch stellt lautet, wie so ein Salt aussehen sollte. Es gibt 3 verschiedene Möglichkeiten für ein Salt:

1. irgendeinen festen String (hardcoded in der Anwendung)
2. einen Teil des Passwortes
3. ein zufälliges Salt, was dann zusammen mit dem Passwort gespeichert wir.

Ich denke Methode 3 ist die beste, oder was meint Ihr?

(So funktioniert das ja auch in /etc/shadow und den Apache Passwort-Dateien, AFAIK)

Und was meint Ihr bzgl. SHA-1 vs. SHA-256 bzgl. gehashter Passwörter? Macht es wirklich Sinn sich (im Fall von PHP) die Abhängigkeit einer zusätzlichen Bibliothekt/Extension (mhash) einzuhandeln, wenn doch SHA-1 eigentlich auf absehbare Zeit noch vollkommen ausreichenden Schutz gegen das errechnen von Passwörtern bietet?

[lord_pinhead]

Die Bitkollision von MD5 kann aber meines Wissens nur bei Text-Dokumenten gemacht werden, Binarys werden immer unterschiedlich gehasht. Ã?ber SHA1 könnte man sich streiten, auch dort gibt es eine neue Methode um eine Kollision herbeizuführen (Schneider Blog) . SHA256 oder gar SHA512 sollte erstmal standhalten, allerdings ist der Overhead recht hoch.

Für das erstellen von Hashtables meines Servers würde ich SHA256 nutzen. Meine Passwörter haben zwar "nur" 12 Zeichen mit MD5, aber ich hab mittendrin einfach ein "falsches" Zeichen eingebaut wie z.b. ¶ (ALT+0182), niemand auf der Welt wird eine Rainbow Table mit dem vollen Ascii Satz haben, schon gar nicht mit 12 Zeichen, das Sprengt so ziemlich alles was die Leute an Speicherkapazität haben. Abgesehen von dem Speicherplatz, es würde sogar auf einen Cluster Monate dauern bis diese Tables erstellt sind.

Der Aufwand den man jetzt bräuchte um das zu meistern, geht über die möglichkeiten der meisten Cracker einfach hinaus, von daher wird immer nach einer anderen möglichkeit gesucht soetwas zu umgehen.

Hardcoden von Passwörtern in einer Binary ist auch nicht anzuraten, das ganze kann über ein Hexeditor oder dem Gnu Debugger ausgelesen werden. Bleibt eigentlich nur ein Salt und das Passwort wie du in möglichkeit 3 beschrieben hast :)

[outofbound]

Die Bitkollision von MD5 kann aber meines Wissens nur bei Text-Dokumenten gemacht werden, Binarys werden immer unterschiedlich gehasht.

Wieso? Bit ist Bit. Theoretisch sind Binarys sogar noch einfacher zu fälschen als Text, weil man "beliebigen" Datenmüll hintenanhängen kann, die einfach nur nie genutzt werden. (Was natürlich nix bringt wenn man die Länge als zusätzlichen Parameter verwendet, oder 2 Hashalgos drüberlaufen lässt).

Ã?ber SHA1 könnte man sich streiten, auch dort gibt es eine neue Methode um eine Kollision herbeizuführen

Die gibt es immer. ;) Die Frage ist jeweils wie viel schneller als ein Geburtstagsangriff das ist. Nur weil MD5 meinetwegen jetzt in 2^16 Ticks knackbar ist, heisst das nicht dass md5 unsicher ist, sondern "broken". Die Sicherheit ist halt nur noch 2^16. *grins* Ich
hoffe ihr versteht wie ich das meine. ;)

Für das erstellen von Hashtables meines Servers würde ich SHA256 nutzen. Meine Passwörter haben zwar "nur" 12 Zeichen mit MD5, aber ich hab mittendrin einfach ein "falsches" Zeichen eingebaut wie z.b. ¶ (ALT+0182), niemand auf der Welt wird eine Rainbow Table mit dem vollen Ascii Satz haben, schon gar nicht mit 12 Zeichen, das Sprengt so ziemlich alles was die Leute an Speicherkapazität haben. Abgesehen von dem Speicherplatz, es würde sogar auf einen Cluster Monate dauern bis diese Tables erstellt sind.

Das ist ja grade das witzige an Kollisionen... du kannst nicht
sicherstellen, dass es ein einfaches Passwort (z.B. "doof") gibt,
welches nicht den gleichen Hash wie dein "sicheres" Passwort hat.
;) Natürlich sollte man sichere Passwörter verwenden, aber das
man durch die Hashlänge begrenzt ist, muss man aufpassen. ;)
Sowenig Sinn es macht ein Passwort mit mehr als 12 Zeichen zu
nehmen wenn die Hashlänge 12 Zeichen ist, sollte mans sich
auch überlegen wie viel z.B. 2^64 Versuche denn wirklich sind
und anhand dessen den Hashalgo aussuchen. ;)

Hardcoden von Passwörtern in einer Binary ist auch nicht anzuraten, das ganze kann über ein Hexeditor oder dem Gnu Debugger ausgelesen werden. Bleibt eigentlich nur ein Salt und das Passwort wie du in möglichkeit 3 beschrieben hast :)

[/quote]

If it works and is tried and tested... use it ;)

Gruss,

Out

[lord_pinhead]

Wieso? Bit ist Bit. Theoretisch sind Binarys sogar noch einfacher zu fälschen als Text, weil man "beliebigen" Datenmüll hintenanhängen kann, die einfach nur nie genutzt werden. (Was natürlich nix bringt wenn man die Länge als zusätzlichen Parameter verwendet, oder 2 Hashalgos drüberlaufen lässt).

Nein. Eine Binary kann ich viel schwerer fälschen weil ich nicht einfach an ein Programm irgendwelchen Datenmüll anhängen kann, ich werd wahrscheinlich nie auf den selben Hash kommen. Bei MD5 und Textdateien soll es einfach sein da man einfach 32kilobyte an Daten anhängt und dann soll es der selbe Hash sein wie zuvor.

Die gibt es immer. ;) Die Frage ist jeweils wie viel schneller als ein Geburtstagsangriff das ist. Nur weil MD5 meinetwegen jetzt in 2^16 Ticks knackbar ist, heisst das nicht dass md5 unsicher ist, sondern "broken". Die Sicherheit ist halt nur noch 2^16. *grins* Ich
hoffe ihr versteht wie ich das meine. ;)

So manch paranoider wird sicherlich sagen das es unsicher ist ;)

Das ist ja grade das witzige an Kollisionen... du kannst nicht
sicherstellen, dass es ein einfaches Passwort (z.B. "doof") gibt,
welches nicht den gleichen Hash wie dein "sicheres" Passwort hat.
;) Natürlich sollte man sichere Passwörter verwenden, aber das
man durch die Hashlänge begrenzt ist, muss man aufpassen. ;)
Sowenig Sinn es macht ein Passwort mit mehr als 12 Zeichen zu
nehmen wenn die Hashlänge 12 Zeichen ist, sollte mans sich
auch überlegen wie viel z.B. 2^64 Versuche denn wirklich sind
und anhand dessen den Hashalgo aussuchen. ;)

Daher liefern Kollisionen auch nicht das Passwort und ich fühl mich sicher ;) Eine Kollision ist eigentlich nur dazu da (denk ich jedenfalls ;) ) um jetzt sicher zu gehen das meine Rootkits nicht entdeckt werden, da zb. Tripwire ja sieht das die Hashsumme gleich ist. Das ist dann eigentlich der einzig logische sinn find ich.

MFG
Lord_Pinhead

[Roger Wilco]

Nein. Eine Binary kann ich viel schwerer fälschen weil ich nicht einfach an ein Programm irgendwelchen Datenmüll anhängen kann, ich werd wahrscheinlich nie auf den selben Hash kommen.

Doch, man kann beliebigen Datenmüll z. B. an eine Win32 .exe oder an ein ELF-Binary anhängen. Der Datenbereich ist fest definiert und alles was danach kommt, wird ignoriert. elf(5) sagt dir, wie es funktioniert. Wenn du kurz Zeit hast, kannst du auch Folgendes machen:

Code: Select all

% cat > hello.c
#include <stdio.h>
int main()
{
  printf("Hello World!n");
  return 0;
}
^D
% gcc hello.c
% ./a.out
Hello World!
% cat >> a.out
Dieser Text wird niemals nie nicht angezeigt, aber das Binary funktioniert trotzdem noch problemlos!
^D
% ./a.out
Hello World!

Na, merkst du was? Was glaubst du im Ã?brigen, was Viren eigentlich so machen? ;)

So manch paranoider wird sicherlich sagen das es unsicher ist ;)

Ist es ja auch. Die Frage ist dabei aber immer, für wen die Daten eigentlich interessant sind. Du wirst feststellen, dass die kryptografischen Funktionen und Verfahren, die heutzutage im Einsatz sind, größtenteils darauf basieren, dass man zum Knacken via Bruteforce einfach zu lange brauchen würde, so dass die gewonnene Information wertlos wird. (Bitte kommt mir jetzt nicht mit Quantenkryptographie. Ich habe geschrieben "heutzutage im Einsatz" ;))

Daher liefern Kollisionen auch nicht das Passwort und ich fühl mich sicher ;)

Ã?hm, du hast ein supertolles, alphanumerisches Passwort mit Sonderzeichen und einer Länge von sagen wir 30 Zeichen. Zufällig hat das Passwort aber den gleichen Hash wie "abc", "gott" oder "ficken". Wenn für das Passwort nicht 2 Hashes (mit unterschiedlichen Verfahren) oder die Länge gespeichert werden, siehst du damit ganz schön alt aus. Egal wie sicher du dich fühlst.

Eine Kollision ist eigentlich nur dazu da (denk ich jedenfalls ;) ) um jetzt sicher zu gehen das meine Rootkits nicht entdeckt werden, da zb. Tripwire ja sieht das die Hashsumme gleich ist. Das ist dann eigentlich der einzig logische sinn find ich.

Naja, es ist ja nicht so, dass die Kollisionen absichtlich in einen Algorithmus eingebaut werden. Sie sind einfach unumgänglich, wenn man einen Plaintext von n Zeichen (n beliebig) auf 32 Hexziffern (z. B. MD5) abbildet.

[outofbound]

Mr. Wilco hat eigentlich alles gesagt, was es dazu zu sagen gibt, deswegen einfach: ACK ;)

Noch als Nachtrag: Wie RW schon ausführlich beschrieben hat, ist das fälschen von Binarys also ohne weiteres möglich. Das üble daran: Im Vergleich zu reinem "Text" erkenne ich bei einem Binary nicht, was "Müll" ist und was nicht, ohne das komplette Programm zu debuggen.
Das führt dazu, dass z.B. zwei Tools, die völlig unterschiedliche Aufgaben erfüllen, den gleichen Hash haben können, da man eben ein "Hashen" von n Bit zu x Bit mit n > x garantiert nicht ohne Kollision hinbekommt. Deshalb kann auch das Password "MWheagwedzsgdeA" den gleichen Hash wie "gott" haben, mit beiden Passwords kommt der User ins System. Daher fahre ich auch Wörterbuchattacken auf meine eigenen Passwörter, um zu vermeiden das ich ausversehen ein Passwort verwende das den gleichen Hash wie ein simples Passwort hat.

Gruss,

Out

[oxygen]

Es ist per Definition nunmal so, dass es bei Hashverfahren Kollisionen gibt. Es ist ja kein perfektes Komprimierungsverfahren. Wenn man damit ein Problem hat, sollte man nicht umbedingt Hashverfahren einsetzten. Für Passwort Hashing sollte md5 noch lange ausreichen. Es ist ja nun doch schon so, dass der Hash nur eine zusätzliche Sicherheitsmaßname darstellt, die erst greift, wenn das Kind schon in den Brunnen gefallen ist.