Was bringt eigentlich hash cracking?

[Zeboo]

Hätte gehört, dass gehashte Passwörter keine Wunderwaffen gegen Hacker sind. Die sind immerhin besser als Klartextpasswörter aber sind keine perfekte Lösung.

Naja wie auch immer. Man ließt hier und da, dass Skriptkiddies neue Hobbies haben: Hashes cracken.
Dabei werden zwei Listen oder eine Liste mit einem Hash verglichen. Die eine Liste beinhaltet Klartext (die vermutlich Passwörter sind) und die andere den Hash, das man eigentlich "cracken" möchte. Jetzt wird Klartext verhasht und verglichen. Wenn es ein Match gibt, hat man eigentlich das Passwort "gecrackt". Das ist sicherlich ein netter Zeitvertreib ABER was bringt das jetzt gegen einem Enduser?

Nehmen wir an man möchte hier auf CB mein Passwort "cracken" -> Man hat seine Liste mit Klartext und ... ja oh, man braucht noch irgend nen Gegenhash. Da kommt man aber eh nicht ran (außer man hackt erst mal die CB Datenbank, aber dann hat man ganz andere Probleme). Also heißt das: man braucht hier im Fall überhaupt keine Angst zu haben, Hacker könnten da nichts machen? Oder wie muss man das verstehen?

Es wäre sogar egal ob ich einen einfachen und schweren Passwort habe, bezüglich des hash crackings, denn wie eben gesagt: man hat ja nicht mal einen Hash das man cracken könnte. Hätte man eins, das auch sehr oft verwendet wird -> pech für mich, wäre leicht zu knacken. Hat man ja aber nicht. Deswegen verstehe ich den Sinn nicht so ganz.

 

[iDont_Know]

meinst du dem MD5password ( den du mit Wireshark siehst ? )

 

[Zeboo]

meinst du dem MD5password ( den du mit Wireshark siehst ? )

Ja MD5. Sieht man das so per Wireshark? Und wenn schon, das sehe nur ich in meinem Netz. Noch weniger kriege ich das bei Usern raus, von denen ich nur einen Benutzernamen habe und sonst nichts weiß. Also kann ich wiegesagt als Passwort "hallo" haben, durch hash cracking kann da eh niemand was machen.

 

[Mumpitzelchen]

Keine Angst ist relativ. Es gibt da so einen Milliardenkonzern, weltweit aktiv, tausende Mitarbeiter. Die haben auch eine Nutzerdatenbank gehabt, sogar mit Kreditkartendaten damit Kunden Spiele für ihre Konsole kaufen konnten.
Die Datenbank wurde von ein paar Scriptkiddies gestohlen und oops.... Passwörter und vor allem Kreditkarten: pooof!

Oder dein WLAN, das wird auch durch einen Hash gesichert. Hashes zu cracken hat viele Arten von Nutzen für den Angreifer.

 

[fRaNkLiN]

Normalerweise läuft das beim Passwort-Knacken anders ab. Einen Hash hast du, das stimmt. Meistens ist der Hash aber nicht md5(Passwort), sondern md5(Salt + Passwort). "Salt" ist eine weitere Zeichenkette, die mit dem Passwort an sich nichts zu tun hat. Das heißt, dass du zum Knacken eines gesalteten und gehashten Passworts auch den Salt kennen solltest, wenn du ihn nicht raten willst. Das könnte unangenehm werden, denn Salts sind in der Regel zufallsgeneriert und bestehen aus wilden Zeichenfolgen.

Sollte "dir" als unterstelltem Script-Kiddie auch noch die Tabelle mit den Salts in die Finger gekommen sein, dann herzlichen Glückwunsch. In User-Datenbanken gibt es normalerweise (hoffentlich) für jeden Nutzer einen eigenen Salt. Das bezweckt, dass für jeden User eine eigene Vergleichstabelle mit gesalteten, gehashten Passwortkandidaten angelegt werden muss. Die nennt man Rainbow Tables und wiegen im Normalfall zwischen 4 und 10GB. In sehr großen Datenbanken bewirkt das also eine Unmenge an "Datenmüll", sprich, der Angreifer braucht extrem lang und sehr viel Speicher, um die Passwörter zu entschlüsseln. Nehmen wir mal 10.000 User an und rechnen mit 5GB pro User, sind allein die Rainbow Tables schon Stoff für 50TB. Der pro User einzigartige Salt erschwert bzw. verlangsamt also das Brute-Forcen der Passwörter extrem.

