Diskussion:Brute-Force-Methode

Stochastik

Auf den mathematischen Bereich ist man jetzt gar nicht wirklich eingegangen, oder? Wäre es nicht vielleicht auch interessant, Brute-Force von der Wahrscheinlichkeits Rechnung her zu beleuchten (mögliche Themen: Wie lange dauert es bis man aus einer Menge mögliche Passwörter 1 richtiges hat / aus einer Menge (Zugans-)Keys/Tokens n gültige hat. Wie viele Zahlen sind in einem handelsüblichen Passwort, Sonderzeichen, Groß-/Klein Buchstaben -> viele Möglichkeiten ergeben sich daraus? etc.) --Sedrubal (Diskussion) 01:36, 15. Jan. 2015 (CET)

X Millionen Abfragen pro Sekunde

15-20 Millionen abfragen pro Sekunde? Erst fand ich den wert nur erstaunlich aber mittlerweile , durch Recherche und eigenes ausprobieren bin ich nicht mehr im Stande diese Zahlen ohne jegliche "beweise" oder "verweise" bzw. belege zu akzeptieren. Selbst wenn der PC im Stande wäre 15-20 Millionen Möglichkeiten in der Sekunde zu berechnen, so müssen diese gegen ein Hash geprüft werden (wenn Sie im Klartext vorlegen würden müsste man sie ja nicht durch Bruteforce ermitteln?) allein die Verschlüsslung bzw. hash Erstellung und die Gegenprüfung verlängern die Prozedur schon erheblich. Ich halte diesen wert für übertrieben und für Panikmacherei.

Ich habe jetzt mal mit c/c++/c# ein paar Permutationen von Strings durchlaufen lassen , und komme auf 3.600.000 Permutationen pro Sekunde. Wenn hier also niemand einen "Gegenbeweis" liefert werde ich die zahlen ändern. (P4, 2.8GHz)

Ja, bitte ändern. Ich hab auch überlegt, ob die Zahl so passt. Außerdem ist es immer abhängig von der Komplexität eines Algorithmus - RAR knackt sich bspw. nicht so schnell wie ZIP. Auch diese Information fehlt im Artikel... --E7 13:33, 6. Feb. 2009 (CET)

Auf einem P4 mit 2,4 GHz sind 25 Millionen Versuche pro Sekunde wohl überhaupt kein Problem mehr. Die Performanceleaks liegen nicht in den Rechnern, sondern in den Homebrew-Programmen. Wenn ich alleine schon den Begriff "String" höre, wundert mich schon gar nichts mehr. In einem solchen Programm wird man keine Strings finden - schon gar nicht ide lahmen Teile aus einer Java, C# oder C++-Klasse. Nur sol als Anregung: Ich habe einen errechneten Hash und will ihn mit einem bestehenden vergleichen. In nehme die erste vier oder acht Byte des errechneten und ziehe davon die ersten vier oder acht Byte des gesuchten ab. Ist das Ergebnis ungleich Null, dann brauche ich gar nicht weitermachen - die beiden sind unterschiedlich. Ein 256Bit Hash ist damit in maximal 8 oder 4 Subtraktionen verglichen - zusammen mit dem Laden und dem Speicher-Shiften kommen im Worst Case (erst das letzte Byte ist unterschiedlich) rund 48 Operationen zusammen. Im Schnitt sind es (Erfahrung) rund 20 Operationen - ein 2,4 GHz P4 schafft rund 4,5 Mrd. Operationen pro Sekunde, sind also auf meinem Rechner gut 93 Mio. Hashtests pro Sekunde. Die Hashtests sind nicht das Problem, die Berechnung der Hashes ebenfalls nicht. 25 Mio. Angriffe pro Sekunde sind mit einem P4 zwischen 2,66 und 3 GHz kein Wunschtraum, sondern ein Erfahrungswert.

Ich kenn mich zwar nicht mit den Hintergründen aus, aber so wie ich das lese, bekomme ich den Eindruck, dass ihr bereits mehr verwendet als Brute-Force, da selbige Methode ja das simple durchprobieren aller möglichen Codes ist. MfG, --Dr. Al. K. Lisch ?!  +/- 12:42, 15. Mär. 2009 (CET)

