Hashes
-
interessierter schrieb:
1. Warum werden MD5 und SHA-0/1 als "broken" angesehen, SHA256/512 aber nicht? Mich interessiert hier der Knackpunkt an dem gemessen entschieden ist, wann ein Hash Algorithmus als "broken" gesehen wird, keine vollständige Kryptoanalyse.
Also ich hoffe dass ich es richtig verstanden habe, und halbwegs richtig wiedergeben kann. Falls das Teilweise Unsinn und/oder unklar ist bitte berichtigen.
"broken" heisst dass Möglichkeiten ("Angriffe") gefunden wurden mit praktikablem Aufwand Kollisionen zu erzeugen. Wobei praktikabler Aufwand bedeutet dass die Chance besteht das mit optimistisch geschätzter Entwicklung der Technik und grossem finanziellen Aufwand in absehbarer Zeit durchführen zu können. Ganz besonders schlimm natürlich wenn es mit heutiger Technik und einem einzigen dicken PC machbar ist.
Und es gibt mehrere Fälle bzw. Kategorien von Angriffen zu unterscheiden. Dementsprechend mehr oder weniger "broken" kann ein Algorithmus sein.
Nennen wir die beiden zu hashenden Datensätze (Files, Strings - Byte-Würste halt) mal A und B. Eine Kollision ist dann wenn hash(A) == hash(B).
Nicht sehr schlimm ist, wenn der Angrif der die Kollisionen erzeugt A und B vollständig vorgibt. Also andersrum: keinerlei Einschränkungen bezüglich A und keinerlei Einschränkungen bezüglich B erlaubt. Man kann dann zwar hübsch massenweise Kollisionen erzeugen, aber man kann mit den Paaren (A,
die dabei rauskommen in den meisten Fällen nix anfangen. Sind halt irgendwelche Datenwürste die den gleichen Hashcode haben. Vermutlich gibt es einige Anwendungen wo sogar das schon schlimm wäre, aber bei den Sachen die mir jetzt einfallen könnte man damit maximal ein wenig Verwirrung stiften.Schlimm ist dagegen, wenn ich ein A so "vorbereiten" kann, dass ich mit dem "vorbereiteten" A (nennen wir es A') einfach eine Kollision erzeugen kann.
Wobei "vorbereiteten" jetzt heisst ich modifiziere Teile von A auf eine ganz bestimmte Art & Weise.
z.B. ich füge in einem File einen Padding-Block/Kommentar-Block/... ein der mit vom Angriff vorgegebenen Daten angefüllt werden kann.
Wenn ich mir dann noch aussuchen kann welche Änderung ich in B' haben möchte ist die Kacke am dampfen.Angenommen ich habe ein File-Format das eben solche Padding-Blöcke erlaubt - wozu auch immer. Möglicherweise um das dauernde Umkopieren von Daten zu vermeiden wenn nur kleine Änderungen gemacht werden. Wenn ich mich richtig erinnere erlaubt ID3v2 (z.B. in einem MP3 File) sowas.
Dann kann ich ein File A so abändern dass ich ein A' erhalte das vollkommen "normal" aussieht, ein 100% gültiges Exemplar seines File-Formats ist, und gleichzeitig an einer passenden Stelle die vom Angriff vorgegebenen Daten enthält.
Dieses A' lasst ich mir dann von irgendwem signieren.
Und dann lasse ich mir ein B' mit ein paar gewünschten Änderungen erzeugen (bzw. u.U. sogar komplett anderem Inhalt), wobei der Angriff dann z.B. die Daten im Padding-Block beliebig abändern kann um die Kollision zu erzeugen.
Und schwupps: B' die für A' erzeugte Signatur gilt ebenso für B'. Böse Sache.Etwas allgemeiner formuliert: sobald man Bedingungen für Teile von A und B vorgeben kann, kann man damit vermutlich böse Dinge anstellen.
Und katastrophal ist es, wenn man A komplett vorgeben kann, und Teile der gewünschten Änderung in B. Dann muss man die Schummelei nämlich nichtmal vorbereiten.
War es das was du wissen wolltest?
2. Gibt es für asymmetrische Verschlüsselungen auch so einen quasi Standard, wie es für symmetrische Verfahren AES ist? (RSA vielleicht?)
Ich kenne zwei Verfahren die sich beide grosser Beliebtheit erfreuen, und beide quasi-standard sind: RSA und ECC (Elliptic Curve Cryptography).
Beide werden z.B. ausgiebigst für Zertifikate eingesetzt.
Ich würde aber nicht behaupten dass eines davon "mehr standard" ist als das andere.Mein klarer Favorit ist ECC. Wobei ich auch den Eindruck habe dass allgemein die Tendenz zu ECC geht. Weil man die gleiche Sicherheit mit wesentlich kürzeren Schlüsseln bekommt.
-
-
hab ich jetzt das forum kaputt gemacht
-
_-- schrieb:
hab ich jetzt das forum kaputt gemacht
Ja. Mach sofort den Thread wieder heile!
-
cooky451 schrieb:
_-- schrieb:
hab ich jetzt das forum kaputt gemacht
Ja. Mach sofort den Thread wieder heile!
-
@hustbaer
Wenn ich mir das so durchlese, bedeutet das doch, dass das Speichern von Passwörtern als gesalzene MD5 Hashes immernoch sicher ist? (Also man kann die Passwörter nicht mehr in Klartext herstellen oder einen Klartext finden, der den gleichen Hash erzeugt.)
-
cooky451 schrieb:
@hustbaer
Wenn ich mir das so durchlese, bedeutet das doch, dass das Speichern von Passwörtern als gesalzene MD5 Hashes immernoch sicher ist? (Also man kann die Passwörter nicht mehr in Klartext herstellen oder einen Klartext finden, der den gleichen Hash erzeugt.)Korrekt.
Trotzdem ist md5 für Passwörter blöd. Weil MD5 ist zu schnell. Man will für Passwörter einen langsamen Hash Alogorithmus haben.
Aber solange gut gesalzen ist, ists sicher genug.
Die Sicherheit eines Hash Algos hat damit aber nichts zu tun. Die Sicherheit sagt aus wie schwer es ist Kollisionen generieren zu können. Schwache Hashes erleichtern es nicht an den Klartext zu kommen, sie erleichtern nur Kollisionen (was oft reicht, aber zB bei knacken einer geklauten DB mit Passwörtern wäre es egal).
-
Shade Of Mine schrieb:
Trotzdem ist md5 für Passwörter blöd. Weil MD5 ist zu schnell. Man will für Passwörter einen langsamen Hash Alogorithmus haben.
Aber solange gut gesalzen ist, ists sicher genug.
Zu 99% würde ich Dir zustimmen, sehe aber die Geschwindigkeit nicht als Nachteil.
Bei einem schnellen Algorithmus hat der Entwickler die Freiheit, einfach mal 829 Zyklen zu durchlaufen und kann trotzdem einen bewährten und auf allen Plattformen verfügbaren Algorithmus einsetzen.Wie sicher es sein muss, hängt im wesentlichen vom Angriffsszenario ab. Ein Angriff auf ein spezielles Kennwort (wie das eines Foren-Admins) ist wesentlich aufwendiger als das Ziel, irgendeines der vielen Konten zu hacken (um z.B. ein ebay-Konto zu kapern).
Das Salzen braucht dann gar nicht mal über individuelle Zufallszahlen laufen, ggf. reicht schon die Einbeziehung des Klartextes und/oder die Anzahl der Zyklen.Ciao, Allesquatsch
-
Salzen verhindert nur Angriffe über Rainbow-Tables, und macht das berechnen des Hashcodes minimal langsamer.
Gerade aber bei gezielten Angriffen auf ein einzelnes Passwort ist es wichtig dass der "Test" möglichst lange dauert.
Das Salz steht dir dabei ja zur Verfügung, bringt also nix bezüglich Sicherheit. Ausschlaggebend ist dann nur die Entropie des Passworts * Aufwand für 1x Probieren.
-
hustbaer schrieb:
Salzen verhindert nur Angriffe über Rainbow-Tables, und macht das berechnen des Hashcodes minimal langsamer.
Klares JEIN
JA, Salz ist das einfachste Mittel, um Angriffe auf entwendete Zugangsdaten über Rainbow-Tables abzuwehren.
NEIN, Salz ich jenseits der Rainbow-Tables hilfreich. Denn neben Rainbow-Tables sind Wörterbuchattacken ein erfolgreiches Rezept, um in geklauten Kennwort-Tabellen Treffer zu erzielen.
In schlechten Implementierungen wurde häufig nur das Kennwort als Klartext durch den MD5 gejagt. Und wegen des Hashs wird sowas auch nicht später geändert, um keine Benutzer zu verlieren.
Entsprechend sind die Hashes auch bei allen Benutzern gleich, die gleiche Kennworte haben.
Geht es also darum, die Identität eines von 100.000 Benutzern zu übernehmen, reicht ein Angriff für alle. Und was ohne Salz x Tage gedauert hätte, klappt jetzt in x Sekunden. Noch schneller wird es, wenn man aus den 100.000 Benutzern die vorauswählt, deren Kennworthash nicht kollisionsfrei ist.Ich gebe Dir aber Recht, dass das für echte Kryptologen keine wirklich höhere Sicherheit darstellt. In der Praxis gilt aber: Der Dieb wählt immer den leichtesten Weg - und der kann auch zum Nachbarn führen
Ciao, Allesquatsch
-
Allesquatsch schrieb:
Zu 99% würde ich Dir zustimmen, sehe aber die Geschwindigkeit nicht als Nachteil.
Bei einem schnellen Algorithmus hat der Entwickler die Freiheit, einfach mal 829 Zyklen zu durchlaufen und kann trotzdem einen bewährten und auf allen Plattformen verfügbaren Algorithmus einsetzen.Nope. Dann nimm einfach blowfish.
@hustbaer:
dass rainbow tables beim salzen nicht mehr gehen, nimmt man gerne mit.
Aber salzen verhindert, dass eine komplette DB geknackt werden kann. ein einzelner hash kann immer geknackt werden, egal welcher hash algo verwendet wird.Passwoerter sind einfach zu kurz fuer sowas.
-
Na ja. Bei den üblichen 10-14 Zeichen ist das schon ne Menge Arbeit oder nicht? Klar, schwache Passwörter mit 6 Zeichen knackt man quasi im Vorbeigehen.
-
cooky451 schrieb:
Na ja. Bei den üblichen 10-14 Zeichen ist das schon ne Menge Arbeit oder nicht? Klar, schwache Passwörter mit 6 Zeichen knackt man quasi im Vorbeigehen.
http://golubev.com/files/ighashgpu/readme.htm
Ein normaler PC den jeder bei sich zuhause haben kann, kann mehrer millionen hashes pro Sekunde berechnen. Und jetzt stell dir vor du hast eine Infrastruktur dafuer - zB ein Botnetz
-
cooky451 schrieb:
Na ja. Bei den üblichen 10-14 Zeichen ist das schon ne Menge Arbeit oder nicht? Klar, schwache Passwörter mit 6 Zeichen knackt man quasi im Vorbeigehen.
Leider dürfte das Übliche eher bei 6 als bei 10 liegen.
Mit meinem Standardkennwort für risikofreie Anwendungen bis ich auf 8 Zeichen geblieben, weil es viele Webangebote gibt, die mehr als 8 Zeichen oder Sonderzeichen ablehnen.
Auch dieses Jahr habe ich noch Webangebote gesehen, die das Kennwort im Klartext ablegen, denn es wird nachher per E-Mail verschickt.
Ciao, Allesquatsch
-
Shade Of Mine schrieb:
Ein normaler PC den jeder bei sich zuhause haben kann, kann mehrer millionen hashes pro Sekunde berechnen. Und jetzt stell dir vor du hast eine Infrastruktur dafuer - zB ein Botnetz
Unterschätze mal die Exponentialfunktion nicht.
Für 14 Zeichen haben selbst die Geheimdienste keine passende Hardware mehr. Schließlich beinhaltet Rainbow-Table einen Brute-Force.
Ciao, Allesquatsch
-
Allesquatsch schrieb:
weil es viele Webangebote gibt, die mehr als 8 Zeichen oder Sonderzeichen ablehnen.
Jo, das ist total plem.
War für mich vor 10 Jahren schon unverständlich, und ist es heute noch viel mehr. Man sollte meinen dass auch die doofen irgendwann mal dazulernen, aber dem ist wohl anscheinend nicht so.
-
Allesquatsch schrieb:
Für 14 Zeichen haben selbst die Geheimdienste keine passende Hardware mehr.
Unterschaetze die Hardware nicht. Du hast heute enorm viele Cores.
Eine ATI HD5870 kann etwa 1300000000 Hashes pro Sekunde Testen. Und das ist echt nicht mehr die neueste Hardware. Aber klar, ich brauche davon schon etliche Tausend Maschinen - mit Botnetz aber kaum ein Problem.Man kann die komplexitaet der Passwoerter auch noch reduzieren. Da zB Niemand aaaaaaaaaa als Passwort haben will. Da gibt es viele Tricks. zB keine Grossbuchstaben innerhalb des Passwortes, nur sehr wenige moegliche Sonderzeichen, keine zuoft wiederholenden gleichen Zeichen,... Und die erwartete Passwortlaenge ist 4-8.
Aber ein Passwort interessiert mich ja eh nicht, wenn dann will ich alle haben - und das geht eben nicht. Angriffe auf einen einzelnen wuerde man ja anders angehen.
-
hustbaer schrieb:
Nicht sehr schlimm ist, wenn der Angrif der die Kollisionen erzeugt A und B vollständig vorgibt. Also andersrum: keinerlei Einschränkungen bezüglich A und keinerlei Einschränkungen bezüglich B erlaubt. Man kann dann zwar hübsch massenweise Kollisionen erzeugen, aber man kann mit den Paaren (A,
die dabei rauskommen in den meisten Fällen nix anfangen.Oh, es gibt einen neuen Angriff auf Webserver, der sich genau auf solche Paare stützt. Und zwar nutzt der aus, dass das Erzeugen einer hashmap mit n kollisionen O(n^2) Rechenaufwand hat. Und wie greift man damit an? Einfach www.bla.de?A=1&B=1&C=1&... und du lastest mit Sicherheit einen kompletten Kern für mehrere Minuten aus. Berechnet wurde, dass man so je nach Implementation mit ca 1GB Upstream >10000 Kerne auslasten kann. Der einfachste Schutz dagegen ist eine randomisierte Hashfunktion(d.h. beim Start des Programms werden zufällige Parameter festgelegt). Trotzdem ein mächtiger Angriff der heute noch viele server betreffen sollte.
-
Shade Of Mine schrieb:
Unterschaetze die Hardware nicht. Du hast heute enorm viele Cores.
Ja, das ist wirklich noch mal ein qualitativer Schritt gewesen.
Aber es ist eigentlich nur für Brute-Force-Angriffe tauglich und im Zusammenhang mit Botnetzen nur eine theoretische Übung, da nur sehr wenige Bots entsprechende Gaming-Boliden sind. Wer einen aktuellen Rechner >1000EUR besitzt, liegt eher außerhalb der typischen Opfergruppe.
Es ist aber anzunehmen, dass im Spionagebereich durchaus mal 1000 solcher Maschinen in einem Rechenzentrum zusammen kommen können.Shade Of Mine schrieb:
Man kann die komplexitaet der Passwoerter auch noch reduzieren. Da zB Niemand aaaaaaaaaa als Passwort haben will. Da gibt es viele Tricks. zB keine Grossbuchstaben innerhalb des Passwortes, nur sehr wenige moegliche Sonderzeichen, keine zuoft wiederholenden gleichen Zeichen,... Und die erwartete Passwortlaenge ist 4-8.
Aber ein Passwort interessiert mich ja eh nicht, wenn dann will ich alle haben - und das geht eben nicht. Angriffe auf einen einzelnen wuerde man ja anders angehen.
Für die Erstellung von Rainbow-Tables ist aber wesentlich mehr zu tun, als Hashes zu rechnen. Da müssen große Datenmengen geschrieben und verglichen werden. Und das können die GPUs nicht.
Das Wesentliche: Die Hürde Zeit verliert wg. GPU und Cloud an Bedeutung, aber der Gesamtaufwand (Speicherbedarf, Kosten) bleibt noch so hoch, dass man mit einem langen, komplexen Kennwort keine Angst haben sollte, auf diese Weise gehackt zu werden.
Mit einem Mio EUR Etat würde ich wahrscheinlich leichtere, billigere Wege finden, an die Information zu kommen.Ciao, Allesquatsch
-
Shade Of Mine schrieb:
Unterschaetze die Hardware nicht. Du hast heute enorm viele Cores.
Eine ATI HD5870 kann etwa 1300000000 Hashes pro Sekunde Testen.Nun ja. 14 ist wohl doch zu hart:
50^14 = 6.10351562 × 10^23 (Habe mal 50 statt 80 oder so genommen, um die aaaas etc. rauszunehmen.)
1 300 000 000 * 60 * 60 * 24 * 365 * 10 000 = 4.09968 × 10^2010k Spielerechner rechnen ein ganzes Jahr lang durch - und wir sind immernoch ganze Größenordnungen entfernt. Aber in ein paar Jahren funktioniert's vielleicht.
