Frage:
Wie kann verhindert werden, dass Benutzername und Passwort übereinstimmen, wenn ein Benutzername geändert wird?
PwdRsch
2016-03-08 01:36:43 UTC
view on stackexchange narkive permalink

Angenommen, ich habe ein System, bei dem eine der Sicherheitsanforderungen darin besteht, Benutzer daran zu hindern, ein Kennwort zu wählen, das ihrem Benutzernamen entspricht. Benutzernamen unterscheiden nicht zwischen Groß- und Kleinschreibung, die Kennwörter jedoch. Die Kennwörter werden vom Server mithilfe einer sicheren Hashing-Funktion gespeichert, die nicht rückgängig gemacht werden kann.

Wenn das Konto erstellt wird, stehen dem Server zunächst sowohl der Benutzername als auch das Kennwort im Klartext zum Vergleich zur Verfügung. Wir können sie im Speicher vergleichen (ohne Berücksichtigung der Groß- und Kleinschreibung), um festzustellen, ob sie übereinstimmen, und den Benutzer anweisen, in diesem Fall ein anderes Kennwort zu wählen. Sobald diese Prüfung abgeschlossen ist, wird das Passwort sicher zur Speicherung gehasht, während der Benutzername im Klartext gespeichert wird. Hier gibt es keine Probleme, die die Anforderung erfüllen.

Wenn der Benutzer sein Kennwort ändern möchte oder es für ihn geändert wird, kann der Server seinen Benutzernamen-Datensatz abrufen und ihn mit dem neu ausgewählten Kennwortwert vergleichen (erneut ignorieren) case) um zu sehen, ob es passt. Auch hier gibt es keine Probleme, die Anforderungen zu erfüllen.

Das System erlaubt jedoch auch Änderungen des Benutzernamens. Während dieses ID-Änderungsprozesses hat der Benutzer dem Server nicht unbedingt sein Kennwort im Klartext mitgeteilt. Möglicherweise haben sie dies bei der Authentifizierung getan, aber der Server wird dieses Kennwort nicht im Klartext speichern, nur für den Fall, dass sie ihren Benutzernamen ändern möchten. Daher ist das Klartextkennwort nicht verfügbar, um nach einer Übereinstimmung mit dem neu ausgewählten Benutzernamen zu suchen.

Um unsere Anforderungen zu erfüllen, kann der Server dieselbe sichere Hashing-Funktion verwenden, um den neuen Benutzernamen zu hashen und mit dem aufgezeichneten Hash-Passwort zu vergleichen. Wenn sie übereinstimmen, kann der Server den Benutzer anweisen, einen anderen Benutzernamen zu wählen. Da der Benutzername jedoch nicht zwischen Groß- und Kleinschreibung unterscheidet, schlägt diese Prüfung möglicherweise fehl, wenn sie möglicherweise wahr ist. Wenn ich "PwdRsch1" als neuen Benutzernamen einreiche und mein Passwort "pwdrsch1" lautet, lässt das System dies zu, da die Hashes nicht übereinstimmen. Ich - oder schlimmer noch ein Angreifer - könnte mich später erfolgreich mit einem übereinstimmenden Benutzernamen und Passwort von "pwdrsch1" authentifizieren.

Wir könnten den Benutzernamen vor dem Hashing in Kleinbuchstaben zwingen und ihn mit dem Passwort vergleichen, aber dann ist das umgekehrte Szenario möglich. Der Benutzername würde als "pwdrsch1" gegen ein Passwort von "PwdRsch1" geprüft und erlaubt, da diese nicht übereinstimmen. Später kann ich mich jedoch erfolgreich mit einem übereinstimmenden Benutzernamen und Kennwort von "PwdRsch1" authentifizieren.

Welche vernünftigen Optionen habe ich, um das Risiko zu verringern, dass ein Kennwort mit einem Benutzernamen übereinstimmt, bei dem die Groß- und Kleinschreibung nicht berücksichtigt wird?