Nein, sie verwenden durchaus noch Brute-Force. Brute-Force sagt nur aus, das man alle möglichen Sachen durchprobiert, und das tuen sie ja. Das sie dies komplexer gestalten ist unerheblich, denn sie probieren immernoch jeden Wert durch. Soweit ich es als Hobbyprogrammierer (ca. 3 Jahre) verstanden habe. Nochmal kurz zusammengefasst: Es ist nur erheblich, OB alles durchprobiert wird, nicht WIE. Das strings um einges langsamer sind, sollte klar sein. -- FlySoft

Was Wikipedia nicht ist

Argh, das Lemma bitte wieder zu Brute-Force-Methode ändern, Wikipedia ist nicht der Ort neue Begriffe zu erfinden, bzw. krampfhaft einzudeutschen. Siehe: Wikipedia:Was Wikipedia nicht ist --Blubbalutsch 20:29, 17. Jul 2005 (CEST)

Passwörter mit mehr als 8 Zeichen

hm... der Satz Dies kann nur ausgeschlossen werden, wenn Passworte mit 8 oder mehr Zeichen verwendet werden. ist irgendwie komisch und falsch... selbst durch ein Passwort mit mehr als 8 Zeichen kann nicht ausgeschlossen werden, dass das Passwort per bruteforce geknackt wird. Ich lösch den Satz einfach mal... --Pegmag 00:12, 4. Apr 2006 (CEST)

Da magst du recht haben, aber selbst bei einer Geschwindigkeit von 25 Millionen Versuchen pro Sekunde, wirst du gut 101 Tage brauchen um alle Möglichkeiten durchzuprobieren (Bei zweiundsechzig möglichen Zeichen (=Buchstaben groß und klein + Zahlen ohne Sonderziechen)

62^8 = 2,183401056*10^14
-> 2,183401056*10^14):(60*60*24) = 101,0833822

mfg --Dr. Al. K. Lisch ?!  +/- 10:00, 14. Sep. 2008 (CEST)

Dabei ist allerdings zu bedenken, das sich die 25Mio. Überprüfungen/Sekunde auf einem Mittelklasserechner aus dem Jahre 2008(!) bezogen! Wenn man ein Rechenzentrum zur verfügung hat, sinkt die benötigte Zeit schnell. Das sollte dabei bedacht werden. -- FlySoft

Software

Um eine brute force Attacke erfolgreich fahren zu können benötigt man doch eine Software, die automatisiert den Angriff ausführt, oder? Im Artikel steht nichts darüber. --87.165.255.33 09:21, 14. Nov. 2006 (CET)

Du kannst eine Brute-Force-Attacke auch manuell ausführen, d.h. sämtliche Passwörter von Hand eintippen. Nicht so effizient, aber dennoch "Brute Force"... --217.24.207.26 16:13, 16. Nov. 2006 (CET)

Schutz

Als Schutz vor einem Brute-Force-Angriff wird momentan nur die Passwortlänge aufgeführt. Sollten nicht auch andere Schutzmechanismen, wie z.B. die Sperrung des Zugangs bei einer gewissen Anzahl von Falscheingaben oder die Vorgaukelung eines erfolgreichen Logins (u.a. bei "Mobile Sitter" vom Fraunhofer-Institut) auch erwähnt werden ?

