Perl: Sonderzeichen in Passwörtern
0 0 
MudGuard
0 
dedlfix
0 
Gunnar Bittersmann
1 0 
Auge
2
Perl: Sonderzeichen in Passwörtern
Hallo,
aktuell schließe ich in meinem Projekt Sonderzeichen in Passwörtern aus.
Würde diese aber gern zulassen, nun kann ich aber nicht überschauen, ob es dadurch zu Problemen beim Speichern des des Passworthashes kommen kann.
Und macht es Sinn, Umlaute auszuschließen, da der Nutzer, wenn er an einem Gerät im Ausland sitzt, ja dann diese gar nicht eingeben kann?
Hat da jemand Erfahrungen bzw. wie setzt ihr die Problematik um?
Danke Jan
-
aktuell schließe ich in meinem Projekt Sonderzeichen in Passwörtern aus.
Wie kommunizierst du das?
Und macht es Sinn, Umlaute auszuschließen, da der Nutzer, wenn er an einem Gerät im Ausland sitzt, ja dann diese gar nicht eingeben kann?
Hat da jemand Erfahrungen bzw. wie setzt ihr die Problematik um?
ich kann UTF8 empfangen, speichern, ausgeben. Und hatte für mich ein Passwort gewählt, das äöüß enthält. Mit deutscher Tastatur kein Problem, aber auf einem dusseligen Smartphone nicht eingebbar. Ich - gottseidank Administrator - konnte das Passwort per Laptop ändern.
Du könntest die Zeichen des Passwortes erklären [A..Z],[a..z],[0..9] und bei jedem Tastendruck per Javasript einzeln prüfen.
Aber irgendwann kommt ein Zombie von 1960 daher und kann keine Kleinbuchstaben eingeben.
Restrisiko bleibt.
Linuchs
-
Hi,
aktuell schließe ich in meinem Projekt Sonderzeichen in Passwörtern aus.
Was ist denn nach Deiner Definition ein Sonderzeichen?
Und macht es Sinn, Umlaute auszuschließen, da der Nutzer, wenn er an einem Gerät im Ausland sitzt, ja dann diese gar nicht eingeben kann?
Es gibt z.B. unter Windows die Character Map. Damit kann man auch ohne die passende Taste Umlaute eingeben.
cu,
Andreas a/k/a MudGuard -
Tach!
aktuell schließe ich in meinem Projekt Sonderzeichen in Passwörtern aus.
Würde diese aber gern zulassen, nun kann ich aber nicht überschauen, ob es dadurch zu Problemen beim Speichern des des Passworthashes kommen kann.
Spezielle Perl-Fragen kann ich nicht beantworten. Aber das Grundprinzip ist überall gleich. Was verarbeitet ein Hash? Sind es Zeichen oder sind es Bytes? Es ist eine mathematische Operation, also Zahlenwerte, also Bytes. Das heißt, solange die Bytes/Zahlenwerte dieselben sind, kommt beim Hash auch dasselbe Ergebnis raus. Deine Sorge sollte also sein, dass die eingegebenen Zeichen stets mit denselben Bytes kodiert werden. Ein ä beispielsweise darf nicht einmal ISO-8859-1-kodiert daherkommen und ein anderes Mal UTF-8-kodiert. Das wären unterschiedliche Bytes und damit unterschiedliche Hash-Werte.
Und macht es Sinn, Umlaute auszuschließen, da der Nutzer, wenn er an einem Gerät im Ausland sitzt, ja dann diese gar nicht eingeben kann?
Diese Frage musst du für dein Projekt beantworten. Muss der Nutzer unter allen Umständen sein Passwort eingeben können? Dann fallen eine ganze Menge Zeichen weg, nicht nur Umlaute. Ob sie ausgeschlossen werden müssen oder nur ein Hinweis auf die Problematik angezeigt wird oder der Nutzer es selbst wissen/merken muss, ist deine Entscheidung.
dedlfix.
-
@@JanW2
Und macht es Sinn, Umlaute auszuschließen
Nein.
Irgendwelche Beschränkungen, wie ein Passwort laut Meinung eines unwissenden Produktmanagers/-entwicklers auszusehen hätte, führen dazu, dass Nutzer Passwörter wählen müssen, die sie sich nicht merken können. Oder dass dann zu einfache Passwörter gewählt werden oder für verschiedene Zugänge dasselbe.
Alle Zeichen zulassen! Keine Zeichen verlangen!
da der Nutzer, wenn er an einem Gerät im Ausland sitzt, ja dann diese gar nicht eingeben kann?
Ich habe in letzter Zeit (heißt in den letzten 20 Jahren) kein Gerät gesehen, wo man nicht die Tastatur umstellen könnte.
LLAP 🖖
--
“When UX doesn’t consider all users, shouldn’t it be known as ‘Some User Experience’ or... SUX? #a11y” —Billy Gregory -
Ok, vielen Dank für die Antworten.
Aktuell bedeutet "keine Sonderzeichen", dass nur die Zeichen a-zA-Z0-9 zugelassen sind.
Ich werde einfach mal testweise probieren, was passiert, wenn ich alle Zeichen zulasse.
Eine Frage habe ich noch, da ich mich noch einmal in das Thema "sichere Passwörter" eingelesen habe.
Aktuell sind meine Passwörter "gesalzen" und gehasht abgespeichert. Ich weiß, dass das Salt wichtig ist, aber versuche mir klarzumachen, warum dem so ist.
Lese ich dazu Texte, steht als Hauptgrund, dass es bei gesalzenen Passwörtern keinen Sinn macht, Rainbow-Tables vorauszuberechnen.
Aber wenn man annimmt, die Nutzertabelle gelangt in falsche Hände, so hat derjenige ja die Salts im Klartext vorliegen und kann ja dann die Rainbow-Tabellen berechnen.
Warum ist das ein so großer Gewinn an Sicherheit, nur weil man die Tabellen nicht vorausberechnen kann?
Danke!
-
Hallo
Lese ich dazu Texte, steht als Hauptgrund, dass es bei gesalzenen Passwörtern keinen Sinn macht, Rainbow-Tables vorauszuberechnen.
Das stimmt soweit. Ein ungesalzener Wert ergibt mit einer Methode immer wieder einen voraussagbaren Hash. Mit Salz muss die Rekonstruktion eines Wertes jeweils von vorn beginnen. Zudem ergibt der selbe Ausgangswert mit verschiedenen Salzen unterschiedliche Hashes.
Aber wenn man annimmt, die Nutzertabelle gelangt in falsche Hände, so hat derjenige ja die Salts im Klartext vorliegen und kann ja dann die Rainbow-Tabellen berechnen.
Das stimmt, aber der Angreifer muss die Berechnung halt für jeden Ausgangswert einzeln durchführen. Mit hinreichend modernen Hashing-Methoden kann das schon einmal Monate oder Jahre an Prozessorzeit in Anspruch nehmen.
Warum ist das ein so großer Gewinn an Sicherheit, nur weil man die Tabellen nicht vorausberechnen kann?
Der Gewinn besteht in der Zeit, die zur Berechnung des Ausgangswerts des Hashes notwendig ist.
Tschö, Auge
--
Wenn man ausreichende Vorsichtsmaßnahmen trifft, muss man keine Vorsichtsmaßnahmen mehr treffen.
Toller Dampf voraus von Terry Pratchett -
Hallo JanW2,
Eine Frage habe ich noch, da ich mich noch einmal in das Thema "sichere Passwörter" eingelesen habe.
Aktuell sind meine Passwörter "gesalzen" und gehasht abgespeichert.
Das ist gut, aber noch nicht das Optimum. Heutzutage werden Passwörter eigentlich nicht mehr mit den klassischen Hashing-Funktionen wie MD5, dem alten Crypt oder SHA1 oder so gehasht, sondern man verwendet Algorithmen wie PBKDF2, Bcrypt oder Scrypt. PBKDF2 und Bcrypt sind dabei Platzhirsche, die in der überwiegenden Anzahl der Fälle genutzt werden. Perl bietet da auch Module zu an. Du solltest, wenn möglich, darauf umsteigen.
Die Verwendung kryptologischer Hash-Funktionen ist nicht mehr zeitgemäß, diese Algorithmen sind unter anderem darauf ausgelegt, möglichst schnell einen Hash zu erzeugen. Heutzutage kann sich aber jeder Depp einen Cluster von 1000 Computern mieten, mit dicken Grafikkarten, und dort die Passwörter mit JohnTheRipper auf der Grafikkarte brute-forcen. Die Zielsetzung beim hashen von Passwörtern muss also sein, möglichst viel Rechenzeit für einen Hash-Vorgang zu verbrauchen, um Brute-force-Angriffe teurer zu machen.
Ich weiß, dass das Salt wichtig ist, aber versuche mir klarzumachen, warum dem so ist.
Die Sicherheit eines Passwort-Hashes wird definiert durch die mittlere Zeit, die benötigt wird, um den zu dem Hash gehörigen Klartext zu errechnen oder zu erraten. Wenn ich jetzt eine Rainbow-Table habe (die gibt es fertig zum Download in diversen mal mehr, mal weniger zwielichtigen Portalen), bei der bereits alle möglichen Kombinationen drin sind, die ich mit dem Hashing-Verfahren erreichen kann, dann ist es eine Frage von Milli- oder sogar Microsekunden, ein Passwort zu brechen. Setze ich einen Hash dazu, verändere ich die Ausgangslage: es ist nicht mehr möglich, eine Rainbow Table voraus zu berechnen.
LG,
CK-
Danke für die ausführlichen Infos!
Zwei Sachen:
- Umsteigen auf ein modernes Hashverfahren, gerne. Funktioniert aber eigentlich nur auf folgendem Weg, oder? Nutzer loggt sich ein. Ich prüfe ob das gehashte Passwort nach altem oder neuen (neue Spalte in der Nutzertabelle) Hashverfahren vorliegt. Wenn Passworthash noch in der Spalte "alter Hash" vorliegt, dann authentifiziere ich den Nutzer nach dem alten Hashverfahren und bei gültigem Login hashe ich das eingegebe Klartextpasswort nach neuem Hashverfahren und speichere es dann in der Spalte "neuer Hash" ab. Den alten Hash kann ich dann ja prinzipiell löschen.
Zu deinem
es ist nicht mehr möglich, eine Rainbow Table voraus zu berechnen.
Ist es nicht egal, ob die Rainbow Table vorausberechnet wird? Wenn ein Angreifer eh die Daten hat, dann kann er das Klartext-Salt ja dazu verwenden, einfach eine neue Rainbow-Tabelle zu berechnen? Einzig was ich nicht abzuschätzen weiß: Wie lange das Berechnen einer solchen Tabelle dauert.
"Auge" schreibt in seinem Post ja
Mit hinreichend modernen Hashing-Methoden kann das schon einmal Monate oder Jahre an Prozessorzeit in Anspruch nehmen.
Gut, das ist ein Argument.
Und was ich bisher übersehen habe und wirklich ein wichtiger Punkt ist: Wenn "Auge" schreibt
Zudem ergibt der selbe Ausgangswert mit verschiedenen Salzen unterschiedliche Hashes.
Vielen Dank euch beiden!
-
Hallo JanW2,
- Umsteigen auf ein modernes Hashverfahren, gerne. Funktioniert aber eigentlich nur auf folgendem Weg, oder? Nutzer loggt sich ein. Ich prüfe ob das gehashte Passwort nach altem oder neuen (neue Spalte in der Nutzertabelle) Hashverfahren vorliegt. Wenn Passworthash noch in der Spalte "alter Hash" vorliegt, dann authentifiziere ich den Nutzer nach dem alten Hashverfahren und bei gültigem Login hashe ich das eingegebe Klartextpasswort nach neuem Hashverfahren und speichere es dann in der Spalte "neuer Hash" ab.
Das ist ein mögliches Verfahren, ja. Ich würde allerdings lieber eine Spalte „Hash-Version“ einfügen und bei veraltetem Hash-Verfahren die Spalte mit dem Passwort-Hash sowie die Versions-Spalte upzudaten. So hast du die Möglichkeit später das Hash-Verfahren ohne Änderung am Mechanismus und Datenmodell erneut zu ändern.
Den alten Hash kann ich dann ja prinzipiell löschen.
Den kannst du nicht nur prinzipiell löschen, den solltest du unbedingt löschen bzw überschreiben.
Zu deinem
es ist nicht mehr möglich, eine Rainbow Table voraus zu berechnen.
Ist es nicht egal, ob die Rainbow Table vorausberechnet wird? Wenn ein Angreifer eh die Daten hat, dann kann er das Klartext-Salt ja dazu verwenden, einfach eine neue Rainbow-Tabelle zu berechnen?
Klar, aber das kostet Plattenplatz und dauert Zeit. Und er muss das bei jedem Passwort neu machen, denn der Hash ist ja bei jedem Passwort anders. Dadurch werden Brute-Force-Angriffe über Rainbow-Tables einfach unattraktiv weil zu teuer. Da nutzt man dann lieber Wörterbuch-Attacken oder sowas.
LG,
CK
-
-