Wie du siehst, ist das Knacken von Hashes also kein Zeitvertreib für Kinder. Moderne GPUs rechnen (in diesem Fall: leider) abartig schnell verschiedene Zeichenkombinationen und -längen durch. Ist die Rainbow Table berechnet, fehlt nur noch eine Abfrage, und das Passwort ist bekannt. Es liegt also im Interesse der Betreiber der Datenbanken, diese möglichst unkompromittierbar zu gestalten: Firewalls, VPN-Zugriffe, gesicherte APIs, ablaufende Token, sichere Admin-Passwörter... sollten all diese Sicherheitsmaßnahmen umgangen worden sein oder fehlen, braucht es eigentlich nur noch Zeit und Rechenleistung (die die meisten Script-Kiddies wohl kaum ihr Eigen nennen werden).

Noch zu der Frage, was das dem "Crackenden" bringt: Oft sind in großen Netzwerken - siehe PSN - Kredikartendaten im Profil des Nutzers hinterlegt. Kennt man das Passwort, kann man sich oft die Daten ansehen, normalerweise, damit sie der Nutzer ändern kann.

 

[Daaron]

Der Sony/PSN-Hack war doch eh nur der prominenteste Fall, einer von Hunderten. Ein weiterer prominenter Kunde der letzten 2-3 Jahre war Mr. Spex (die hatten gleich gar nicht gehasht), Gamigo waren schon fällig, Twitter war glaub ich letztens dran,...

So... und was bringt es, über Hashcracking das Passwort eines Users für eine Seite herauszufinden, wenn man bereits über einen erfolgreichen Angriff eh Kontrolle über die Datenbank hat? Tja, Psychologie! Die meisten User sind dumm und faul. Sie benutzen dasselbe Passwort für mehrere Dienste.
Also selbst wenn PayPal deine Passwörter wie Fort Knox gegen solche Angriffe schützt... wenn du dieselbe Kombination aus Mail+PW wie bei Gamigo verwendet hast, dann haben die Angreifer jetzt Zugang zu deinem PayPal-Konto und somit ist Polen offen (außer du hast SMS-TAN aktiv).

Wenn also Hash Cracking jetzt so problematisch ist, was kann man als User tun?
Als USER sollte man:
- nie dieselbe Kombo aus Username/Mailadresse und PW 2x verwenden
- nur SICHERE Passwörter verwenden. Je länger und komplizierter die Passwörter, desto größer wird die Rainbow Table. Für 8 Stellen nur mit kleinen Buchstaben und evtl. Zahlen brauchste meinetwegen ne 10GB große RT. Wenn du jetzt 10 Stellen mit Groß- & Kleinschreibung, Zahlen und Sonderzeichen nimmst explodiert die RT auf meinetwegen 100GB. Noch 2 Stellen mehr und der Angreifer braucht ne neue Festplatte pro RT.

Was kann der Entwickler tun?
Oh... verdammt viel. Er kann endlich mal sein Hirn anwerfen....
Wenn keine anständigen Crypto-Befehle zur Verfügung stehen hilft es schon, den Hash-Befehl 1.000 oder 10.000x laufen zu lassen. Für den Server ist das ein Witz, der regulärer User muss dann vielleicht 10ms länger warten beim Login. Für einen Angreifer steigt der Rechenaufwand aber ebenfalls aufs 1.000- oder 10.000-fache.... und das ist nur die schwächere Schutz-Variante.
Moderne Umgebungen bieten feine Crypto-Systeme. Das Problem an Hash-Algorithmen wie md5 oder SHA1 ist, dass sie entworfen wurden um SCHNELL zu sein. Sie sollen primär zügig einen Vergleichswert zu etwas erstellen, z.B. als Prüfsumme über eine gerade heruntergeladene Datei oder gebrannte CD. Es gibt starke Crypto-Befehle, die auf SICHERHEIT pochen, dafür eben auch gezielt langsam sind. Für PHP gibts dafür z.B. password_hash();

 

[Smagjus]

