nicht angemeldet
Hallo Sven,
wie ich bereits geschrieben habe, ist das Passwort "test" nur ein Beispiel! Mir ist klar das sowas nicht sicher ist und per Dictionary Attack ohne weiteres zu knacken ist, auch wenn man nur Zugriff auf den Login hat.
"Dagegen sichert man sich, indem man im Passwort eine Mindestlänge fordert, und neben kleinen Buchstaben auch noch große Buchstaben, Zahlen oder Sonderzeichen."
->Technisch/Mathematisch gesehen ist ein längeres Passwort besser als ein kürzeres mit Sonderzeichen. Mit Sonderzeichen lychen einen wahrscheinlich die Besucher der Seite, die Allgemeinheit ist ja allgemein faul und hat von Sicherheti null Ahnung, das wissen wir wahrscheinlich beide. Ansonsten stimme ich dir natürlich zu, das es sicherer wäre.
"Das läßt sich nur deswegen per Brutforce knacken, weil du ein so schlechtes Passwort erlaubt hast."
->War wie gesagt ein Beispiel, recht haste natürlich trotzdem.
"Gewiß ist es recht simpel, einfach bei "aaaa" anzufangen, alle daraus resultierenden MD5-Strings zu erzeugen, und abzuwarten, bis der gewünschte String rauskommt.
Aber genauso einfach ist es, einfach das vier Zeichen lange Passwort als Loginversuch zu verwenden - das Loginsystem wird sich schon melden, wenn es das Passwort als korrekt erkannt hat."
->Beim bruten des Logins kansnt du aber eine IP einfach nach z.B. 3 falschen Versuchen sperren. Natürlich köntne man diverse Proxys nutzen etc. Aber wenn das Passwort nicht grade allzu kurz/simpel ist oder im Wörterbuch steht, ist das nicht wirklich praktikabel.
Würdest du lokal den Hash bruten, hättest du diese Einschränkungen nicht, also muss man schaun hier entsprechend einen Riegel vorzuschieben - also entweder doppelt verschlüsseln, was sowohl schwache als auch bereits starke Passwörter nochmal stärkt oder halt n Salt dazu.
"Es ist für das Speichern eines Passwortes absolut irrelevant, ob das im Klartext, mit MD5, mit SHA1, mit doppeltem MD5 oder ROT13 passiert."
->Ist es absolut garnicht. Stichwort SQL Injection. Hier macht es dann sehr wohl n Unterschied, ob ich das Passwort erst noch bruten muss oder nicht.
"Entscheidend für die Sicherheit ist, dass das Passwort vom User selbstverständlich immer im Klartext eingegeben wird, der Prüfmechanismus kann also so komplizierte und lange Strings produzieren, wie er will - das hindert einen Angreifer nicht, zu kurze Klartextpassworte durch Ausprobieren im Login herauszufinden."
->Dieses Problem wird man aber immer haben. Auch wenn man, wie du richtigerweise vorschlägst, eine Mindestlänge sowie eine Kombination von diversen Zeichen fordert.
Das gibt aber keinen Grund dafür, andere Mögliche Sicherheitslücken nicht zu schließen.
"Du behauptest hier Dinge, ohne den Beweis anzutreten. Deshalb widerspreche ich deiner Darstellung einfach mal."
-> Du kannst es ja selbst ausprobieren bzw. korrigiere mich wenn ich falsch liege, ich will hier ja auch noch was lernen:
4^62 < 32^62 (Zeichen^(26+26+10 für a-z,A-Z,0-9, hoffe ich habe hier jetzt mal keinen Zahlendreher drinne).
Ich kann dir nur sagen, dass ich und viele andere einen MD5 Hash eines Passwortes mit a-z0-9 und max.8 Zeichen in rund 2 Stunden als Klartext haben, wäre es 2mal verschlüsselt allerdings nicht.
Bei den von dir geforderten Zeichen würde ich das Passwort ab einer entsprechenden Länge auch nicht in einer rentablen Zeit herausbekommen, da Stimme ich dir ebenfalls zu. Aber wäre dieses ebenfalls nochmal verschlüsselt, würde es nochmal länger dauern.
"Es ist für einen Angreifer, der in einer Datenbank MD5 als Passwort vorfindet, praktisch unmöglich, daraus wieder die Originalen Passworte herzustellen."
-> Bei entsprechend langen und starken Passwörtern, ja.
Aber schau dir diverse Boards an, da gibt es per Standard keine richtigen "Passwortrichtlinien" und die Passwörter werden (z.B. beim WbbLite) einmalig per md5() verschlüsselt. Und wieviele Nutzer benutzen simple Passwörter, wenn man ihnen nichts anderes vorschreibt?
"Da würde man extrem viel Rechenzeit sinnlos drauf verschwenden, ohne wirklich Erfolge zu haben."
-> Bei entsprechenden Passwörtern nutzt man einfach die verfügbaren Rainbow Tables im Netz, spart ne Menge Zeit.
"Außerdem wäre noch zu klären, wie der Angreifer denn an den Passwort-Hash kommen kann. Was sagt so ein Vorfall über die Sicherheit?"
->Wie bereits erwähnt, SQL Injection, diverse Exploits wenn der Hoster nicht regelmäßig Updates fährt, schwaches SQL Passwort und externer Zugriff etc. Angriffsmöglichkeiten gibs viele.
"Man könnte also, wenn man wollte, einfach an dieser Stelle die Accountdaten anzapfen, ohne sich auch nur einen Deut um doppeltes, dreifaches oder tausendfaches MD5 zu scheren."
->Wie gesagt, das geht aber immer und sit ein anderer Angriffsweg.
In meinen Post ging es vor allem darum, das man evtl. per SQL Injection o.ä. an die DB Daten kommt.
Zuasmmenfassend lässt sich sagen, dass du sicher recht hast, das man Passwortregeln aufstellen muss. Sonderzeichen sind mir dabei icht so ganz geheuer bzw. man müsste diese Einschränken (Gefahr der SQL Injection etc.). Ich persönlich würde ein möglichst langes Passwort erzwingen, soll der Nutzer sein normales Passwort halt 2,3 mal wiederholen. Optimalerweise erzwingt man statt Sonderzeichen einfach die deutschen Umlaute (zumindest bei deutschsprachiger Zielgruppe), denn die gibt es per default bei den meisten Brute Force Programmen nicht, bei den Rainbow Tables im Netz auch nicht.
Die 2fache Verschlüsselung bringt meiner Meinung nach sehr wohl etwas, unabhängig von der stärke des ursprünglichen Passwortes.
Auch wichtig, die Unterscheide der Passwörter in der DB und im cookie, sosnt könnte man ein entsprechendes Cookie ja selbst erstellen, ohne jemals das Passwort im Klartext gekannt zu haben!
MudGuard
Der Martin