Frage:
Gibt es einen Vorteil beim Teilen eines Passworts?
Bill the Lizard
2011-04-04 23:06:10 UTC
view on stackexchange narkive permalink

Ich habe über den LANMAN (LM) -Hash gelesen und bin neugierig auf einen bestimmten Teil des Algorithmus.

Der LM-Hash wird wie folgt berechnet:

  1. Das ASCII-Passwort des Benutzers wird in Großbuchstaben konvertiert.
  2. Dieses Passwort wird auf 14 Byte null aufgefüllt.
  3. Das 14-Byte-Passwort wird aufgeteilt in zwei 7-Byte-Hälften.
  4. Mit diesen Werten werden zwei DES-Schlüssel erstellt, einer aus jeder 7-Byte-Hälfte.
  5. Jeder der beiden Schlüssel wird zum DES-Verschlüsseln verwendet Die konstante ASCII-Zeichenfolge "KGS! @ # $%" führt zu zwei 8-Byte-Chiffretextwerten.
  6. Diese beiden Chiffretextwerte werden zu einer 16 verkettet -Byte-Wert, der der LM-Hash ist.
  7. ol>

    Es gibt viele Sicherheitslücken, die im verlinkten Wikipedia-Artikel beschrieben und an anderer Stelle besprochen wurden, aber ich bin besonders an den Schritten 3 bis 6 interessiert Ich bin gespannt, was zu diesem Design geführt hat. Gibt es einen echten Sicherheitsvorteil, wenn Sie ein Passwort aufteilen, die beiden Hälften getrennt verschlüsseln und dann die beiden Hälften wieder zu einem Hash kombinieren? Oder ist dies nur ein Beispiel für "Sicherheit durch Dunkelheit" ?

Drei antworten:
#1
+54
Thomas Pornin
2011-04-05 00:04:14 UTC
view on stackexchange narkive permalink

Das Aufteilen des Passworts ist eine Schwäche , kein Vorteil . Es ermöglicht, jedes Passwort zur Hälfte unabhängig zu brechen. Beginnend mit ASCII-Zeichen (Codes von 32 bis einschließlich 126) und anschließendem Entfernen der Kleinbuchstaben erhalten Sie 127-32-26 = 69 mögliche Zeichen im Kennwortalphabet. Dies führt zu 69 7 sup> möglichen Hälften, die etwas unter 2 43 sup> liegen. Mit anderen Worten, dies ist durch rohe Gewalt sehr gut nachvollziehbar. Sie benötigen nicht einmal ein Wörterbuch.

Dies ist keine Sicherheit durch Dunkelheit. Dies ist Unsicherheit durch Inkompetenz.