Sollte "dir" als unterstelltem Script-Kiddie auch noch die Tabelle mit den Salts in die Finger gekommen sein, dann herzlichen Glückwunsch. In User-Datenbanken gibt es normalerweise (hoffentlich) für jeden Nutzer einen eigenen Salt. Das bezweckt, dass für jeden User eine eigene Vergleichstabelle mit gesalteten, gehashten Passwortkandidaten angelegt werden muss. Die nennt man Rainbow Tables und wiegen im Normalfall zwischen 4 und 10GB.

Das was du hier beschreibst (ob es der Kürze deines Postings oder Unwissenheit geschuldet ist, lassen wir mal außer Frage) ist aber noch lange keine Rainbow Table.

Meistens ist der Hash aber nicht md5(Passwort), sondern md5(Salt + Passwort).

Das wäre eine schöne Welt. Der TÜV stellt dir auch ein Datensicherheitszertifikat aus, wenn du Passwörter im Klartext speicherst. Außerdem gilt bei Passwörtern selbst in Unternehmen häufig die Devise: Hauptsache leicht zu merken. Da wird dann auch gerne auf 2-zeichenlange Passwörter zurückgegriffen, die identisch zum Nutzernamen sind.

 

[Mumpitzelchen]

Sollte "dir" als unterstelltem Script-Kiddie auch noch die Tabelle mit den Salts in die Finger gekommen sein, dann herzlichen Glückwunsch. In User-Datenbanken gibt es normalerweise (hoffentlich) für jeden Nutzer einen eigenen Salt. Das bezweckt, dass für jeden User eine eigene Vergleichstabelle mit gesalteten, gehashten Passwortkandidaten angelegt werden muss. Die nennt man Rainbow Tables und wiegen im Normalfall zwischen 4 und 10GB. In sehr großen Datenbanken bewirkt das also eine Unmenge an "Datenmüll", sprich, der Angreifer braucht extrem lang und sehr viel Speicher, um die Passwörter zu entschlüsseln.

Kein Mensch nutzt mehr RainbowTables, eben wegen dem Salt und weil GPUs die Hashes einfach direkt berechnen: ist schneller und braucht weniger Speicherplatz. 10GB Rainbowtables war mal

 

[iDont_Know]

ist dieser Salt immer an der gleicher Stelle ??

 

[Krik]

Das hängt vor der Implementierung ab. Ich habe schon Passwort+Salt (PHP-Seiten) und Salt+Passwort (Unix) gesehen.
Es ist aber egal, wo der Salt steht. Alleine durch sein Vorhandensein und seiner Zufälligkeit erhöht er den Crack-Aufwand immens.

Oder hast du etwas anderes gemeint?

 

[Daaron]

Und dann gibts ja auch noch die wirklich solide Herangehensweise: Salt & Pepper.

 

[ice-breaker]

Oder es gibt gleich die absolut solide herangehensweise: Algorithmen zum Hashen der Passwörter, die dafür gedacht sind viel Zeit zu verbrauchen und nicht wie die md- oder sha-Familie auf Geschwindigkeit ausgelegt sind.
Bcrypt oder PBKDF2 würden darunter fallen. Selbst wenn du da den Hash erbeutest hast du noch eine ganze Zeit zu rechnen, nen bcrypt hash mit cost factor 10 braucht auf einem Kern einer CPU ca 90ms, das ist 70.000 mal soviel wie sha1. Praktikable GPGPU-Lösungen gibt es da aktuell gar nicht.

 

[Lunke]

Da kommt man aber eh nicht ran (außer man hackt erst mal die CB Datenbank, aber dann hat man ganz andere Probleme).

Doch, genau so kommt man an den Hash. Du hast zwar recht, dass man dann im Prinzip eh schon Zugriff auf die Konten hat und daher das Passwort gar nicht mehr benötigt, ABER man kann mit dem Passwort trotzdem noch mehr anfangen, als du dir vorstellst. Z.B. haben viele Leute die gleichen Passwörter auf mehreren Seiten verwendet. Wenn man also an das Passwort kommt, das UserXY bei CB nutzt, dann kann man das Passwort ja mal bei allen gängigen Internetdiensten durchprobieren (Mail, Facebook, ...).

 

[Krik]

