Diskussion:Salt (Kryptologie)/Archiv

message: Ich habe im Rahmen meiner Änderung den Satz "Falls jemand in den Besitz des Wertes des Salzes und des gespeicherten Hashes kommt, so sind zwar Wörterbuchangriffe möglich, jedoch verdoppelt jedes Bit aus dem Wert des Salzes den benötigten Platz und die benötigte Zeit, um die Hashes einer Wörterbuchattacke zu berechnen." entfernt. Ich habe ihn nicht verstanden und vermute, daß der ursprüngliche Autor sich geirrt hat, denn der Absatz hat das eigentliche Thema nicht rübergebracht. Sollte ich mich geirrt haben, bitte den Satz wieder (evtl. umformuliert) hinzufügen. --AndreKR 02:47, 27. Jul 2006 (CEST)
replies: text: Recht hast du... habs verschoben. --AndreKR 04:51, 25. Feb. 2007 (CET)

text: Im Allgemeinen verwendet man ja den Artikel der deutschen Übersetzung, hier als das Salz. --FGodard ✉ Bewertung 19:17, 24. Jun. 2007 (CEST)
thread_title:  (nicht eingeordnete Diskussionsbeiträge 

message: Mir ist unklar, warum man im Einleitungssatz (oder überhaupt) mit Fremdwörtern kokettieren muss. Die Verständlichkeit für den Einsteiger schwindet dadurch deutlich und überflüssigerweise. Verknüpfen passt zudem deutlich besser als verketten, da keinesfalls nur eine einfache Aneinanderreihung (Verkettung) denkbar ist. -- 87.153.195.23 19:59, 3. Nov. 2009 (CET)
thread_title:  konkatenieren 

message: Der letzte Satz im Abschnitt "Motivation" erweckt den Eindruck, Rainbowtables seien einfach gehashte Wortlisten. Das wäre dann doch zu stark vereinfacht. Ich schlage vor, diesen Satz einfach wegzulassen. Der dritte Satz im Abschnitt "Anwendungen" sollte aus sprachlichen Gründen dann so beginnen: Sogar Rainbowtable-Angriffe sind...
-- Mak 01:16, 13. Jun. 2011 (CEST)
thread_title:  Rainbow Tables 

message: Salts kamen zu einer Zeit in Mode, als von Rainbow-Tables auf Grund fehlender großer Massenspeicher noch keine Rede war. Frage: Wozu wurden Salts damals eingesetzt? (Soweit ich mich erinnere, wurden Salts erstmals zusammen mit einem aus DES erzeugten Trapdoor-Algorithmus eingesetzt.) --217.6.251.18 09:20, 12. Jul. 2011 (CEST)
thread_title:  Historische Frage 

message: Die Beispiele für die Anwendung von Salts sind derzeit zwei Protokolle (prinzipiell wichtig, auch wenn ich eines davon noch nie gehört habe), und dann gleich "Forensoftware" und schliesslich ganz allgemein "andere Systeme für Internetseiten". Wieso sind ausgerechnet Foren so prominent hervorgehoben? Salts sollten überall verwendet werden, wo Passwörter gespeichert werden. Bei Foren zumeist der Fall, klar, aber eben auch überall sonst, wo man sich registrieren kann oder muss (Mailprovider, Shops, Banken, ...). --y work? 17:08, 3. Jan. 2012 (CET)
thread_title:  Forensoftware? 

message: dieser sachverhalt wird 3x erklärt :-( (nicht signierter Beitrag von 79.226.0.121 (Diskussion) 16:46, 27. Jan. 2012 (CET)
thread_title:  Weiterhin ergeben mehrere gleiche Passwörter mit hoher Wahrscheinlichkeit unterschiedliche Hashwerte. 

message: Der Artikel legt z.Z. viel Wert auf die Aussage "Rainbowtables" werden wertlos etc. gelegt und Wörterbuchangriffe erschwert und damit wird suggeriert, das Hash-Verfahren mit SALTs in irgendeiner Form "an sich" sicherer sind. RTs funktionieren nur mit dem Hash-Verfahren, für welches sie gebildet worden sind. Wird dieses Verfahren verändert, kann man natürlich nicht Tabellen verwenden, welche für die eigentliche Version gebildet wurden. Rainbowtables haben einen Erstellungsaufwand, der um das 10-20 fache höher ist als denselben Zeichenraum zu bruteforcen - daher werden sie in der Regel eher für "Routine"-Bereiche erstellt oder von großen, kollaborativen Projekten für Zeichenräume, bei denen der einzelne Teilnehmer schon viel Zeit für einen Bruteforce verwenden muss. Liegt nun dasselbe Verfahren mit einem ordentlichen SALT vor, kann weiterhin der Zeichenraum, den RTs typischweise abgedeckt werden, gebruteforced werden. Ein einzelnes Passwort wird daher durch SALTs nicht besser geschützt.
Beim Bruteforcen steigt der Rechenaufwand gegenüber dem "Ur-Verfahren" nur, wenn mehrere geSALTete Hashes vorliegen. Dann muss jeder Passwort-Kandidat für jeden vorliegenden geSALTeten Hash berechnet werden und nicht ein einziges Mal erzeugt und dann verglichen werden. Je mehr Hashes vorliegen, desto langsamer wird das Bruteforcen bis es irgendwann nicht mehr wirtschaftlich wird. Daher wird eine Liste mit vielen geSALTetenHashes einfach aufgetrennt, nach interessanten Konten oder schlichtweg nach Menge, bis das einzelne System wieder mit einer angenehmen Geschwindigkeit arbeitet. Desweiteren können geSALTete Hashes, bei denen z.B. exakt das gleiche SALT vorliegt, zusammengefasst werden um den Aufwand wieder zu verringern. Passwortcracker machen das automatisch und hashen einen Kandidaten für jedes SALT nur einmal. 
=== Wörtbuchangriffe ===
SALTs bieten keinen Schutz gegen Wörtbuchangriffe. Gute Wortlisten, selbst mehrsprachige, haben in der Regel weit unter 1 Milliarde Einträge, teilweise unter 50 Millionen. So viele Wörter und Namen, die Menschen auch als Passwort verwenden, gibt es dann doch nicht. Auch hier steigt nur der Rechenaufwand durch das SALT, aber die Zahl der zu prüfenden Kandidaten ist um vieles geringer als beim Bruteforcen. 50 Millionen Kandidaten können selbst bei einer Geschwindigkeit von 10.000 Kandidaten pro Sekunde in 83 Minuten geprüft werden. D.h. Probleme treten nur auf, wenn sehr viele geSALTete Hashes (i.S.v. tausende und mehr) auftreten. Aber auch hier kann die Aufgabe einfach auf mehrere Systeme verteilt werden, so dass z.B. 10 Systeme je 1000 geSALTete Hashes übernehmen und dann die Wortliste doch in akzeptabler Zeit durchbringen.
Alle erfolgreichen Verfahren wie MD5crypt und bcrypt verwenden daher einfach tausende von Iterationen desselben Hashing-Verfahrens um den Rechenaufwand in die Höhe zu treiben. Das ist die nützlichste Kombination mit einem SALT, nun können tatsächlich nur kleine oder sehr kleine Zeichenräume gebruteforced werden und auf Wortlisten können nur begrenzt Permutationsregeln angewandt werden. Aber letztlich gibt es kein Hashingverfahren, welches gegen Wort- oder Namenslisten resistent ist, daher sollte man nie von einem "Schutz" vor Wörtbuchangriffen beim Offline-Cracken sprechen. Vielleicht fieselt das jemand in den Artikel ein :) -- 88.67.75.65 11:52, 2. Mai 2010 (CEST)
replies: text: Habe eben die Redundanz entfernt und auch einige inhaltliche Mängel ausgebügelt, es wird jetzt nicht mehr von verhindern, sondern nurmehr von erschweren gesprochen. Noch irgendwelche Anmerkungen? BTW: Salt schreibt man nicht SALT, da es keine Abkürzung ist. --FGodard|✉|± 13:42, 2. Mai 2010 (CEST)
thread_title:  Schutzwirkungen durch SALTs 

message: SALTs bieten keinen Schutz gegen Wörtbuchangriffe. Gute Wortlisten, selbst mehrsprachige, haben in der Regel weit unter 1 Milliarde Einträge, teilweise unter 50 Millionen. So viele Wörter und Namen, die Menschen auch als Passwort verwenden, gibt es dann doch nicht. Auch hier steigt nur der Rechenaufwand durch das SALT, aber die Zahl der zu prüfenden Kandidaten ist um vieles geringer als beim Bruteforcen. 50 Millionen Kandidaten können selbst bei einer Geschwindigkeit von 10.000 Kandidaten pro Sekunde in 83 Minuten geprüft werden. D.h. Probleme treten nur auf, wenn sehr viele geSALTete Hashes (i.S.v. tausende und mehr) auftreten. Aber auch hier kann die Aufgabe einfach auf mehrere Systeme verteilt werden, so dass z.B. 10 Systeme je 1000 geSALTete Hashes übernehmen und dann die Wortliste doch in akzeptabler Zeit durchbringen.
Alle erfolgreichen Verfahren wie MD5crypt und bcrypt verwenden daher einfach tausende von Iterationen desselben Hashing-Verfahrens um den Rechenaufwand in die Höhe zu treiben. Das ist die nützlichste Kombination mit einem SALT, nun können tatsächlich nur kleine oder sehr kleine Zeichenräume gebruteforced werden und auf Wortlisten können nur begrenzt Permutationsregeln angewandt werden. Aber letztlich gibt es kein Hashingverfahren, welches gegen Wort- oder Namenslisten resistent ist, daher sollte man nie von einem "Schutz" vor Wörtbuchangriffen beim Offline-Cracken sprechen. Vielleicht fieselt das jemand in den Artikel ein :) -- 88.67.75.65 11:52, 2. Mai 2010 (CEST)
replies: text: Habe eben die Redundanz entfernt und auch einige inhaltliche Mängel ausgebügelt, es wird jetzt nicht mehr von verhindern, sondern nurmehr von erschweren gesprochen. Noch irgendwelche Anmerkungen? BTW: Salt schreibt man nicht SALT, da es keine Abkürzung ist. --FGodard|✉|± 13:42, 2. Mai 2010 (CEST)
thread_title:  Wörtbuchangriffe 

message: Gleich am Anfang heisst es: "eine zufällig gewählte Zeichenfolge, die an einen gegebenen Klartext [...] angehängt wird"
Meines Wissens wird das Salt vorangestellt. Also "hash_function($salt$plaintext)". (nicht signierter Beitrag von Dermaush (Diskussion | Beiträge) 21:52, 20. Nov. 2015 (CET)
thread_title:  angehängt oder vorangestellt? 

message: Wie dem geneigten Leser klar werden dürfte und auch der Konsens hier in vorgehenden Diskussionen lautet, bedarf dieser Artikel einer gehörigen Politur. Dieser werde ich mich den nächsten Tagen widmen. Bitte etwaige Fragen etc. hier mit sauberen Abschnitten vermerken. Für zeitnahes Feedback meinerseits bitte auf meiner Diskussionsseite eine Notiz hinterlassen. Danke. --Roeme (Diskussion) 17:02, 22. Mai 2012 (CEST)
replies: text: Meiner Meinung nach ist der Artikel akzeptable, so dass die Überarbeiten-Vorlage entfernt werden könnte. Gibt es da einen Konsens? Joschi71 (Diskussion) 14:24, 14. Jun. 2013 (CEST)
replies: text: Bin auch der Meinung, dass der Artikel nun ausreichend gut ist...C rall (Diskussion) 18:46, 30. Okt. 2013 (CET)
thread_title:  Überarbeitung läuft 

message: So wie ich den Sinn des ersten Satzes verstehe widerspricht der folgende ihm sofort.
Im ersten Satz wird absolut gesagt das die Sicherheit nicht erhöht wird aber im folgenden Satz das Gegenteil bewiesen.
"Wenn der verwendete Salt einem Angreifer bekannt ist, erhöht er nicht die Sicherheit bei einem Angriff auf dieses Passwort.
Ein schwaches Passwort kann also fast ebenso leicht mithilfe von Wörterbuch- oder Brute-Force-Angriffen entschlüsselt werden[4], es muss nur noch durchprobiert werden, an welcher Stelle des Passwortes der Salt angehängt wurde."
Meine Behauptung dabei ist, dass durch eine Erhöhung des Aufwandes ein Passwort zu entschlüsseln, die Sicherheit eines solchen steigt.
Die Frage ist ob Sicherheit in dem Kontext in Beziehung mit dem Aufwand steht der Nötig ist das Passwort zu entschlüsseln, was ich bejahen würde.
Wenn der verwendete Salt einem Angreifer bekannt ist, erhöht er die Sicherheit bei einem Angriff auf dieses Passwort nur in sehr geringem Maß. Ein schwaches Passwort kann fast ebenso leicht mithilfe von Wörterbuch- oder Brute-Force-Angriffen entschlüsselt werden[4], es muss nur noch durchprobiert werden, an welcher Stelle des Passwortes der Salt angehängt wurde. 
--NichtAllwissender (Diskussion) 13:37, 24. Mär. 2016 (CET)
replies: text: Ich gebe dir Recht, dass die Sicherheit vom Aufwand des Knackens abhängt. Ich finde nur den letzten Abschnitt in der neuen Version auch etwas missverständlich. Natürlich erhöht ein geheimer Salt die Sicherheit, weil er dann die Funktion eines Peppers hat. Ich fände eine Formulierung besser in dem Sinne "die Funktion des Salt basiert nicht auf seiner Geheimhaltung" oder "... setzt nicht seine Geheimhaltung voraus". Zu den schwachen Passwörtern: Die Position des Salt ist nicht das Problem und auch meistens bekannt, deshalb schlage ich vor, etwas in der Art zu schreiben "es muss lediglich das Passwort zusammen mit dem Salt durchprobiert werden." 
--Beloumi (Diskussion) 10:52, 16. Apr. 2016 (CEST)
thread_title:  Missverständniss oder unwissenheit? 

message: "Wörterbuchangriffe durch Rainbow Tables werden erschwert, da nicht mehr in einer Liste von verschlüsselten Werten (Hashtabelle) der zugehörige entschlüsselte Wert nachgeschlagen werden kann, sondern für jeden Klartext hash (Klartext + Salt) = bekannter Hash überprüft werden muss, was viel Rechenzeit kostet. "
Warum heißt es hier, dass der "entschlüsselte" Wert nachgeschlagen wird ? 
Es handelt sich schlicht um Klartext aus einer eigenen Rainbow Table. Das Gegenteil von "verschlüsselt" ist nach meinem Verständnis "unverschlüsselt" und nicht "entschlüsselt". Es erschwert auch das Verstehen des Vorgangs. 
Ich hatte das gestern stillschweigend geändert, heute ist es zurückgesetzt. ? Gruß Matze (nicht signierter Beitrag von 178.201.21.117 (Diskussion) 10:22, 25. Mai 2016 (CEST)
replies: text: hallo, vielen dank für deine mitarbeit. deine bearbeitung wurde nicht zurückgesetzt. änderungen von nicht angemeldeten benutzern müssen gesichtet werden, bevor sie angezeigt werden (s. WP:Gesichtete Versionen). das habe ich gerade getan. --Mario d 12:22, 25. Mai 2016 (CEST)
thread_title:  Entschlüsselt oder unverschlüsselt