Siehst du das Ding dort oben, wo dein Benutzername angezeigt wird? Sie können das nicht tun, wenn der Benutzername jetzt gehasht gespeichert ist, oder?

Ein Wort, Benutzerfreundlichkeit.

Während das, was Terry sagt, wahr ist, haben Anmeldesysteme manchmal tatsächlich den Benutzernamen (aber ohne Salz). Sie müssen einen Anmeldenamen und einen Anzeigenamen auswählen. Der Anmeldename wird gehasht gespeichert (ohne Salt, da Sie ihn nachschlagen müssen müssen) und das Kennwort wird gesalzen. Der Anzeigename unterscheidet sich von Ihrem Anmeldenamen (da dieser ebenfalls geheim gehalten werden sollte) und wird bei Bedarf angezeigt.

Selbst wenn ein Angreifer Ihren Namen sieht, kann er ihn nicht an Ihren Anmeldenamen anhängen Name. Während ich sage, dass es gesalzen werden kann, besteht eigentlich keine Notwendigkeit dafür. Das Wichtigste ist nur, es geheim zu halten. Wenn die Datenbank kompromittiert wird, kann der Angreifer weiterhin Informationen wie Ihre E-Mail-Adresse oder Ihren Namen verwenden, wenn er neue Angriffe auf Ihre anderen Konten durchführen möchte.

Im Allgemeinen gelten Benutzernamen nicht als sicher, sondern als Identität und nicht als Authentifizierung. Es ist gut, nicht preiszugeben, welche Benutzernamen gültig sind, aber es wäre schlimmer, wenn Sie zufällig eine Kollision hätten. Sie können dies immer noch umgehen, indem Sie alle übereinstimmenden Benutzernamen nach einem passenden Kennwort-Hash durchsuchen, aber das ist etwas chaotisch.

Wenn Sie ansonsten eine gute Kennwortsicherheit und Einschränkungen bei Anmeldeversuchen haben, eine vollständige Liste von Benutzernamen bietet einem Angreifer wenig praktischen Wert. Der Hauptvorteil wäre Phishing, aber wenn Ihre offizielle Korrespondenz Informationen enthält, können diese Informationen nicht gehasht werden und sie würden sie erhalten, wenn sie Ihre Datenbank trotzdem kompromittieren würden.

Auch die Benutzerfreundlichkeit mag Sagte Terry. Es ist viel einfacher, Ihr Konto zu finden, wenn sie Benutzernamen sehen können. Sie gewinnen nicht genug, wenn Sie versuchen, eine Kennung zu sichern, um sie in den meisten Kontexten zu rechtfertigen.

Während andere gut darauf hingewiesen haben, dass es nur wenige (wenn überhaupt) Vorteile gibt, würde ich Ihre Behauptung in Frage stellen, dass es keine Nachteile gibt. Wenn Sie nur den Hash-Benutzernamen speichern, ist die Suche nach dem Benutzernamen einfach. Wenn Sie einen gesalzenen, gehashten Benutzernamen speichern, wird die Suche etwas problematischer.

Nehmen wir an, wir erstellen eine SQL-Tabelle mit Benutzernamen und (gehashten) Kennwörtern und weisen den SQL Server an, die Spalte mit dem Benutzernamen zu indizieren es wird eine Art binäre Suche oder eine andere Magie durchführen. Wir könnten eine Tabelle haben, die so aussieht:

  Benutzername | Passworttest | j9lnvqjAuhNJs  

(Dies ist der Unix-Krypta-Hash der alten Schule (3), nur zur Vereinfachung und Kürze.)