Die Methoden können nur funktionieren, wenn der Angriff nur durch Verwendung einer Überprüfung ausgeführt werden kann, welche nicht unter der Kontrolle des Angreifers ist (vgl. Wörterbuchangriff#Mögliche_Angriffsziele). Wenn der Angreifer die zum Knacken benötigten Daten, meistens also Geheimtext/Hash-Wert und, falls verwendet, das Salt, über einen anderen Weg erhalten kann und der Algorithmus zum Berechnen des Geheimtextes bekannt ist (dieses ist in den meisten Fällen der Fall), sind die genannten Methoden wirkungslos. Eine Erwähnung im Artikel (zusammen mit diesen Einschränkungen) sollte aber in Ordnung sein. --Phistev 00:35, 12. Jan. 2008 (CET)

Wenn die Überprüfung nicht unter der Kontrolle des Angreifers ist, können Brute-Force-Methoden ganz einfach unterbunden werden, in dem die Überprüfung ausreichend langsam gemacht wird. 0.1s Verzögerung dürften einen Onlinebanking-Kunden beim Anmelden nicht stören, summieren sich aber bei 25 Mio ausprobierten Passwörtern auf knapp 30 Tage (allerdings sind beim Onlinebanking ja eh die Falscheingeben begrenzt). Naclador 10:37, 15. Mär. 2009 (CET)

Warum versucht man nicht diese Verzögerung der Überprüfung möglichst tief im System zu implementieren? Ein System, an dem sich Benutzer üblicherweise durch Tastatureingabe des Passwortes identifizieren, muß nicht tausende von Eingaben pro Sekunde zulassen!

Es gibt keine effizienten Algorithmen?

Dieser Satz macht mir Sorgen: "Für viele Probleme in der Informatik gibt es keine effizienten Algorithmen." Ist das nicht sehr gewagt? Ich mein, das wahrscheinlich wichtigste Problem der theoretischen Informatik widmet sich gerade der Frage, ob es für bestimmte Probleme effiziente Algorithmen gibt, oder nicht. Und hier wird das so lasch einfach vorausgesetzt? Ich ersetze den Satz mal durch "Für viele Probleme in der Informatik sind keine effizienten Algorithmen bekannt."

So war es auch gemeint, guter Vorschlag. ↗ nerdi ^disk. 10:41, 13. Dez. 2008 (CET)

Für viele Probleme gibt es beweisbar keine effizienten oder gar keine Algorithmen. Für das Halteproblem gibt es gar keinen. Zudem besagt der Zeithierarchiesatz, dass es für jede Zeitfunktion ein Problem gibt, das in dieser Zeit unmöglich zu lösen ist. Der Beweis ist simple Diagonalisierung. 37.192.43.230 06:35, 13. Feb. 2016 (CET)

Kann es einen Algorithmus mit rotierendem Klartext geben?

Tehoretisch wäre es möglich,aber es hat noch keiner geschaft man müsste eigentlich nur genug Leute haben,die sich mal an diese Aufgabe setzen.Ich würde es selbst versuchen aber leider weiß ich nict wie man solche Programe schreibt.Also wer interesse hat so ein Programm zu schreiben und es wirklich schaft,der sollte nähmlich schleunichst auf den markt damit den das währe das Ultimative verschlüsselungsprogram für e-mails das kann 100% nicht geknackt werden. (nicht signierter Beitrag von 79.205.134.50 (Diskussion | Beiträge) 15:26, 31. Aug. 2009 (CEST))

Es gibt bereits mehrer Algorhytmen, welche theoretisch sicher sind (vlg. One-Time-Pad, und Speziell für E-Mail ist das RSA-Kryptosystem mit ausreichend langem Schlüssel genug, und einfach) Ich verstehe auch "rotierendem Klartext" nicht, was meinst du damit? Ich meine so etwas schonmal im fikitionalen(!) Dan-Brown Roman "Diabolus" gelesen zu haben, vielleicht lese ich es nochmal.

Nachtrag: Ich habe mich jetzt ein bisschen mit dem Thema beschäftigt. Ich hatte mich bereits im Buch über den Begriff "rotierender Klartext" gewundet. Der Klartext ist der Text, der die Nachricht ursprünlic war. Wenn ein Computer ihn nicht erkennen kann, kann es der Mensch auch nicht. Ein sicheres System gibt es bereits, das oben erähnte One-Time-Pad ist sicher. Ich vermute stark, das du u ihn aus dem Buch hast. Wenn nicht, bitte ich dich, eine Qulle anzuführen. Danke. -- FlySoft

Erhöhung der Rechenleistung

Es wurde ja im Artikel geschrieben, dass durch die höhere Rechenleistung mehr Möglichkeiten ausprobiert werden können. Aber müsste nicht die Brute-Force-Methode in der Zukunft immer schwächer werden? Immerhin werden ja auch die Schlüssellängen immer größer. Und es ist doch einfacher einen Schlüssel zu erzeugen, als ihn zu knacken, oder? Ich finde das wichtig zu erwähnen ("dank" mangelndem Fachwissen ist das obige nur geraten). -- Flowmaster94 17:12, 4. Jan. 2010 (CET)

Wenn du die Schlüssellänge schneller steigen lässt als die Rechengeschwindigkeit stimmt das zumindest solange wie du keine effizienten Algorithmen entwickelst um die Probleme zu lösen. Beispielsweise wird RSA wohl früher oder später vollkommen nutzlos werden, wenn Quantencomputer ins Spiel kommen (Mit dem Shor-Algorithmus lassen sich beliebige Zahlen in polynomaler Zeit faktorisieren, wodurch RSA wirkungslos würde).Die Frage ist, ob die Schlüssellännge immer weiter steigt: Sie kann nicht größer werden als die des Passworts, dass du verwendest, sonst probiert man halt die Passwörter durch. Und ich glaube nicht, dass die meisten Leute heute sonderlich längere Passwörter als früher nehmen. Das hängt zwar vom Einsatzzweck (Bei Geheimdienstsachen u.Ä. mag das anders sein) ab, aber prinzipiell lässt sich das Entstehen vom so bedeutend sichereren Passwörten wohl nicht sagen. (Auch ich bin kein Experte und kann mich hier irren) Gruß, Dr. AL. K. Lisch 14:08, 11. Jan. 2010 (CET)

Abrenzung zu "Trial and Error"

Ich kenne den Zusammenhang zwischen der Brute-Force-Methode und Trial and Error (Versuch und Irrtum) nicht. Könnte jemand sagen, in wieweit beide gleichbedeutend sind/ in Beziehung stehen/ sich unterscheiden/ unterschiedlich gebraucht werden? Für mich klingt beides sehr ähnlich. -- Tanja91 14:27, 8. Dez. 2011 (CET)

Cracker?

Ein Cracker ist eine person, die kostenpflichtige Inhalte gratis zur Verfuegung stellt. Hacker waere der geeignete ausdruck (nicht signierter Beitrag von 85.103.52.75 (Diskussion) 16:39, 9. Aug. 2012 (CEST))

Quelle

Also ich finde es nicht in Ordnung, dass folgendes Satz sogar ein DATUM bekommt, aber keine Quelle: "Schon auf einem handelsüblichen Mittelklasse-Computer können etwa 15 bis 25 Millionen Passwörter pro Sekunde ausprobiert werden (Stand 2008)." Das klingt sehr seltsam und meiner Meinung nach einfach nur geraten! Außerdem: Es macht einen Unterschied, was geknackt werden soll. So ist die Entschlüsselung von DES dreimal so schnell wie die von 3DES. Wesentlich langsamer, wird die Entschlüsselung von AES sein. Obiger Satz hat damit kaum einen Informationsgehalt. (nicht signierter Beitrag von 138.246.2.202 (Diskussion) 07:28, 28. Feb. 2014 (CET))

Redundanz?

Im Artikel taucht die Formulierung wiederholte Iteration auf. -- Ist das nicht eine Informationsdopplung? (Ich zumindest kenne den Begriff Iteration etwa "periodische Wiederholung" -- bzw. iterativ etwa "immer-wiederkehrend-geschehend" -- bedeutend.) --88.69.241.184 22:49, 21. Okt. 2014 (CEST)

Abschnitt über Passwortsicherheit

Die Verbindung zwischen der Brute-Force-Methode und Passwortsicherheit liegt auf der Hand. Aber ist der Absatz zu den Maßnahmen gegen Brute-Force-Attacken auf Passwörter mit Salts, Hashes, Rainbow-Tables und dergleichen nicht doch ein bisschen weit ausgeholt?

Untertitel

Der Untertitel "Entschlüsselungsmethode" ist unzutreffend resp. unvollständig. Jenes wird allein durch den Abschnitt der Spieltheorie klar.

Treffender wäre etwa "Lösungsmethode der Informatik", wie in der Einleitung dargestellt. YHolla (Diskussion) 21:47, 30. Apr. 2021 (CEST)