Jepp. Angenommen Cracker kommen an die User-Datenbank von CB. Dann haben sie Hashes und eMail-Adressen aller User. Wenn man die Passwörter errechnet, dann kommen sie in den Mail-Account. Haben sie erst mal den Mail-Account, sehen sie zufällig eine Mail von PayPal (odder ähnlichem) und könnten so an dein Geld kommen. Natürlich nur, wenn überall dasselbe Passwort verwendet wird.

Und das wird gerne gemacht. Ich schätze, mindestens 95% aller User haben maximal drei verschiedene Passwörter, die sie bei verschiedenen Internetseiten und Diensten verwenden.

 

[Masamune2]

Noch zu erwähnen in dieser Diskussion wäre der Umstand dass MD5 oder auch SHA nicht mehr unbedingt prädestiniert sind um damit Passwörter zu sichern da sie wie schon geschrieben vor allem mit Hilfe von Grakas oder Amazons Cloud zu schnell durchgetestet werden können.
Um dem Abhilfe zu schaffen wurden neue Verfahren entwickelt die rechnerisch aufwendiger sind und so selbst mit spezieller Hardware nicht mehr Millionen von Kombinationen pro Sekunde getestet werden können.

Als Hintergrund bitte unbedingt mal den Artikel auf heise lesen: http://www.heise.de/security/artikel/Passwoerter-unknackbar-speichern-1253931.html Da ist eigentlich alles sehr einfach erklärt.

 

[Alrik]

Es wäre sogar egal ob ich einen einfachen und schweren Passwort habe, bezüglich des hash crackings, denn wie eben gesagt: man hat ja nicht mal einen Hash das man cracken könnte. Hätte man eins, das auch sehr oft verwendet wird -> pech für mich, wäre leicht zu knacken. Hat man ja aber nicht. Deswegen verstehe ich den Sinn nicht so ganz.

Du hast es richtig verstanden, so lange niemand den Zugang zum Server von z.B. CB "hacked" und die "gehashten" Daten aus der Datenbank ausliest, kann dir gar nichts passieren und deine Daten sind sicher. Deshalb sind ja auch leider immer noch bei einigen Anbietern die Passwörter "ungehashed" also im Klartext in einer Datenbank abgelegt. Leider hat sich in der Vergangenheit herausgestellt, das der Zugang zu diesen Datenbanken leider teilweise relativ einfach ist. Wie oben schone einige erwähnt haben. Stichwort "SQL-Injection".

 

[Daaron]

Ein auf Sicherheit bedachter Entwickler geht immer erst einmal davon aus, dass sein System geknackt WIRD, und er es danach den Eindringlingen so schwer wie möglich machen muss.
Leider sind überraschend viele Entwickler in ihren Kenntnissen irgendwo auf Stand Ende der 90er hängen geblieben, als md5() noch unknackbar war.

 

[QXARE]

GPUs die Hashes einfach direkt berechnen

Wie darf ich das "berechnen" genau verstehen? Anstatt des RainbowTables-Vergleich fängt man bspw. mit einem Zeichen an und endet dann mit einer gewissen Länge und dazwischen werden quasi alle Hashes "berechnet"?

 

[Daaron]

Rainbow Tables werden schnell einige GB groß. Eine RT für SHA1 mit 12-14 Stellen, Groß+Kleinschreibung, Zahlen, Sonderzeichen belegt dann eben gern mal eine halbe Festplatte.

Dank GPU-Cracking ist es eben effektiver, einfach jeden Hash neu zu berechnen. Du fängst bei "a" an und lässt laufen. Irgendwann ist der Hash deiner "Eingabe" identisch zum gesuchten Hash -> du kennst das Klartext-Passwort bzw. das Passwort + den Salt.

Es kommt aber auf die Aufgabenstellung an. Will ich die Passwort-Hashes einer kleinen Datenbank, z.B. dem CRM eines kleinen Unternehmens, cracken? Dann bearbeite ich jeden Hash einzeln. Habe ich einige tausend Daten, so wie beim Sony-Hack? Dann gehe ich ERST mit Rainbow Tables drüber und guck dann den Rest an.

 

[QXARE]

Danke, war erst etwas verwirrt, aber habe ich mir so gedacht!

777 :>