Abhängig vom Hash kann Brute Force möglich sein: Bei einem Benutzernamen mit "N" Buchstaben (ohne Zahlen) beträgt der Suchraum nur "2 ^ N".
Das Zulassen, dass Benutzer ihren Benutzernamen ändern, führt eindeutig zu Problemen bei der Kennwortverwaltung, und bei den meisten von mir verwendeten Systemen würde dies zu anderen Komplikationen führen. Ist das wirklich alles so wichtig? IME die beste Sicherheit kommt von der Einfachheit.
Separate Anzeige- und Anmeldenamen sind in Ordnung.
Wenn der Benutzername geändert wird, erzwingen Sie ein Zurücksetzen des Kennworts.
@DeerHunter Ich habe auch darüber nachgedacht, aber nicht, aber es in einer Antwort, weil es auch nicht erwünscht sein könnte (der Name wird schließlich aus einem Grund geändert). Beispielsweise möchte eine geschiedene Person möglicherweise nicht jedes Mal, wenn sie sich anmeldet, den Nachnamen ihres Ex eingeben. Wenn Sie also so etwas tun, sind bedeutungslose Anmelde-IDs besser (aber wahrscheinlich auch nicht erwünscht, da sie schwieriger zu verwenden sind merken).
Warum zeigen Sie nicht einfach einen roten Text mit der Aufschrift "Wenn Ihr Passwort auf Ihrem Benutzernamen basiert, besteht eine gute Chance, dass jemand es errät und Ihre Informationen stiehlt." Ich vermute, dass dies fast jeden Fall erledigen wird. Programmatisch erzwungene Kennwortkomplexität ohne Versuche, Benutzer zu schulen, ist diese seltsame, fortdauernde unproduktive Tradition. Dies ist einer von vielen Gründen, warum niemand grundlegende Techniken zum Schutz seiner Daten versteht und warum all diese Anforderungen und Überprüfungen überhaupt existieren.
@DeerHunter: das stimmt, aber wenn irgendetwas es schwieriger macht. Wenn das Konto einen separaten Anzeige- und Anmeldenamen hat und Sie diese Art von Maßnahme überhaupt implementieren, möchten Sie sicherstellen, dass das Kennwort mit keinem der beiden übereinstimmt. Selbst wenn sich der Anmeldename nicht ändern kann, bedeutet die Tatsache, dass sich der Anzeigename ändern kann, dass wir dieses Problem immer noch lösen müssen (oder je nach Fall fehlschlagen / ablehnen können).
Kommentare sind nicht für eine ausführliche Diskussion gedacht. Diese Konversation wurde [in den Chat verschoben] (http://chat.stackexchange.com/rooms/36752/discussion-on-question-by-pwdrsch-how-to-prevent-username-and-password-matches-w) .
@user19474 Wenn Sie dies tun, kann Ihr Passwort-Hashing-System viel schwächer sein, da ein Angreifer, der die Hashes erhält, zuerst die Version in Kleinbuchstaben angreifen kann (viel kleinerer Suchraum) und dann ihre Erfolge daraus ziehen und sie auf die Vollversionen der Hashes anwenden kann .
@PeterGreen, Ich verstehe Ihre Kritik nicht. Wenn jemand seine ID von jsmith in jjones ändert und gezwungen ist, ein neues Passwort auszuwählen, wie ist Klein- / Großbuchstaben relevant?
Wenn Sie der Meinung sind, dass ein Anmeldetoken eine Kombination aus Benutzername und Passwort ist. Dann ist jede Änderung des Benutzernamens oder des Passworts eine Änderung des Anmeldetokens. Und erfordert die Überprüfung IE durch ein ausgefülltes Login-Token -> den Benutzernamen + Passwort. Es fällt mir schwer, mir eine Welt vorzustellen, in der Benutzernamen und Passwörter nicht zusammenhängende Einheiten sind. Sie sind einfach ein öffentliches und privates Token, die zusammen Ihren Berechtigungsnachweis bilden.
Acht antworten:
tim
2016-03-08 01:45:53 UTC
view on stackexchange narkive permalink

Der einzig sinnvolle Weg, um das zu bekommen, was Sie wollen, besteht darin, nach dem Passwort zu fragen, wenn ein Benutzer seinen Benutzernamen ändert. Auf diese Weise verfügt der Server immer über die Informationen, die erforderlich sind, um während einer Änderung einen genauen Vergleich zwischen Benutzername und Kennwort durchzuführen und Übereinstimmungen zu verhindern.

Wie vertrauliche Vorgänge - wie das Ändern von Kennwörtern oder in Ihrem Fall Benutzernamen - sollten Benötigen Sie trotzdem ein Passwort (um den Schaden von XSS zu begrenzen), sollte dies kein Problem sein.

Ihre einzige andere Alternative besteht darin, jede mögliche Fallkombination auszuprobieren, sie zu hashen und mit dem gespeicherten Hash zu vergleichen wenn ein Benutzer seinen Benutzernamen ändert.

Ich bin damit einverstanden, dass die Eingabe des Kennworts die sinnvollste Lösung ist, wenn Benutzeränderungen am Benutzernamen vorgenommen werden. Bei einigen Systemen (z. B. Microsoft Active Directory) können Administratoren jedoch Benutzernamen ohne Beteiligung des Benutzers ändern. In diesen Situationen ist die Anforderung, dass ein Benutzer sein Kennwort angeben muss, nicht wirklich kompatibel. Ich vermute, dass Ihr anderer Vorschlag, alle Variationen zu hashen, die einzig praktikable Option ist, um die Anforderung zu erfüllen. Andernfalls müssen wir möglicherweise bereit sein, das Risiko zu berücksichtigen, dass ein vom Administrator geänderter Benutzername mit einem Kennwort übereinstimmt.
@PwdRsch Warum sollte ein Administrator Benutzernamen ohne Beteiligung des Benutzers ändern wollen? Ich kann mir keinen legitimen Anwendungsfall vorstellen.
Ich bin mir nicht sicher, ob das eine gute Idee ist. @emory. Wir müssten jemanden, der die Kryptographie hinter Passwort-Hashes wirklich versteht, diese Idee untersuchen und feststellen, dass das Speichern mehrerer Hashes ähnlicher Passwörter einem Angreifer nicht hilft, wenn er es schafft, beide Hashes zu stehlen. Meine allgemeine Meinung ist, dass das Speichern von Passwörtern komplex ist und es normalerweise am besten ist, sich an das Bewährte zu halten.
Ich möchte nicht implizieren, dass der Benutzer die Änderung des Benutzernamens nicht kennt, nur dass er die Änderung nicht selbst durchführen würde. Dies geschieht in Situationen, in denen jemand heiratet und seinen Nachnamen ändert. Dann wird sein Benutzername von den Mitarbeitern des Unternehmens entsprechend geändert.
@PwdRsch - Vielleicht können Sie bei jedem Login die Uname / Passwort-Prüfung durchführen? Oder beim ersten Login nach einer Änderung des Benutzernamens? Das heißt, wie wäre es, wenn Sie die Anforderungen in diesen Randfällen einfach nicht erfüllen? Sie scheinen es kaum wert zu sein, sich Sorgen zu machen.
@NeilSmithline Ich vermute, dass die meisten Systementwickler diese Fälle ignoriert haben, aber ich war daran interessiert, andere Ideen zu hören.
@emory bringt einen guten Punkt vor. Was tun Sie, wenn der Administrator den Benutzernamen ändert, wenn Ihre Richtlinie verletzt wird? Nur den Namen nicht ändern? Einen anderen - falschen - Namen verwenden? Das macht keinen Sinn. (Wenn der Benutzer es selbst ändert, kann eine Kennwortänderung erforderlich sein, aber es scheint nicht wünschenswert, den Administrator das Kennwort ändern zu lassen. Wenn dies der Fall wäre, könnten Sie einfach eine Kennwortänderung obligatorisch machen und kein Problem haben.)
@emory Ja, Sie können Zeichenanforderungen / -einschränkungen hinzufügen, um sicherzustellen, dass ein Benutzername niemals ein gültiger Kennwortwert sein kann oder umgekehrt. Fühlen Sie sich frei, dies als eine weitere Antwort auf diese Frage zu erweitern.
@tim Ich denke, Sie möchten in dieser Situation wahrscheinlich eine Kennwortänderung durch den Administrator erzwingen. Oder erzwingen Sie die Kontosperrung, wenn sich der Benutzer dann nicht mit seinem jetzt übereinstimmenden Benutzernamen / Passwort anmelden kann, bis er einen Validierungsprozess abgeschlossen und sein Passwort geändert hat. Aus Sicht des Benutzers definitiv nicht ideal, aber erzwungene Passwortänderungen sind selten.
@NeilSmithline Ich würde in Betracht ziehen, Ihre Optionen zur Überprüfung auf Übereinstimmungen während der Anmeldung oder nur nach einer Änderung des Benutzernamens als Antwort aufzuschreiben, da dies vernünftig erscheint und ich nicht möchte, dass es nur in den Kommentaren vergraben wird.
Wenn der Administrator den Benutzernamen ändert, können Sie ein Flag setzen, dass das Kennwort geändert werden muss. An den Benutzer wird ein Link gesendet, der die Änderung benachrichtigt. Wenn sich der Benutzer das nächste Mal anmeldet, muss das Kennwort geändert werden. In meinem Fall versuche ich immer, die Verwendung von Paraphrasen zu erzwingen, die viel länger als Benutzernamen sind. Noch besser, lassen Sie das Passwort fallen und verwenden Sie stattdessen Schlüssel.
@lepe In einem solchen Fall, wenn die Datenbank durchgesickert ist, könnte man einfach nach dem Vorhandensein eines solchen Flags suchen und es gibt eine hohe Wahrscheinlichkeit, dass sich das Passwort im Feld Benutzername im Klartext befindet
@emory Ein Administrator möchte möglicherweise einen Benutzernamen für jemanden ändern, wenn sich sein Name ändert. Das einfachste Beispiel ist, wenn der Benutzername beispielsweise aus dem Nachnamen und der ersten Initiale besteht. Dies kann sich ändern, wenn eine Person heiratet und daher in einem System geändert werden muss. Ein normaler Benutzer kann dann möglicherweise sein Passwort nicht ändern. In ähnlicher Weise müssen Administratoren möglicherweise eine Reihe von Anfragen bearbeiten, sodass es möglicherweise nicht praktikabel ist, sie zum Zeitpunkt der Änderung des Benutzernamens dort zu haben, um ihr Kennwort einzugeben.
Stimmt mit @tim und emory überein: Es gibt keinen legitimen und - eigentlich - vernünftigen Grund dafür, dass "kein Benutzer selbst" den Benutzernamen und das Passwort des Kontos ändert. Wenn eine * legitime * Passwortänderung auftritt, können Sie nach einem alten und einem neuen Pass fragen. Wenn auch ein Benutzername geändert werden soll - OK, fordern Sie ein neues an, dasselbe Passanforderungsformular, nur eine zusätzliche Zeile.
@gabe3886: Genauer gesagt, es gibt keinen Grund, warum der Administrator das Kennwort des Benutzers kennen muss. Lassen Sie das System einfach bei jedem Anmeldeversuch überprüfen, ob der Benutzername und das Kennwort übereinstimmen und ob das Kennwort sehr bald abläuft (dem Benutzer ein Heads-up zu geben, dass die Auswahl eines neuen Kennworts wahrscheinlich besser ist als das Setzen sie an Ort und Stelle).
@Dezza ja, aber normalerweise verbietet ein solches Flag Benutzern die Protokollierung, unabhängig vom Passwort
@Dezza Ich verstehe Ihren Standpunkt. Warum denkst du, ist von "hoher" Chance? Ich denke, es besteht eine "geringe" Wahrscheinlichkeit, dass der neue Benutzername mit dem vorherigen Passwort übereinstimmt. Wie wäre es damit: Wenn der Benutzername geändert wird, wird das Passwort auf ein zufälliges (temporäres) Passwort gesetzt, das vom Benutzer beim Klicken auf den Link geändert wird. Zusätzlich zu den vielen Alternativen zum Überprüfen des Benutzerlinks können Sie den alten Passwort-Hash als Parameter in den Link aufnehmen. Auf diese Weise können Sie nach dem alten Kennwort fragen, um das neue festzulegen, ohne den alten Hash in der Datenbank zu belassen. Wie kw4nta sagte, kann sich der Benutzer nicht anmelden, wenn das Flag aktiviert ist.
Jason
2016-03-08 20:06:21 UTC
view on stackexchange narkive permalink

Ein wenig gegen den Strich gehen - ist es egal, ob der Benutzername in eine "im Wesentlichen ähnliche" Zeichenfolge wie das Kennwort geändert wird. Warnen Sie Benutzer vor der Gefahr, dasselbe Kennwort auszuwählen, und prüfen Sie, ob identisch übereinstimmen.

Unabhängig davon, wie viele Regeln Sie eingerichtet haben, werden sie gefunden, wenn der Benutzer bestimmt ist ein Weg um sie herum. Wenn Sie müssen, geben Sie bei der Änderung des Benutzernamens die Eingabe des Kennworts ein, damit Sie sie in dasselbe Gehäuse zwingen können, oder lassen Sie es einfach durch und überprüfen Sie, wann sie sich das nächste Mal anmelden, und erzwingen Sie dann eine Benutzer- / Passänderung.

Das einzige Mal, wenn dies von Bedeutung ist, ist, wenn Ihre Benutzer einem gezielten Angriff ausgesetzt sind. Wenn ein zufälliges Skriptkind (oder ein anderer Opportunist) die Benutzerliste in den Griff bekommt, verfügt es über weitaus ausgefeiltere Tools, um diese Kennwörter zu knacken, als zu versuchen, mit dem Benutzernamen übereinzustimmen. Dies gilt auch für den Zielangreifer, aber er kann mit einfachen Dingen beginnen, die er selbst in die Tastatur eingeben kann. Und wenn es sich um eine intelligente Person handelt, die versucht, das Passwort "PwdRsch1" zu knacken, sind Sie dann wirklich sicher, wenn Sie nur die Unterschiede zwischen den Fällen überprüfen? Was ist mit "pwdr5ch1"? "PwdRsch2"? "1hcsRdwP"? Sie können Regeln für jedes dieser denkbaren Szenarien schreiben, aber entweder gibt es eines, das Sie vergessen haben, oder Sie machen es so schwierig, eine Kombination aus Benutzername und Passwort auszuwählen, dass sie nur mit "P4ssw0rd!" und damit fertig sein.

Bildung ist die einzige Möglichkeit, Ihre Benutzer dazu zu bringen, wirklich sichere Passwörter zu verwenden, und es wird immer solche geben, die diese nicht erfüllen.

Ich bin damit einverstanden, dass ein entschlossener Benutzer trotz der Richtlinienregeln oder anderer Steuerelemente, die wir verwenden, um schlechte Entscheidungen zu verhindern, ein schwächeres Kennwort wählen kann, als wir möchten. Ich habe jedoch nicht das Gefühl, dass diese Anforderung (wie angegeben) die Dinge zu weit führt. Kombinieren Sie diese technische Kontrolle mit der von Ihnen vorgeschlagenen Ausbildung, und hoffentlich erhalten wir die Sicherheitsvorteile beider. Nur weil die meisten Angreifer über ein Kennwort hinaus raten, das mit dem Benutzernamen übereinstimmt, heißt das nicht, dass wir nicht versuchen sollten, diese Regel durchzusetzen. Wir müssen noch die niedrig hängenden Früchte beseitigen.
@PwdRsch Ich bin nicht anderer Meinung. Mein Punkt ist vermutlich, dass Sie nicht verbergen müssen, was Sie vor dem Benutzer tun. Sie müssen ausdrücklich ihr Kennwort eingeben, wenn Sie einen Namen ändern oder dasselbe ausführen Wenn Sie sich das nächste Mal anmelden, nachdem ein Administrator seinen Namen geändert hat, wird die Ausbildung tatsächlich verbessert, da dies einen Grund zur Aufmerksamkeit gibt. Das heißt, wenn ein Administrator im Wesentlichen * versehentlich * das Passwort eines Benutzers erraten kann, wenn er seinen Benutzernamen auswählt, dann ist dies ein Grund, die Ausbildung * trotzdem * auf den Benutzer zu verlagern, da dies ein schrecklich gewähltes Passwort war.
PyRulez
2016-03-08 10:09:02 UTC
view on stackexchange narkive permalink

Angenommen, der Benutzername enthält 10 Buchstaben. Das sind 1024 verschiedene Kombinationen von Groß- und Kleinschreibung. Überprüfen Sie sie alle.

Speichern Sie den Passwort-Hash in Kleinbuchstaben nicht. Dieser 1024 mag Ihnen unpraktisch erscheinen, aber für einen Angreifer ist es der Unterschied zwischen einem Tag und drei Jahren.

Je nach Hashing und Hardware kann dies etwa eine Minute dauern. Wenn ein Administrator den Benutzernamen ändert, der möglicherweise in Ordnung ist (wenn deutlich angezeigt wird, dass dies ein langsamer Prozess ist), ist eine Minute möglicherweise nicht akzeptabel, wenn ein Benutzer ihn ändert. Dies kann zu Problemen führen, z. B. wenn Benutzer Formulare erneut einreichen und dann nicht wissen, mit welchem ​​Benutzernamen sie gelandet sind, oder wenn Benutzer das Fenster schließen, bevor sie die Meldung erhalten, dass ihr neuer Benutzername nicht akzeptabel ist.
@tim Es muss langsam sein. Andernfalls könnte ein Angreifer, der den Server übernimmt oder über ein Replikat des Servers verfügt, einfach weiter versuchen, den Benutzernamen zu ändern, bis er das Kennwort herausgefunden hat (in der Praxis könnten sie etwas viel Besseres als den Server machen). Sie können jedoch Geschwindigkeit gegen Speicherplatz eintauschen: https://en.wikipedia.org/wiki/Scrypt
Wenn * Sie * (vermutlich ein nicht sachkundiger Passwort-Cracker) dies brutal erzwingen können, kann ein Angreifer das Gleiche viel, viel schneller tun. Wenn Sie ein erfahrener Passwort-Cracker sind, wissen Sie bereits, wie sinnlos Ihre Arbeit ist.
@Jason Sie müssen das Passwort nicht kennen, stellen Sie nur sicher, dass der Benutzername nicht das Passwort ist.
emory
2016-03-08 02:50:56 UTC
view on stackexchange narkive permalink

Sie sollten Benutzer-IDs und Kennwörter zwingen, aus verschiedenen Gruppen zu stammen. In den Kommentaren scheint es, dass die Benutzer-ID aus dem legalen Namen des Benutzers in einer formelhaften Weise "John Smith" -> "jsmith" und "Jane Doe" -> "jdoe" folgen muss. Wenn Jane dann John heiratet und seinen Namen annimmt, muss sich ihre Benutzer-ID in "jsmith2" ändern.

Sie können also festlegen, dass das erste Zeichen in einem Kennwort ein Symbol sein muss oder dass das Kennwort enthalten muss ein Symbol.

Wenn Benutzer-IDs auf 8 Zeichen gekürzt werden, müssen Kennwörter mindestens 9 Zeichen enthalten.

Sie können das kartesische Produkt einer Liste mit Nachnamen und einer Liste von verwenden Vornamen und verwenden Sie diese als schwarze Liste für Passwörter. Wenn ein Mitarbeiter einen Namen hat, der nicht auf Ihrer Liste steht, fügen Sie ihn hinzu. Wenn Benutzer Kennwörter ändern, wird sich das Problem von selbst beheben.

Brenda Utthead hätte einen färbbaren Einwand gegen Ihre vorgeschlagene Richtlinie, insbesondere wenn Benutzernamen in der öffentlichen Kommunikation verwendet werden.
@DamianYerrick Um es klar auszudrücken, ist es meines Erachtens eine strikte Anforderung, dass Benutzer-IDs formelhaft von legalen Namen abgeleitet werden und nicht mit Passwörtern übereinstimmen. Ich denke, Benutzer sollten in der Lage sein, ihre eigene Benutzer-ID auszuwählen, die nicht ihrem legalen Namen entsprechen muss. Brendas Einwand hat mehr mit den Anforderungen von OP zu tun als mit meiner Politik.
@DamianYerrick in Kommentaren sagte das OP, wenn Brenda Smith (Benutzer-ID-Schmied, Passwort-Butthead) Rick Utthead (Benutzer-ID-Rutthead) heiratete und Uttheads Namen nahm, müsste der Administrator Brendas Benutzer-ID in Butthead ändern, aber das wäre ein Problem, weil sie jetzt Benutzer-ID und Passwort sind identisch.
@DamianYerrick, aber wenn Sie glauben, dass die mit dem Passwort übereinstimmende Benutzer-ID nicht das große Problem in Brendas Szenario ist, muss ich zustimmen.
@DamianYerrick Cisco Systems hat das tatsächlich getan und schien mit ihren Mitarbeiternamen spektakulär Pech zu haben, ähnlich wie Chris Rapherty, Simon Hitchin und so weiter. Ich glaube, sie haben auch ihre Benutzernamen auf 8 Buchstaben gekürzt. Viel Vergnügen (außerhalb von Cisco) folgte.
Dewi Morgan
2016-03-08 23:14:19 UTC
view on stackexchange narkive permalink

Dies ist keine Antwort, ich erwähne sie nur, damit die Leute dies nicht tun .

Sie könnten entscheiden, dass es sinnvoll wäre, in zu speichern Zusätzlich zum regulären Hash ihres Kennworts, bei dem zwischen Groß- und Kleinschreibung unterschieden wird, wird ein Hash ihres Kennworts in Kleinbuchstaben umgewandelt.

Dies würde Ihr Problem sicherlich lösen - Sie müssen nur den Benutzernamen, in den Sie ändern, in Kleinbuchstaben und Vergleichen Sie es mit diesem gespeicherten Hash des Passworts in Kleinbuchstaben.

Der offensichtliche Nachteil ist, dass dies den Zweck eines Hash-Passworts teilweise zunichte macht: Angriffe auf Ihre Passwortliste viel schwieriger zu machen. Ein Angreifer, der Zugriff auf Ihre Hash-Passwortlisten erhält, kann den weitaus schwächeren (2 ^ n-mal schwächeren) Kleinbuchstaben-Hash anstelle des Groß- und Kleinschreibung-Hash angreifen.

Also die anderen genannten Optionen (nachfragen) Das Passwort zum Zeitpunkt der Änderung (das Ausprobieren aller Fallpermutationen, wenn ein Administrator es ändert, idealerweise zuerst in der wahrscheinlichsten Reihenfolge) scheint weitaus bessere Wetten zu sein.

Dies war eine der ersten Antworten, die als scheinbar gute Option angeboten wurden und die das Poster später löschte, sobald sich die Leute mit den von Ihnen aufgelisteten Warnungen einmischten. ;) Ich stimme zu, dass die Kompromisse bei der Sicherheit dies nicht wirklich lohnenswert machen.
@PwdRsch Oh, danke - ich habe es nicht bemerkt. Diese Antwort wäre ausnahmsweise in Ordnung, wenn ich unkommentierte Abstimmungen bekommen würde :)
@DewiMorgan Sie könnten es CW machen ... auf diese Weise würden Sie nicht die Wiederholung für die Downvotes verlieren.
Ooh, danke, @wizzwizz4, Das wusste ich nicht. Erledigt! Fühlt sich irgendwie ... frech und ausbeuterisch an :(
YLearn
2016-03-09 04:35:40 UTC
view on stackexchange narkive permalink

Einige gute Antworten, aber hier ist eine alternative Möglichkeit, dieses Problem anzugehen. Anstatt zu versuchen, den neuen Benutzernamen mit dem vorhandenen Kennwort zu vergleichen, können Sie einfach eine Kennwortänderung erzwingen, wenn ein Benutzer seinen Benutzernamen ändert.

Natürlich möchten Sie Benutzer warnen, dass das Ändern des Benutzernamens das Ändern des Benutzernamens erfordert Sie können dann problemlos den bereits vorhandenen Prozess verwenden, um neue Kennwörter mit Benutzernamen zu vergleichen.

Omar Kooheji
2016-03-10 00:22:36 UTC
view on stackexchange narkive permalink

Obwohl die sinnvollste Lösung bereits erwähnt und akzeptiert wurde, nämlich nach dem Kennwort bei der Änderung des Benutzernamens zu fragen, sollten Sie dies trotzdem tun. Eine Alternative besteht darin, auch den Hash des Passworts in Kleinbuchstaben (mit einem anderen Salt?) Zu speichern und den Benutzernamen in Kleinbuchstaben damit zu vergleichen.

NH.
2017-10-24 00:56:17 UTC
view on stackexchange narkive permalink

Die einzige Möglichkeit, Benutzer daran zu hindern, dumme Passwörter auszuwählen, besteht darin, Richtlinien für die Generierung von Passwörtern zu erzwingen (im Gegensatz zu den leider üblichen Richtlinien für das Format des Passworts) p> Wenn Sie nicht so viel Autorität über Ihre Benutzer haben (die meisten Websites haben dies nicht), sollten Sie sie zumindest anweisen, ihre Passwörter mit einem Passwortmanager zu generieren (und ihr Hauptpasswort mit Würfeln ), und Sie können es möglicherweise schwierig machen, diese Richtlinie zu missachten:

Eine Möglichkeit, dies zu tun, besteht darin, dass Ihr Kennwortfeld keine Tastatureingaben akzeptiert, sondern nur Daten oder Computer einfügt -typisierte Daten (ich empfehle, die Geschwindigkeit zu überprüfen, mit der Zeichen eingegeben werden). Dann können Sie das Feld, in dem die Kennwortrichtlinie erläutert wird, rot umreißen oder etwas, um die Aufmerksamkeit darauf zu lenken.



ⓘ
Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...