Die sichersten Arten des Logins

[Sven Rautenberg]

Moin!

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.

Was bestimmt supergut ankommt, wenn damit der eine blöde Mitarbeiter der gesamten Firma das Login des NAT-Netzwerks sperrt.

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.

Richtig, das lernt man eigentlich doch schon im Cracker-Kindergarten: Wenn man BruteForce nehmen muß, ist es einfacher, ein leichteres Ziel woanders zu suchen.

Es sei denn, der Aufwand lohnt sich. Wenn sich der Aufwand lohnt, gibts allerdings auch nicht solche Pipifax-Passworte, sondern richtige. Wenn überhaupt, denn auch kryptographische Authentifizierungsverfahren sind mit SSL ja recht einfach zu realisieren, und deutlich sicherer, als ein Passwort.

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.

Wenn ich lokal den Hash knacken will, muß ich den aber erst mal haben.

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.

SQL.Injection funktioniert nur, wenn a) extrem schlechter Code geschrieben wurde, bei dem sowas möglich ist, und b) SQL überhaupt zur Ermittlung des Accounthashes benutzt wird. Es gibt ja noch diverse andere Methoden, Passwörter zu speichern.

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).

Doch.

62 Symbole, 4 Stück = 62^4 = 14776336.

16 Symbole (Hexzahlen), 32 Stück = 16^32 = 3,4e+38

Wenn man weiß, dass doppeltes MD5 benutzt wird, ist das genauso schnell zu bruteforcen, wie einfaches MD5. Kostet nur etwas mehr Rechenzeit für die Doppelberechnung von MD5.

Wenn du argumentierst "Ja, das weiß man eben nicht", dann frage ich mich, was gegen die Verwendung von Salz als Prefix oder Suffix spricht?

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.

36 Möglichkeiten mit 8 Zeichen sind 36^8 = 2,8e+12 - klingt also nicht unrealistisch hinsichtlich Bruteforce. Aber mit Bruteforce doppeltes MD5 zu knacken kosten vielleicht die doppelte Zeit wegen doppeltem Rechenaufwand - mehr aber auch nicht. Also vier statt zwei Stunden.

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 würde die Zeit nur verdoppelt werden, sofern die Programme wirklich ideal wären und 100% in produktive Rechenarbeit stecken, hingegen keinerlei in Organisationsaufgaben.

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.

Das sicherzustellen ist also extrem wichtig! Denn damit schützt man sich nicht nur vor dem eher unwahrscheinlichen Angriff über Bruteforce eines bekanntgewordenen Passworthashes, sondern auch gegen Bruteforce beim Login!

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?

Das kann ja nicht mein Problem sein, wenn andere Software schlecht mit den Passwörtern umgeht.

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.

Das bedeutet also, dass der Angreifer sowohl volle Kenntnis über den Hash als auch den verwendeten Mechanismus zur Generierung desselben hat.

Mit anderen Worten: Er kann munter zuhause bruteforcen, weil ihn das doppelte MD5 nicht überrascht.

In meinen Post ging es vor allem darum, das man evtl. per SQL Injection o.ä. an die DB Daten kommt.

In deinem Post ist von SQL-Injection nicht ein einziges Mal die Rede gewesen. Du mischst hier ganz munter die Angriffsszenarien so, wie es dir in den Kram paßt.

Zuasmmenfassend lässt sich sagen, dass du sicher recht hast, das man Passwortregeln aufstellen muss.

Das ist unabdingbar. Schön, dass du das einsiehst.

Sonderzeichen sind mir dabei icht so ganz geheuer bzw. man müsste diese Einschränken (Gefahr der SQL Injection etc.).

Sorry, aber du hast keinerlei Ahnung, wie Absicherung gegen SQL-Injection funktioniert, oder?

Ich persönlich würde ein möglichst langes Passwort erzwingen, soll der Nutzer sein normales Passwort halt 2,3 mal wiederholen.

Oh, wahnsinn! Super Idee! Statt den Nutzer einmal in die wirklich sichere Methode einer vernünftigen Passworterstellung einzuweisen, schluderst du wieder rum.

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.

Damit handelst du dir Zeichensatzprobleme ein. Die klassischen ASCII-Zeichen sind überall die gleichen, Umlaute nicht. Schon mal dran gedacht, was passiert, wenn eine Website von ISO auf UTF-8 umstellt?

Die 2fache Verschlüsselung bringt meiner Meinung nach sehr wohl etwas, unabhängig von der stärke des ursprünglichen Passwortes.

Die doppelte Verschlüsselung bringt nichts. Schwache Passworte bleiben schwach!

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!

Zu dem Thema Cookie hatte ich mich noch nicht geäußert - aber das ist auch eine Schwachsinnsidee. Wozu gibt es Session-Mechanismen? Da erhält der Nutzer jedesmal eine andere Session-ID, und man kann an der ID bruteforcen, wie man will - sie hat keinerlei Bedeutung, enthält keine Passworte etc.

Insgesamt kritisiere ich an deiner Vorgehensweise, dass du Glauben machen willst, md5() sein eine Sicherheitsfunktion, und je häufiger man sie anwendet, desto mehr Sicherheit bekäme man.

Diese Ansicht ist grundsätzlich falsch!

- Sven Rautenberg