Wieso braucht ein Passwort Sonderzeichen?

[Dese]

Hallo,

@ Kanibal,


die Kollisions Wahrscheinlichkeit gibt es nicht, wenn man den Hash Saltet, und hinten beispielsweise noch die ID des Users dran hängt, dann ist der Hash einmalig.

Beispiel: das Passwort beim registrieren erfassen, und die ID des users an den String des Passwortes hängen, dann das ganze in sha1 oder Md5 mehrfach hashen, einen Salt benutzen z.B. alle Zahlen 4 mit 3 austauschen und umgekehrt, und hinten noch die ID des Users dran, da wünsche ich dem Hacker mal viel spaß bei...

es ist scheiß egal was du an das passwort noch drannhängst oder nicht. merhfaches hashen erhöht die kollisionswkt. das problem ist nicht die eindeutigkeit der eingabe, das problem ist, dass die ausgabe (ergebnis des hashens) für mehrere eingaben in frage kommt und das verschlimmert sich im allgemeinen (das muß es nicht, jeh nach verfahren, aber ist bei den gängigen hash-funktionen der fall).

 

[Daaron]

Ich will mich nicht unbedingt in die Diskussion einmischen, sondern lediglich auf eine Reihe interessanter Artikel auf Arstechnica aufmerksam machen:
http://arstechnica.com/security/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/

Toll. Dieser Artikel verrät uns, was zumindest leidlich erfahrene Entwickler eh schon wussten: reines MD5 ist lächerlich. Aber schon, wenn bei MD5 einfach mit Salt&Pepper gearbeitet wird und selbige Werte nicht kompromittiert werden, wird es um ein vielfaches schwerer, hier verwerbare Ergebnisse zu finden.
Spätestens bei bcrypt() hätten die sich allesamt die Zähne ausgebissen.

 

[terminator60000]

Hallo,

@ Daaron,

Ich versteh nicht, wo ein Sonderzeichen ein Problem darstellen sollen.

Kurzes Beispiel:
Wenn ich eine Datenbank abfrage habe:

SELECT * FROM `tabelle` WHERE `password`='$passwort';

und ich habe ein schlecht gecodetes script, welches die übergebenen Werte nicht entkräftet,
dann kann ich in mein passwort, username usw. einfach folgendes eingeben:

''; DROP DATABASE `datenbank`;--

und schon lösche ich mit einer einzigen abfrage gleich die gesammte Datenbank.

Es gibt dort viele Methoden wie ich die Datenbank mittels eingaben vom User beeinflussen kann.
Und wenn ich als Programmierer so aus angst vor Hackern jede eingabe vom User entkräften lasse, aber bei der eingabe von Passwörtern die sonderzeichen als solche bestehen lasse, ist das höchst Fahrlässig, dann öffne ich ja Tor und Türe.

Nix, was ein Botnetz aufhält. Primäre Angreifer sind heute doch keine einzelnen Rechner mehr, sondern Command & Control - Server.

Natürlich hast du recht, und man ist mit dem was ich geschrieben habe ungeschützt gegen Angriffe von Botnetzen, um meinen Vorpost zu ergänzen: der Cracker hätte aber einen mehr aufwand, was ihn bei einem kleinem Shop evtl. schon aufhällt, aber wenn man ihn von seinem Ziel nicht abbringen lässt, könnte man z.B. überprüfen wie viele Anfragen mit demselben Aufruf (Nutzername = HalloWelt) es gibt, und dementsprechend deaktiviert man dann für eine gewisse zeit die Login Funktion beispielsweise für 1 Stunde. (Hat ein Vorposter ja bereits geschrieben).

Ich denke dass man sich vor Angriffen wie Botnetzen schützen kann, und auch einen "Notfallplan" für die Passwörter haben kann: z.B. eine Verschlüsselungstechnik welche keine Kollisionen verursacht, ohne dass der Nutzer dazu gezwungen werden muss, ein Sonderzeichen einzugeben.

@ Dese

es ist scheiß egal was du an das passwort noch drannhängst oder nicht. merhfaches hashen erhöht die kollisionswkt. das problem ist nicht die eindeutigkeit der eingabe, das problem ist, dass die ausgabe (ergebnis des hashens) für mehrere eingaben in frage kommt und das verschlimmert sich im allgemeinen (das muß es nicht, jeh nach verfahren, aber ist bei den gängigen hash-funktionen der fall).

Tut mir leid, vergiss den Satz von mir bitte, das war eine Vollkommene Falschaussage, die Hashes die am ende rauskommen wären natürlich dieselben wenn ich beispielsweise "haus" Hashe und bei dem wort "Bär" der geiche raus kommt, in diesem fall würde es natürlich eine Kollision geben.
Die von mir beschriebene Funktion wäre jedoch in sachen Decrypt recht knifflig, und wenn ich brute force unterbinden kann, braucht der Cracker nur zu wissen, wie ich den salt gesetzt habe, und was ich verändert habe, um die Verschlüsselung zu knacken. Heißt: Er müsste einsicht auf die php Dateien besitzen um herauszufinden was die Passwörter bedeuten.

Oder liege ich da falscher ansicht?

 

[Dese]

hmm, wenn ich jetzt noch mal deinen post oben lese, meintest du, dass du die userid hinten an den GEHASHTEN wert hängst? als an das ergebnis des hashens?