Wenn Sie Ihre Benutzernamen im Klartext speichern, rufen Sie den ( Das Hash-Passwort für einen Benutzer ist ein einfacher SQL-Aufruf. Angenommen, Sie möchten die Anmeldeinformationen für einen Benutzer überprüfen, der den Benutzernamen test :

  eingegeben hat. Wählen Sie das Kennwort von Benutzern aus, bei denen Benutzername = 'test';  

Einfach genug. Wenn wir nun die Benutzernamen im gleichen Format wie die Passwörter speichern, sieht unsere Tabelle folgendermaßen aus:

  Benutzername | PasswortM1CAtvzDdJDGU | j9lnvqjAuhNJs  

Wenn ein Benutzer nun seinen Benutzernamen test eingibt, wie überprüfen Sie das Kennwort? Eine binäre Suche ist hier nutzlos, da Sie nicht einmal das Salz kennen, mit dem Sie den Benutzernamen gespeichert haben. Stattdessen müssen Sie jeden Benutzernamen in der Datenbank durchlaufen, den angegebenen Benutzernamen mit dem Salt für diesen Benutzernamen verschlüsseln und ihn mit dem gespeicherten (gehashten) Benutzernamen vergleichen, um festzustellen, ob er übereinstimmt. Youch!

Angenommen, Sie haben einige gute Vorsichtsmaßnahmen getroffen und einen schönen langsamen Hash wie bcrypt anstelle einer guten alten Unix-Krypta verwendet? Double Youch!

Wie Sie sich vorstellen können, hat das Speichern eines gesalzenen Hash-Benutzernamens anstelle von einfachem Text einige schwerwiegende Nachteile.

Wenn Sie den Benutzernamen gehasht und gesalzen haben, wie würde das System wissen, dass neue Konten einen eindeutigen Benutzernamen haben, ohne alle vorhandenen Datensätze zu durchlaufen und den neuen Benutzernamen mit jedem einzelnen vorhandenen Salt zu hashen?

Ihre Idee ist edel und die Frage interessant. Nun, ich glaube, Sie haben entweder überhaupt nicht an Benutzerfreundlichkeit gedacht, als Sie die Frage angesprochen haben, oder Sie haben den Punkt des Hashing verpasst (oder vielleicht Sie nur falsch geschrieben 'Verschlüsselung').

Hashing ist irreversibel, es sei denn, Sie haben Supercomputer, die Dinge brutal erzwingen, oder Regenbogentabellen, um nach Hashes zu suchen. Daher würde die Benutzerfreundlichkeit nach unten gehen, wenn Sie die für Anmeldungen verwendeten Benutzernamen / E-Mails hashen würden. Wenn man jedoch dasselbe mit einem vordefinierten Schlüssel im Programm (der den Benutzernamen überprüft) selbst "verschlüsselt", ist dies möglicherweise etwas sicher. Aber noch einmal - ein direkt in einem Programm gespeicherter Verschlüsselungsschlüssel ist genauso gut wie gar kein Schlüssel. Dies sind die Hauptgründe, warum Benutzernamen nicht gehasht oder verschlüsselt werden.

Ich denke, der wahrscheinlichste Grund ist, dass das Hashing der Benutzernamen zusammen mit dem Passwort keinen zusätzlichen Schutz bietet.

Wir empfehlen Benutzern, schwierige und komplexe Passwörter zu erstellen, wodurch sie schwerer zu knacken sind. Jede Datenbank mit gehashten Benutzernamen kann mit einem einfachen Wörterbuch in wenigen Minuten geknackt werden ... es sei denn, Sie benötigen mindestens 6 alphanumerische Zeichen für Ihre Benutzernamen;)

Diese Idee entspricht zwei Taktiken: 1) Sicherheit durch Dunkelheit, 2) Zusätzliche Abschwächung von Timing-Angriffen (wenn Sie eine zeitsichere Vergleichsfunktion verwenden). Sie können kein einzigartiges Salz verwenden, um dies effektiv zu tun, aber es ist eine gute Idee. Dies würde es einem ermöglichen, die Tabelle, die Anmeldeinformationen enthält, von der Tabelle zu trennen, die "Personen" -Informationen enthält. Dann zwei Tabellen, Person (könnte Klartext-E-Mail-Adressen enthalten) und Benutzer (könnte einen Hash-Benutzernamen (Site Wide Salted) und ein Hash-Passwort und ein eindeutig gesalzenes Passwort enthalten). Das Nachschlagen des Benutzers anhand des Hash-Benutzernamens ist kein Problem.

Ich denke, das ist eine ausgezeichnete Idee. Wie von Anthony Rutledge ausgedrückt; Dies kann Sicherheit durch Verschleierung / Verschleierung bieten, und wenn eine Schlüsselableitungsfunktion wie PBKDF2 verwendet wird, besteht für einen potenziellen Angreifer, der versucht, eine gestohlene Datenbank zu kompromittieren, vermutlich eine um mehrere Größenordnungen größere Schwierigkeit.

Zum Beispiel würde ein Offline-Brute-Force-Angriff auf eine gestohlene Datenbank das Auffinden von Hash-Kollisionen sowohl für den Benutzernamen als auch für das Kennwort erfordern, ungeachtet der Tatsache, dass das Salzen des Benutzernamens in der Methode, wie oben erwähnt, Dies würde bedeuten, dass Angreifer Ihren Computer kommandieren und auch Ihren Quellcode identifizieren und verstehen müssten, da das Salt nirgendwo in Ihrer Datenbank vorhanden wäre. Es fügt mehrere zusätzliche Verteidigungsebenen hinzu, ohne die Rechenlast für die Webanwendung erheblich zu erhöhen.

In Bezug auf Hashing-Probleme: Der Benutzername kann mit einer proprietären Serverseite gesalzen werden Hash, basierend auf dem tatsächlichen Benutzernamen / der E-Mail-Adresse.

Das würde bedeuten, dass das Salz bekannt ist, wenn auch programmgesteuert. Und das Skript, das das Salz berechnet und zurückgibt, kann sich im Verhältnis zum Webdienst außerhalb des Bandes auf dem Computer befinden - so dass auf jede Methode zum Erzeugen des Salzes von jedem mit dem Web ausgerichteten Einstiegspunkt nicht zugegriffen werden kann.