sha512hash

[lordg2009]

Hallo miteinander

Ich habe mich in letzter Zeit viel mit Passwort-Sicherheit beschäftigt. Während ich mein win-pw relativ schnell geknackt habe, komme ich bei Linux nicht weiter, obwohl es das selbe pw ist. So, wie ich es verstanden habe, speichert Linux das Passwort in der shadow Datei, aber nicht als hash-string, sondern als sorted non hast-string. Mein Linux nutzt sha512 und ich würde gerne wissen, wie ich diesen string converten kann, damit ich ihn per bruteforce testen kann.

Vielen Dank

 

[Thermi]

Das kann man normalerweise mit dem Tool "john", welcher ein Passwortknacker für Unix/Linux-Systeme ist. In der Community-Edition kann er weitaus mehr Hashes bruteforcen, als in der standardedition. Du musst dem Tool nur zeigen, wo die passwd- und shadow-Dateien liegen. Ich weiß allerdings nicht, ob es bereits sha512 beherrscht.

 

[Mumpitzelchen]

In

man shadow
man 3 crypt

steht alles was du wissen musst. Mit johntheripper und (ocl)hashcat gibts auch Programme die tun was du willst.

 

[xone92]

ein sha512-Hash mit brute-force zu bearbeiten (speziell mit salt, ist normalerweise überall so) bringt nicht wirklich Punkte ... wenn das Passowort lang genug ist dauert es Jahrmillionen.

 

[andy_0]

Die Windows Passwörter sind eigentlich auch ausreichend sicher gegen Brute Force Angriffe. Wirklich erfolgsversprechend sind bei Angriffen auf Hash nur Rainbow Table (http://project-rainbowcrack.com/table.htm).

 

[lordg2009]

mit hashcat setze ich mich gerade auseinander. Habe mir die Optionen alle angeschaut. Hab die entsprechende nicht gefunden.

Würde gerne mit diesem Programm weiterarbeiten, wenn mir da jemand einen Tip geben kann? Es gibt zumindest die Option irgendwie mit salted Dateien zu arbeiten.

Mit Rainbow-tables habe ich mich schon mal beschäftig. Aber da sollen ja salted hashes Verbesserungen erziehlen. Ich versuche gerade mittels GPU Passwörter zu knacken. Hab mein Windows Passwort auf beide Arten geknackt und per cuda lief es 150 mal schneller (8Mil/s vs 1300M/s)

 

[andy_0]

Ein Salt beugt natürlich gegen generische Rainbow Tables vor. Da muss man natürlich speziell für das jeweilige Salt (z.B. OS wie Windows XP, Windows 7, ...) extra Rainbow Tables erzeugen.

Selbst 1300*10^6 Keys/s sind für ein 128Bit Hash nicht schnell genug. Um alle Keys zu berechnen würdest du noch immer 8,3*10^21 Jahre benötigen. Ein 128Bit Hash ist außerdem eher winzig.

 

[xone92]

Ein Salt beugt natürlich gegen generische Rainbow Tables vor. Da muss man natürlich speziell für das jeweilige Salt (z.B. OS wie Windows XP, Windows 7, ...) extra Rainbow Tables erzeugen.

Selbst 1300*10^6 Keys/s sind für ein 128Bit Hash nicht schnell genug. Um alle Keys zu berechnen würdest du noch immer 8,3*10^21 Jahre benötigen. Ein 128Bit Hash ist außerdem eher winzig.

Mein Reden mit Salt ist ein gutes Gegenmittel gegen Rainbow-Tables verfügbar. Man kann sicherlich per brute-force angreifen ... es dauert halt nur "etwas" länger.

 

[lordg2009]

Ich würde es halt wirklich gerne ausprobieren, und zwar mit einem CUDA unterstützendem Programm und Brute-Force. Kennt da jemand ein HowTo?

Ergänzung (10. Juli 2012)

Hab jetzt John ausprobiert (unter Linux).
Man muss ja zuerst ein unshadow durchführen, wo die passwd und shadow datei kombiniert werden, so dass john sie verarbeiten kann. Ich habe mir die Ausgabe angeschaut und der hash für das Passwort ist noch immer der gleiche. John kann aber irgendwie direkt damit arbeiten. Mich würde jetzt ineteressieren, was john mit diesem non-hex-string macht und ob ich diesen auch benutzen kann, um ihn mit hashcat zu verarbeiten.

 

[lordg2009]

@ xeno92

Brute - Force dauert natürlich länger, als rainbow tables, aber durch den salt wird zeit, die brute-force benötigt ja nicht verlängert, aber ich denke das meintest du auch.

Ich hab mir den salt vom sha512-crypt angeschaut: 13 base64 Zeichen, also 64^13 Möglichkeiten für den Salt selbst. Damit ist, so denke ich, dieser Algorithmus im Prinzip immun gegen rainbow-tables.

 

[xone92]

Rainbow Tables sind vorberechnete Antworten zu Fragen (vereinfacht gesagt). Du kannst also mit einer Rainbow Table zu einer passenden Antwort die Frage finden (man muß nur suchen und nicht rechnen). Wäre z.B. bei Primfaktorenzerlegung dadurch wesentlich schneller.

Du brauchst also 64^13 Rainbow Tabellen - für jede Möglichkeite des SALTs eine andere Tabelle. Deswegen wird die Nutzung von Rainbow-Tables so unmöglich. Ein SALT muß deshalb auch zufällig sein. Nicht das du zufälligerweise die Tabelle schon vorberechnet hast.

Brute force ist da natürlich außen vor. Aber Brute Force dauert eben ewig lang.

 

[andy_0]

Aber man kann eben Rainbow Tables für jedes System berechnen, wo das gleiche Salt verwendet wird. Es ist, so wie ich das sehe, nicht praktibal z.B. jede Installation von Windows mit einem extra Salt zu versehen. Dadurch bekommt man Probleme mit der Integration in eine bestehende Infrastruktur (z.B. Domain).

Man kann also durchaus eine Rainbow Table für ein weit verbreitetes System errechnen.

 

[lordg2009]

Windows nutzt doch NTLM ohne salts und außerdem werden doch z.B. bei Linux die salts jedes mal zufällig neu generiert.