das garantiert zwar auch nicht, dass es zu keinen kollisionen kommt, aber viel problematischer ist, dass die userids im allgemeinen nicht zu verheimlichen sind. das problem ist ja zu einer bekannten userid das passwort zu finden. wenn ich diese also kenne, dann kann ich die vom hashwert auch wieer abschneiden.

aber deinen zweiten post verstehe ich nicht. hab keine ahnung, was du da erklärst.

 

[Daaron]

Kurzes Beispiel:
Wenn ich eine Datenbank abfrage habe:

SELECT * FROM `tabelle` WHERE `password`='$passwort';

Schönes Beispiel, wie man es so oder so nicht macht. Klar, SQL Injection in Reinstkultur... aber: Wir sind weder Sony Entertainment noch Mr. Spex, wo sowas mal eben klappen kann.

1.) password=$password <- tja... was soll ich dazu sagen. Entweder steht sowohl in der Spalte password als auch in $password ein Hash, dann ist hier eine Injection unmöglich. Oder aber eine Injection ist möglich, dafür steht in der DB das Passwort direkt mal im Klartext.
2.) Selbst WENN wir das jetzt statt auf password eben auf user anwenden (user = $user AND password = $hashpw)... Wir sind doch erwachsene Menschen, oder? Wir können doch alle von 12 bis Mittag denken. Selbst für Steinzeit-Entwickler wäre das Problem mit mysql_real_escape_string($user) sofort aus der Welt. Programmierer, die bereits in der Neuzeit angekommen sind, nutzen hingegen eine Form von Prepared Statements. Selbige sind, wenn man sie nicht total falsch verwendet, immun gegen SQL Injection, auch ohne dass man User-Eingaben vorher bereinigt.
3.) Dein Beispiel geht nicht. PHP verweigert das Ausführen mehrerer Queries in einem Aufruf aus Sicherheitsgründen.

Ich denke dass man sich vor Angriffen wie Botnetzen schützen kann, und auch einen "Notfallplan" für die Passwörter haben kann: z.B. eine Verschlüsselungstechnik welche keine Kollisionen verursacht, ohne dass der Nutzer dazu gezwungen werden muss, ein Sonderzeichen einzugeben.

Du hast unbewusst das Stichwort genannt: VERSCHLÜSSELUNG. Viele Systeme verwenden noch Hash-Verfahren, und hier liegt der Hund begraben. Wenn statt dessen wirkliche Crypto-Verfahren wie bcrypt verwendet würden, wäre das Problem deutlich kleiner... und trotzdem wären 6 Zeichen mit Sonderzeichen deutlich robuster gegen Brute-Force als es 10 alphanumerische Zeichen wären.

Die von mir beschriebene Funktion wäre jedoch in sachen Decrypt recht knifflig, und wenn ich brute force unterbinden kann, braucht der Cracker nur zu wissen, wie ich den salt gesetzt habe, und was ich verändert habe, um die Verschlüsselung zu knacken. Heißt: Er müsste einsicht auf die php Dateien besitzen um herauszufinden was die Passwörter bedeuten.

Sicher, die Achillesferse von Salt-Verfahren (man sollte sie trotzdem verwenden) ist der Moment, wo ein Angreifer wirklich auf den Quellcode des Projektes zugreifen kann, und nicht nur irgendwie an einen Datenbank-Dump gelangt ist. Solche Angriffe sind aber viel seltener. Außerdem:
Wenn ein Angreifer deine salt.php auslesen kann, dann braucht er auch gar keinen Rechenaufwand mehr betreiben. Viel schneller und billiger wäre es, einfach die login.php so umzuschreiben, dass jeder erfolgreiche Login das Passwort nebst Login-Name per Mail direkt zu ihm nach Hause liefert. Das wären vielleicht 4 Zeilen Code zusätzlich...

 

[mambokurt]

PS: Nervt euch das auch, wenn man sich irgendwo registrieren möchte, und nur eine Maximale länge für ein Passwort eingeben darf? (Teilweise sogar nur 8 Zeichen)

Meine Bank erlaubt nur 5(!) Zeichen. Völlig hanebüchen. Wenn schon eine Beschränkung dann bei 50 Zeichen oder sowas. Letztendlich wird der Hash ja davon nicht länger, so what?

Ergänzung (29. Mai 2013)

Hallo,

@ Daaron,


Kurzes Beispiel:
Wenn ich eine Datenbank abfrage habe:

SELECT * FROM `tabelle` WHERE `password`='$passwort';

und ich habe ein schlecht gecodetes script, welches die übergebenen Werte nicht entkräftet,
dann kann ich in mein passwort, username usw. einfach folgendes eingeben:

''; DROP DATABASE `datenbank`;--

und schon lösche ich mit einer einzigen abfrage gleich die gesammte Datenbank.

Es gibt dort viele Methoden wie ich die Datenbank mittels eingaben vom User beeinflussen kann.
Und wenn ich als Programmierer so aus angst vor Hackern jede eingabe vom User entkräften lasse, aber bei der eingabe von Passwörtern die sonderzeichen als solche bestehen lasse, ist das höchst Fahrlässig, dann öffne ich ja Tor und Türe.

*hust*preparedstatements*hust*

Wenn du Userinput zu SQL Abfragen konkatenierst ist dir eh nicht mehr zu helfen, Sonderzeichen hin oder her . Davon ab wirst du aber kaum das Passwort im Klartext vergleichen, das heißt deine injection würde mit durch den Hash/Crypt laufen und wäre eh wirkungslos.