Hashes
-
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.
-
Allesquatsch schrieb:
Es ist aber anzunehmen, dass im Spionagebereich durchaus mal 1000 solcher Maschinen in einem Rechenzentrum zusammen kommen können.
Oki, streichen wir drei Stellen.
Allesquatsch schrieb:
Das Wesentliche: Die Hürde Zeit verliert wg. GPU und Cloud an Bedeutung,
GPU noch drei Stellen?
Und Cloud vier?Bitte nochmal den Schulabschluß machen.
-
cooky451 schrieb:
Nun ja. 14 ist wohl doch zu hart:
Heute: wahrscheinlich.
Vor 2 Jahren hätte ich gesagt: 14 ist unknackbar.In 2 Jahren sagen wir wahrscheinlich: 14? das soll sicher sein? lololz.
Die Performancedaten sind übrigens aus 2009 für handelsübliche Hardware.
-
Shade Of Mine schrieb:
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.
Man nimmt einfach ein spezielles Verfahren. Das muss kein eigener Hash-Algo sein. Unter Linux wurde früher zB MD5 und mittlerweile SHA2. Dabei wird der Hash-Algo einfach mehrfach aufgerufen. https://en.wikipedia.org/wiki/Crypt_(Unix)#MD5-based_scheme
Ansonsten gibt es noch bcrypt und scrypt
Achso und in Anwendungen bitte immer ein etabliertes Verfahren (bcrypt, glibcs sha2 crypt, scrypt, etc.) verwenden und niemals nie was eigenes entwerfen. Wer md5(pwd+salt) als Passwortverfahren nimmt, ist einfach ein Trottel.
-
volkard schrieb:
Bitte nochmal den Schulabschluß machen.
Hallo Volkard,
freche Bemerkungen machen mir nichts.
Aber ich finde es bedauerlich, dass mir der Sinn Deiner inhaltlichen Bemerkungen verborgen geblieben ist.Leider fehlt vielen Leute, auch solchen die lange mit IT und Mathe zu tun hatten, das Gespür, was die Exponentialfunktion ausmacht.
Erst neulich hatte ich mich über den Informatiklehrer meines Sohns amüsiert, der weissagte, dass auf 64bit Betriebssysteme dann 128bit Betriebssysteme folgen würden.Solltest Du also gemeint haben, dass technische Quantensprünge dem Verlust von drei oder vier Stellen entsprächen, ist das eine Fehleinschätzung. Wegen des größeren Exponenten wären das in Zehnerpotenzen doppelt so viele Stellen. Für drei Kennwortstellen mehr bedeuten also millionenfache Rechenleistung.
Mag sein, dass mein Schulabschluss schon etwas länger her ist, aber dafür war er bei mir nur kostenlos und nicht umsonst.
Ciao, Allesquatsch
-
Shade Of Mine schrieb:
Unterschaetze die Hardware nicht.
Hallo Shade Of Mine,
natürlich geht die Entwicklung voran und wer darauf nicht reagiert, wird weggefegt.
Allerdings sehe ich die Sache nicht gar so dramatisch, wie sie hier dargestellt wird. Man folgt da schnell Fehleinschätzungen und Trugschlüssen.
1. Die Entwicklung überrollt uns nicht, sondern verhält sich eigentlich recht berechenbar. Auch wenn die von Dir angegebenen Benchmarkwerte sich auf 4 Jahre alle Grafikprozessoren beziehen, sind die Leistungsdaten aktueller Karten keine Überraschung (Mooresche Gesetz). Ein aktueller High-End-PC aus der 5000 EUR-Klasse schafft mit zwei Top-Karten und 1200W Netzteil knapp 12 TerraFLOPS.
Bei großzügiger Abschätzung packt man 15 Mrd MD5-Hashs in der Sekunde oder 1,3 Billiarden (1,3e15) am Tag. Das ist immer noch sehr weit vom weg, was 12 oder
14 Zeichen einer deutschen Tastatur (1e24 oder 1e28) hergeben.
Für die vollständige Enumeration ist der Quotient immer noch bei rund 9 Zehnerpotenzen. Wollte man die Rechenzeit auf 3 Jahre begrenzen, würde man für diesen Zeitraum die Stromleistung aller deutschen Kernkraftwerke benötigen.
Ich denke, dass hier einige die Dimensionen von Cloud und Botnetzen verkennen.2. Den Trugschluss sehe ich darin, dass man verkennt, dass die Rechenleistung nicht nur der Angreifer mit dem Mooreschen Gesetz steigt. Du hast schon selbst erkannt, dass MD5 einfach zu schnell ist, um für sich noch sicher zu sein.
Aber wenn der Angreifer Milliarden Hashes in der Sekunden ermitteln kann, kann das der Betreiber auch. Wenn beim Verschlüsseln 1000 Zyklen kein Laufzeitproblem mehr sind, kann ich die Rechenzeit beim Angreifer immer um den gleichen Faktor verlängern.Ciao, Allesquatsch
-
Allesquatsch schrieb:
Wenn beim Verschlüsseln 1000 Zyklen kein Laufzeitproblem mehr sind, kann ich die Rechenzeit beim Angreifer immer um den gleichen Faktor verlängern.
Nope. Du kannst nicht konstant deine Software anpassen. Du bist festgelegt auf das was du damals gemacht hast.
Und du vergisst, dass es nicht ein Rechner ist der das knacken will sondern ein Botnetz aus mehreren tausend Rechnern. Oder eben eine Server Farm.
Und du bist jetzt schon bei 14 Zeichen. Welcher User hat 14 Zeichen im Passwort? Die meisten Services aktzeptieren 14 Zeichen ja nichtmal...
6-8 sind da eher die Passwoerter...
-
Also "die meisten Server" ist schon arg übertrieben. Die meisten Server akzeptieren sehrwohl Passwörter mit 12, 14 oder mehr Zeichen. Beschränkungen auf <= 8 sind mittlerweise schon sehr selten (wenn auch leider noch nicht ganz ausgestorben). Zumindest bei den Systemen die ich in den letzten Jahren verwendet habe.
Und wieso sollte man ein Programm modifizieren müssen?
Mehr als einen Eintrag in einem .ini File braucht das nicht.
Bzw. man könnte es sogar auto-tuning machen.
MinRounds=1000, MaxRounds=1000000, MaxCpuTime=100ms
Dann wird zu jedem Passwort zusätzlich zum Salt und Hash noch die Anzahl der Runden mit abgespeichert.Bei jeder Passwort-Änderung soll der Server dann so viel Runden machen wie sich ausgehen (min. jedoch die eingestellte Anzahl).
Wenn man es noch besser machen will, kann man irgendwo die durchschnittliche Rundenanzahl die bei den letzten N Passwörtern verwendet wurde abspeichern. Und sobald sich jmd. einloggt dessen Passwort-Hash weniger als N/10 Runden verwendet wird das Passwort an der Stelle neu gehasht (beim Login liegt es ja Klartext vor, kann also neu mit mehr Runden gehasht werden).
Ich sehe da kein Problem. Wenn ich was übersehen habe bitte korrigier mich.
-
Shade Of Mine schrieb:
Allesquatsch schrieb:
Wenn beim Verschlüsseln 1000 Zyklen kein Laufzeitproblem mehr sind, kann ich die Rechenzeit beim Angreifer immer um den gleichen Faktor verlängern.
Nope. Du kannst nicht konstant deine Software anpassen. Du bist festgelegt auf das was du damals gemacht hast.
Dummerweise bleibt Dir in sensiblen Bereichen gar nichts anderes übrig, als dann die Benutzer zu zwingen, nach der Anmeldung das Kennwort zu ändern, damit Du es dann mit einem härteren Algorithmus neu krypten kannst.
Shade Of Mine schrieb:
Und du vergisst, dass es nicht ein Rechner ist der das knacken will sondern ein Botnetz aus mehreren tausend Rechnern. Oder eben eine Server Farm.
Nein, nicht vergessen, sondern offen gelassen, ob Du jetzt die fehlenden 9 Zehnerpotenzen durch Anzahl Rechner oder durch Zeit überbrückst.
Habe stattdessen die Energiemenge als Veranschaulichung genutzt und dargestellt, dass die Energiemenge von allen deutschen Kernkraftwerken für 3 Jahre notwendig ist, um alle Hashes auszuprobieren.
Sicherlich wird die Leistungsfähigkeit weiter steigen, aber nur um zweistellige Prozente im Jahr und nicht um Faktoren. Zu meinen Lebzeiten wird es sicher billiger sein, mir zwei Jungs aus Weißrussland vorbei zu schicken, als das Kennwort durch Brute-Force herauszubekommen.Shade Of Mine schrieb:
Und du bist jetzt schon bei 14 Zeichen. Welcher User hat 14 Zeichen im Passwort? Die meisten Services aktzeptieren 14 Zeichen ja nichtmal...
6-8 sind da eher die Passwoerter...Mein Masterpassword für Keepass ist 19 Zeichen lang
In Keepass sind die per Zufall generierten Kennworte für meine dienstlichen Zugänge. Mein Kennwort für die Festplattenverschlüsselung und Windows hat 12 Stellen. Ich bin mir sicher: Die konkrete Implementierung in Anwendungen und Systemen ist leichter anzugreifen. Da gibt es genügend Systeme, in denen das Kennwort noch ungesalzen und vielleicht nicht mal gehasht rumliegt.Ciao, Allesquatsch
-
hustbaer schrieb:
Und wieso sollte man ein Programm modifizieren müssen?
Mehr als einen Eintrag in einem .ini File braucht das nicht.
Bzw. man könnte es sogar auto-tuning machen.
MinRounds=1000, MaxRounds=1000000, MaxCpuTime=100ms
Dann wird zu jedem Passwort zusätzlich zum Salt und Hash noch die Anzahl der Runden mit abgespeichert.Und wer macht das?
Theorie und Praxis sind nicht das selbe.
Die bessere Lösung wäre übrigens (wie schon von rüdiger genannt) bcrypt.