Bearbeiten: "Mit brutaler Gewalt hochgradig handhabbar" eröffnet auch den Weg für verschiedene Optimierungen. Beachten Sie, dass LanMan nicht gesalzen ist. Daher können vorberechnete Tabellen effizient sein (Sie zahlen die Kosten für die Tabellenerstellung einmal , dann greifen Sie mehrere Halbkennwörter an - es lohnt sich tatsächlich Dies gilt auch für ein einzelnes Kennwort, da ein Kennwort zwei Halbkennwörter ist. Im Jahr 2003 veröffentlichte Philippe Oechslin einen verbesserten Zeit-Speicher-Kompromiss (in diesem Artikel prägte er den Begriff "Regenbogentabelle") und berechnete Tabellen zum Knacken von LanMan-Passwörtern. Er beschränkte sich auf alphanumerische Passwörter (Buchstaben und Ziffern, aber keine besonderen Zeichen), also ein Leerzeichen von 2 / sup> . Die kumulative Größe der Tabellen würde dann 1,4 GB bei einer Cracking-Effizienz von 99,9% und einer Angriffszeit von weniger als einer Minute betragen.

Mit einem 2 43 sup> -Raum, dh 64-mal größer, steigen sowohl die Tabellengröße als auch die Angriffszeit um den Faktor 16 (das ist 64 2 / 3 sup> ), es handelt sich also um 23 GB (das ist für heutige Festplatten nicht viel) und einen 15-minütigen Angriff. Tatsächlich wäre der Angriff schneller als dieser, da der Engpass darin besteht, auf der Festplatte nachzuschlagen, und der intelligente Angreifer eine SSD verwendet, die 50-mal schneller nachschlagen kann als eine mechanische Festplatte (eine 32-GB-SSD kostet weniger als 70 $ ...). Der Aufwand für die Tabellenerstellung (eine einmalige Ausgabe) kann auf einem einzelnen PC einige Wochen oder auf einer anständigen Cloud einige Tage dauern, daher ist er ziemlich billig.

Anscheinend, solche Tabellen existieren bereits ...

Ich wundere mich auch über die Geschichte. IIRC, die ursprüngliche Unix-Krypta, hat 8 Zeichen verwendet, weil sie etwas verwendet haben, das direkt mit DES zusammenhängt, ohne eine Schlüsselableitungsfunktion. Wahrscheinlich ähnlich mit LANMAN, trotz Aktualisierungen in Theorie und Praxis, bevor sie es entworfen haben.
Ich möchte ein Update für Anfang 2014 hinzufügen: A) Die 23-GB-Nachschlagetabelle passt sogar in RAM auf modernen Desktop-Computern, und B) jetzt kann ein einzelner PC mit 8 AMD R290X-GPUs auf Lager eine umfassende Brute-Force- / Markov-Suche durchführen / Erstellen Sie mit [oclHashcat] (http://hashcat.net/oclhashcat/) in nur 13,65 Minuten eine Nachschlagetabelle des gesamten 2 ^ 43 LM-Schlüsselraums. Mathe: 2 ^ 43 mögliche Passwörter / 10,74 Milliarden Versuche / Sekunde = 819 Sekunden. 819/60 = 13,65 Minuten.
#2
+38
D.W.
2011-04-05 10:37:13 UTC
view on stackexchange narkive permalink

Das Aufteilen des Passworts in Hashes ist kein Vorteil. Dies wurde aus unbekannten Gründen durchgeführt, die heute nicht mehr relevant sind.

Der Grund, warum der LanMan-Hash auf diese Weise funktioniert, liegt darin, dass der LanMan-Hash auf DES basiert. DES akzeptiert einen 56-Bit-Schlüssel. Daher ist es natürlich, einen Block von 7 Bytes als einen DES-Schlüssel zu behandeln. Es gibt keine gute Möglichkeit, DES zu verwenden, um mehr als 7 Bytes gleichzeitig zu hashen, und wir brauchen eine Möglichkeit, aus DES einen Hash für längere Passwörter zu erstellen. Daher haben die Designer des LanMan-Hash beschlossen, das Passwort in zwei Hälften aufzuteilen / p>

Heute würden wir niemals einen Passwort-Hash auf diese Weise erstellen. Wir würden nur Bcrypt, Scrypt, PBKDF2 oder ein gleichwertiges Produkt verwenden - oder wir würden etwas Ähnliches basierend auf vorhandenen Grundelementen wie SHA256 erstellen. Zu dieser Zeit gab es Bcrypt, Scrypt, SHA256 usw. noch nicht, was den LanMan-Designern die Möglichkeit eröffnete, diese Art von verheerendem Fehler zu machen.

Nach modernen Maßstäben ist der LanMan-Hash ein mieses Design. Es gibt viele viele Angriffe darauf. Es ist sehr schwach. Niemand sollte heute den LanMan-Hash verwenden, wenn er dies möglicherweise vermeiden kann. (Wie andere bereits betont haben, ist seine Sicherheit selbst für die damaligen Verhältnisse mies. Ein fairer Punkt.)

Gute Antwort! Aber zu: "modernen Standards" ... nach welchen Standards wäre der LanMan-Hash kein mieses Design? Wann wurde es in den 80ern entwickelt? Sogar die Unix-Krypta (3) aus der Unix-Version 7 von 1979 hatte ein Salz und 25 Iterationen. http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/libc/gen/crypt.c Auch die Entropie durch Konvertierung in Großbuchstaben wurde nicht reduziert. Es scheint auch besser zu sein, das Passwort einfach abzuschneiden, als die zweite Hälfte unabhängig zu hashen, was sehr kurz und knackbar sein kann und wertvolle Hinweise auf die erste Hälfte gibt.
Ich würde argumentieren, dass es selbst zu der Zeit mies war. Nehmen wir zum Beispiel 3DES, das es schafft, einen 168-Bit-Schlüssel sicher in DES einzuschleusen, indem er mit aufeinanderfolgenden Schlüsseln neu codiert. Wenn LanMan die zweite Schlüsselhälfte verwendet hätte, um das Ergebnis der ersten Runde zu codieren (ohne das Zwischenergebnis auszugeben), wäre es nicht annähernd so katastrophal gewesen wie jetzt.
Beachten Sie, dass wir heute mit "SHA256 oder einem Äquivalent" niemals einen einzigen Durchgang eines Hashing-Algorithmus durchführen würden. Stattdessen würden wir BCrypt, SCrypt oder PBKDF2 (möglicherweise PBKDF2-HMAC-SHA-256) mit einem zufälligen Salz und einem ausreichend hohen Arbeitsfaktor oder einer ausreichend hohen Iterationszahl verwenden.
Danke, @Anti-weakpasswords! Guter Punkt. Ich habe meine Antwort entsprechend überarbeitet. Ich freue mich über das Feedback.
@D.W. Kein Problem; das ist was ich tue und danke, dass du deine Antwort überarbeitet hast! Ich kann sogar ein anderes Level geben: "oder etwas Ähnliches basierend auf vorhandenen Grundelementen bauen" AUCH läuft auf "Siehe den [Passwort-Hashing-Wettbewerb] (https://password-hashing.net/)" :). Habe eine positive Bewertung!
Genauer gesagt: "Wir würden etwas Ähnliches basierend auf vorhandenen Grundelementen erstellen" ist "wir" als Sicherheitsgemeinschaft - es sei denn, Sie verfügen über ein solides Verständnis der Kryptografie * und * unterziehen Ihr Design einer Peer-Review durch andere seriöse Kryptographen, bevor Sie es verwenden. Sie sollten nicht Ihre eigenen rollen (so verwandelte LANMAN ein anständiges Primitiv in einen schrecklich unsicheren Hash).
#3
+3
MasterZ
2011-04-05 04:22:36 UTC
view on stackexchange narkive permalink

Nur weil etwas komplexer ist, ist es nicht unbedingt sicherer. Ich habe einen Passwort-Cracker auf meiner Windows-Box ausgeführt und er schien die Passwörter in 8 Zeichenfolgen aufzuteilen. Dabei wurde jede Zeichenfolge unabhängig von der anderen Zeichenfolge unterbrochen, sodass der Vorgang extrem schnell ablief.

Also von a Der praktische Standpunkt, ein Passwort zu teilen, ist nicht vorteilhaft, und @Thomas hat bereits erläutert, warum es mathematisch nicht vorteilhaft ist.

Windows Vista und höher tun dies nicht.


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 2.0-Lizenz, unter der er vertrieben wird.
Loading...