Ein Gedanke ist, das Senden von Formularen nicht zuzulassen, wenn das Kennwortfeld keinen Wert enthält. Wenn sie versehentlich das Passwort in den Benutzernamen eingegeben haben, wird im Passwortdialog wahrscheinlich nichts angezeigt.

Es ist erwähnenswert, dass dies nicht einfach clientseitig erfolgen muss, sondern Dies kann auch auf einem Server erfolgen, solange der verwendete Transport sicher ist und die Eingabe erst protokolliert wird, nachdem überprüft wurde, ob das Kennwortfeld nicht leer ist.

Angenommen, Ihre Backend-Anwendung und SIEM müssen fehlgeschlagene Anmeldeversuche bei verschiedenen Anwendungen anzeigen (und daher die Fehlermeldung "Benutzer P @ $$ w0rd ist ungültig" anzeigen), dann ist es nicht trivial, dies zu stoppen.

Es ist jedoch eine gute Möglichkeit, sicherzustellen, dass alle Anwendungen, die vertrauliche Daten einschließlich Benutzernamen und Kennwörtern senden, HTTPS (verschlüsseltes HTTP mit SSL) implementieren, um sicherzustellen, dass Netzwerkgeräte und alle Personen im Netzwerk nicht das Kennwort erhalten, das fälschlicherweise verwendet wurde in das Feld für den Benutzernamen eingegeben!

Das Problem ist also, dass Analysten die Kennwörter nicht in den vertraulichen Protokolldateien sehen sollen.

Achtung: Selbst wenn Sie Javascript verwenden, werden die auf Ihrer Festplatte gespeicherten Kennwortdaten nicht im Klartext verarbeitet.

Eine bessere Lösung besteht darin, die Protokolle vorzuverarbeiten, bevor die Analysten sie sehen, und Informationen in den Protokollen zu redigieren.

Sie können diese zeilenweise Filterung durchführen, wenn Sie Zeilen auf die Whitelist setzen oder andere auf die schwarze Liste setzen Linien. Beispiel:

Sie können Benutzernamen auf die Whitelist setzen, wenn sie in einer Protokolldatei mit

• einem Muster ([az] + Nummer) oder angezeigt werden ([az] + Punkt + [az])
• enthält einen Domänennamen, gefolgt von einem Schrägstrich "\" für AD-Umgebungen.
• wird mehrmals angezeigt.
• Can Sie müssen mit einem LDAP-Verzeichnis bekannter Benutzernamen verglichen werden, bevor die Analysten es sehen.

Sie identifizieren Kennwörter auch anhand von:

• Die Kennwortrichtlinie folgt häufig einem Muster (ein Symbol, obere / untere, x Zeichen ...).

Mit diesem Wissen können Sie einen benutzerdefinierten Protokolldatenbereiniger erstellen, um die von Ihnen eingegebenen Informationen zu schützen Ich möchte nicht, dass Analysten sehen.

Wie sieht eine gefilterte Zeile aus?

Sie können fragwürdige Benutzernamen einfach redigieren, indem Sie sie hashen, ihnen eine menschliche ID zuweisen und sie speichern Ein sicherer Speicherort:

  eb574b236133e60c989c6f472f07827b Redact1 7e67b89a695bfbffc05b7ed2c38f927f Redact2 ..etc  

Die Analysten können immer wieder feststellen, ob ein bestimmter Eintrag wiederholt wird in der Frequenz.

Die genaue Hashing-Methode (oder Verschlüsselungsmethode), die Sie auswählen, unterliegt Risiken, da diese "Hash-Datenbank" hochwertige Informationen enthält. Und Seeding verhindert (von Natur aus) eine Frequenzanalyse, die für Sie von Wert sein kann oder nicht.

Ich kann nur drei Probleme mit dem, was Sie besprechen, identifizieren.

1. Benutzer geben Informationen nicht korrekt ein.
2. Analysten können Kennwörter aus Protokollen erkennen.
3. Passwörter werden im Klartext gesendet und sind anfällig für man-in-the-middle strike> lauschen.
ol>

Meiner Meinung nach ist dies der Fall ziemlich einfach zu beheben.

1. Benutzerfehler akzeptieren, widerwillig .
2. Protokollieren Sie keine ungültigen Benutzernamen, sondern protokollieren Sie fehlgeschlagene Versuche und IP.
3. Senden Sie keine Benutzernamen im Klartext. Verwenden Sie Technologien wie HTTPS oder Javascript, um den Klartext zu codieren (z. B. ROT13).
ol>

Beispielprotokoll einer fehlgeschlagenen Anmeldung und anschließend ein erfolgreicher Wiederholungsversuch.

  [00:00:00] Ein Konto konnte sich ab 192.168.1.100 nicht anmelden. [00:21:00] Erfolgreiche Anmeldung 'root' ab 192.168.1.100  

Beim Lesen anderer Antworten möchte ich dies einschließen.

• Überprüfen Sie alle Felder vor dem Absenden.
• Ziehen Sie in Betracht, das Formular als Eric zwischen mehreren Seiten aufzuteilen G erwähnt.

Eine Lösung, die einige Banken zumindest in Web-Apps implementiert haben, ist die Anmeldung auf zwei Seiten.

1. Akzeptieren Sie auf der ersten Seite nur den Benutzernamen
2. Fordern Sie auf der nächsten Seite des Prozesses das Kennwort an und geben Sie den Benutzernamen nur zurück, damit es sich nicht um ein bearbeitbares Feld handelt.
ol>

Daher sollte die einzige Eingabe auf der zweiten Seite das Passwort sein. Da der Benutzer weiß, dass er die erste Seite mit einem Benutzernamen löschen muss, weiß er, dass er dieses Gate löschen muss. Die einzige Option auf der zweiten Seite ist das Kennwort.

Wenn Sie diesen Workflow implementieren können, können Sie die Benutzer darauf konzentrieren, was sie wann eingeben.

---

Berücksichtigen Sie auch Ihre Protokollierung: Möglicherweise können Sie Ihre Protokollierung ändern tatsächliche Anmeldeinformationen nicht enthalten?

Verwenden Sie beispielsweise bei einer erfolgreichen Anmeldung die Primärschlüssel-ID, anstatt die Eingabe zurückzugeben: "Der Benutzer mit der ID: '2342342' hat versucht, sich anzumelden", dann "Der Benutzer mit der ID '2342342' hat erfolgreich ein Passwort angegeben ".

Wenn Sie nachschlagen und der Benutzername nicht vorhanden ist, hat beispielsweise "Benutzer von IP-Adresse '192.168.0.10' versucht, sich mit einer ungültigen Benutzer-ID anzumelden".

Dies wären Ihre Protokolle auf App-Ebene. Webserver-Protokolle können Abfrageparameter enthalten, sodass die Adressierung möglicherweise etwas schwieriger ist, oder Sie können eine Art Proxy-Filter zwischen die Aktion und das Schreiben des Protokolls einfügen, um den Protokollinhalt basierend auf bestimmten Regeln zu redigieren. Dies wäre plattformspezifisch, aber es sieht so aus, als ob es unter Apache möglich sein könnte.

Beschränken Sie als sekundäre Steuerung den Lesezugriff auf die verschiedenen Protokolldateien, die Sie verarbeiten.

Im Allgemeinen sind alle Client-Codes intelligent genug, um grundlegende Fehler zu behandeln.

1. Benutzer-ID und / oder fehlendes Passwort
2. Passwort entspricht nicht den Richtlinien
ol>

Wenn Sie diese Einträge immer noch im Protokoll sehen, wird

  Benutzer P @ $$ w0rd nicht [...] beendet. Ein Konto konnte sich nicht anmelden: P @ $$ w0rd [...]  

Keine der Client-Überprüfungen hat funktioniert, und das System hat das unverschlüsselte Kennwort über das Netzwerk gesendet. Was war also im Passwortfeld? Auf keinen Fall leer, da die Client-Validierung fehlschlagen würde. Es muss etwas anderes sein als das Passwort

. Machen Sie also eine Zwei-Pass-Authentifizierung.

1. Beim ersten Pass senden Sie alle verschlüsselten Details einschließlich des Passworts an den Server. Überprüfen Sie, ob das Feld Kennwort leer ist.
2. Erster Durchgang, Überprüfen Sie, ob das Kennwort mit den Richtlinien übereinstimmt. Andernfalls Fehler.
3. Erster Durchgang. Überprüfen Sie anschließend, ob das Kennwort in Ihrer Datenbank vorhanden ist. Wenn nicht Fehler aus.
4. Senden Sie eine RPC-Antwort an den Client zurück und lassen Sie ihn jetzt die Benutzer-ID und das Kennwort senden.
5. Führen Sie nun den Authentifizierungsprozess aus
ol >

Die ganze Essenz dieses Prozesses besteht darin,

1. das Risiko zu minimieren. Beachten Sie, dass Sie das Risiko für Zero
2. , dem Client nicht zu vertrauen, nicht ausschließen können.
ol>

Lassen Sie Ihre Benutzeroberfläche schließlich von einem UX-Experten überprüfen. Möglicherweise weist Ihre Benutzeroberfläche einen Fehler auf, der dazu führt, dass Benutzer das Kennwort in das ID-Feld eingeben.

Nach Ihrer Beschreibung Ihrer Architektur ist dies nicht möglich, aber meiner Meinung nach lautet die richtige Lösung: Senden Sie den Benutzernamen nicht im Klartext und protokollieren Sie keine Benutzernamen fehlgeschlagener Anmeldeversuche. Der einzige Ort, an dem der Benutzername und das Kennwort gespeichert werden sollen, ist das Subsystem, das das Kennwort überprüft. Bis dahin ist der Benutzername nicht authentifizierte, willkürliche Daten - jeder, der Zugriff auf das Anmeldeformular hat, bei dem es sich in einer Webanwendung um das gesamte Internet handelt, kann alles eingeben, was er möchte, wie oft er möchte - und daher sagt Ihnen sehr wenig von Interesse. (Es sei denn, Ihr Anmeldeformular ist nicht für das Internet verfügbar.)

Dies würde wahrscheinlich einen Großteil der Protokollanalyse eliminieren, da nicht festgestellt werden kann, wer was getan hat ...? P. >

Wenn Sie einen Benutzernamen ohne das richtige Kennwort angegeben haben, wissen Sie nicht, dass die Anfrage tatsächlich von diesem Benutzer stammt. Sie wissen also immer noch nicht, wer stark> hat den Anmeldeversuch gemacht.

Das allgemeine Problem ist die kennwortbasierte Authentifizierung. Jeder Tante-Emma-Laden besteht auf einer eigenen Authentifizierung mit Passwörtern. Das ist dumm.

Lassen Sie einen anderen Identitätsanbieter die harte Arbeit leisten, um die Anmeldeinformationen sicher zu halten. Gehen Sie genauso vor wie bei StackOverflow: Ermöglichen Sie die Authentifizierung mit OpenID, Google Mail usw.

Ihre Benutzer werden es Ihnen danken, dass Sie irgendwo kein weiteres Kennwort benötigen.

Client-seitiges Javascript erscheint vernünftig.

Überprüfen Sie, ob das Kennwortfeld vor der Übermittlung nicht leer ist. Überprüfen Sie, ob der Benutzername in einer gültigen Form vorliegt. Besonders elegant ist etwas, bei dem der Benutzername eine E-Mail-Adresse sein muss. Sie können außerdem verhindern, dass das Passwort in Ihrem Mechanismus zum Festlegen / Ändern von Passwörtern in Form einer E-Mail-Adresse vorliegt. Überprüfen Sie dann einfach, ob der Benutzername in Form einer gültigen E-Mail-Adresse vorliegt, bevor Sie das Formular senden. Dies könnte ähnlich mit beispielsweise Sonderzeichen oder Zahlen geschehen. (ZB sind in Kennwörtern Zahlen / Sonderzeichen erforderlich, Benutzernamen jedoch verboten.)

Verwenden Sie außerdem für alle Formularübermittlungen eine aktuelle SSL-Bibliothek (dies sollte erfolgen, um zu verhindern, dass Netzwerk-Lauscher abhören im). Zum Lesen dieser Protokolle sind erhöhte Berechtigungen erforderlich (z. B. kann das Webserverkonto in diese Protokolle schreiben, aber nur root kann sie lesen). Sobald das Kennwort den Authentifizierungsschritt nicht besteht, geben Sie den Benutzernamen nicht an andere Systeme weiter. (Verwenden Sie auch SSL zwischen verschiedenen internen Systemen, um Netzwerk-Lauschangriffe zu verhindern.)

Ich mag den Ansatz, den mein aktuelles Unternehmen bei diesem Problem verfolgt: Wenn Sie Ihr Passwort in das falsche Feld eingeben, läuft Ihr Passwort durch ein automatisiertes System sofort ab. Daher muss der Benutzer sein Kennwort ändern, und das Kennwort im Protokoll ist jetzt nicht mehr anfällig.

Dies ist natürlich immer noch nicht ideal, wenn der Benutzer dieses Kennwort weiterhin für ein anderes System verwendet. Wenn ein Benutzer jedoch hoffentlich gezwungen wird, sein Kennwort zu ändern, wird er sich der möglichen Sicherheitsrisiken bewusster.

Meistens ist die EINFACHSTE Antwort die richtige Antwort. Jetzt stellen wir fest, dass jede E-Mail-Adresse kurz vor dem Domain-Namen mit einem "@" gekennzeichnet ist. Wenn Sie "@" zu einem NICHT AKZEPTIERBAREN Schlüssel im Passwort machen, ist die Lösung ziemlich offensichtlich. Wenn der Benutzername NICHT @ hat und ALLE BENUTZERNAMEN E-Mail-Adressen sind, protokollieren Sie nur diejenigen, die mindestens @ enthalten.

Wenn der Benutzername NICHT "@" hat, kann dies wahrscheinlich einige Benutzer verärgern, aber Dies ist eine saubere Lösung. Das heißt, EIN EINZIGES Sonderzeichen, das VOR einem Passwort kommt. Genau wie ALLE BENUTZERNAMEN, die E-Mail-Konten sind, haben sie ein Format. Alle Antworten haben am Anfang oder am Ende einen Sondercharakter. Wenn der Benutzer ein Kennwort eingibt, teilen Sie ihm mit, dass er es eingeben muss.

Die dritte Lösung ist die FARBCODIERUNG. Machen Sie das Benutzernamenfeld gelb und das Passwortfeld rot. Rot erregt normalerweise Ihre Aufmerksamkeit, da es für empfindliche Dinge verwendet wird. Selbst wenn sie auf die Tastatur schauen, werden sie SEHR SCHNELL LERNEN, dass Passwörter rot sind. Im Grunde genommen ist das Textfeld UND die Kennzeichnung des Kennworts vorzugsweise in einem separaten Feld rot und die Bezeichnung und das Textfeld des Benutzernamens sind GELB

Warum nicht einfach damit antworten?

  Dieser Benutzername existiert nicht  

Wie viel Kontrolle haben Sie darüber, wie der empfangende Server damit umgeht? Es scheint, als ob die Lösung, die ein Benutzer oben vorgeschlagen hat, um sowohl den Benutzernamen als auch das Kennwort zu hashen, auf verschiedene Arten funktioniert:

Methode 1 (JavaScript erforderlich): Hash sowohl des Benutzernamens als auch des Kennworts. Speichern Sie in Ihrer Datenbank gehashte Benutzernamen und führen Sie dann Ihre Authentifizierungssuche mithilfe dieses Felds durch. Dies ist ideal, wenn Sie die Kontrolle über die Art und Weise haben, wie die Daten auf Ihrem Server behandelt werden, aber nicht die Protokollierungskapazität.

Methode 2 (ohne JavaScript): Empfangen Sie den Benutzernamen wie gewohnt im Klartext. Konvertieren Sie es jedoch wie in Methode 1 in einen Hash, sobald Sie es auf dem Server erhalten haben. Wenn der Versuch fehlschlägt, protokollieren Sie den Hash und nicht den Benutzernamen. Die Protokolle sind weiterhin nützlich (etwas weniger nützlich, wenn sie kursiv überprüft werden), da jeder Hash einen Benutzer immer noch eindeutig identifiziert. Keines davon ist so elegant wie die Top-Antwort hier (und ich würde vorschlagen, dies auch zu verwenden), aber sie sind gründlicher.

• erlaubt nur das Übertragen von MD5-Hashes von Benutzernamen UND Passwörtern (oder ähnlichen Hashs), so dass alles, was in den Protokolldateien protokolliert wird, immer wie eine feste Länge zufälliger Zeichen aussieht, was niemandem möglich ist Erraten Sie schnell, dass es sich um einen MD5 eines Passworts oder eines Benutzernamens handelt.

Con: Um mit Benutzernamen in Ihrer Datenbank zu vergleichen, müssen Sie entweder zwei Spalten speichern, z. 'Benutzername' und 'md5 (Benutzername)' ODER Sie müssen jedes Mal, wenn Sie den Benutzernamen für die Anmeldung abfragen, dynamisch hashen.

• Erstellen Sie einen Protokolleintrag nur, wenn der Benutzername in der Datenbank vorhanden ist. Andernfalls protokollieren Sie nur die IP-Adresse.

• Erlauben Sie dem Benutzer, mit der Maus und nicht mit der Tastatur auf die Eingabetaste zu klicken, oder lassen Sie die Tastatur erst nach 5 Sekunden des zuletzt eingegebenen Zeichens in einem der Felder zu, damit der Benutzer Zeit hat, auf den Bildschirm zu schauen und seinen Fehler zu erkennen.

• beschränken Sie zulässige Benutzernamen und Kennwörter:

  1. Kennwörter müssen ein Sonderzeichen wie! @ # $% ^ & * enthalten. ()
  2. Benutzernamen dürfen KEINE Sonderzeichen enthalten
  ol>

Auf diese Weise können Sie mit Javascript schnell feststellen, ob es sich bei dem eingegebenen Benutzernamen um einen handelt oder Passwort.

Eine einfache, aber ärgerliche Lösung könnte darin bestehen, ein Bildschirmtastaturlayout mit HTML-Schaltflächen zu haben, in dem Benutzer ihren Benutzernamen nur über diese Schaltflächen eingeben können. Dadurch wird verhindert, dass der Fehler gemacht wird. Mir ist klar, wie ärgerlich dies sein kann out to be, aber nach dem ersten Login können Sie ein Cookie verwenden, um sich den Benutzernamen zu merken und ihn nicht erneut zu benötigen. Javascript wird natürlich benötigt. Jetzt ist es unmöglich, das Passwort versehentlich im Klartext zu senden. Hoffe es hilft.

Ich habe eine andere Einstellung ... Welches Problem versuchen Sie wirklich zu lösen?

1. Falsche Passwörter? Das heißt, Wenn Sie sehen, dass eine Person "Passwort" (oder eine Variante) verwendet, möchten Sie in der Lage sein, zum Benutzer zurückzukehren und es zu korrigieren?

2. Passwörter, die im Klartext gesendet werden?

3. Oder das Problem mit Idioten, die keine Formulare eingeben oder lesen können (oder vielleicht eine schlecht gestaltete Benutzeroberfläche)?

ol>

Denken Sie immer daran, dass Sie bei jedem "Hinzufügen" zum System möglicherweise Komplexität hinzufügen und definitiv Code hinzufügen - beides erhöht die Möglichkeit, dass Sie irgendwo Sicherheitslücken in Ihrer Gesamtarchitektur öffnen (möglicherweise im Stapel, möglicherweise) über das Web könnte über das Netz sein ...). Wenn Sie also eine der drei lösen, müssen Sie messen, ob der Wert der Lösung das Risiko wert ist, ein Loch zu stechen, von dem Sie nichts wissen - der Teufel, den Sie kennen, ist immer besser als der Teufel, den Sie nicht kennen.

Nun zu jedem.

Das Auflösen fehlerhafter Passwörter sollte beim Einrichten und Ändern des Passworts über die Validierungsregeln erfolgen. Und nur dort. Wenn Sie einen weiteren Ort hinzufügen, besteht nur die Gefahr, dass die Validierungsregeln verwirrt oder nicht mehr synchron sind.

Passwörter werden im Klartext gesendet. Wen interessiert das? Zugegeben, es könnte sich unsicher anfühlen, aber denken Sie daran, dass dies eine n-teilige Authentifizierung ist. Wenn Sie nur einen Teil haben, unterscheidet sich dies nicht von einem Wort in einem Wörterbuch. Vielleicht, nur vielleicht, wenn Sie einen aktiven Schnüffler haben, kann er ihnen einige Hinweise geben, aber dann ist das bereits vorhandene Eindringen Ihr eigentliches Problem, nicht ein gelegentliches, zufälliges, fettes Fingern von Passwörtern im Feld für den Benutzernamen. Nun, wenn alle Teile in dem klaren, großen Problem gesendet werden.

Problem mit Idioten oder schlechtem UI-Design. Benutzer oder Benutzeroberfläche erneut vermitteln. Einfach. Bieten Sie aktive Hilfe auf der Benutzeroberfläche an, lassen Sie die Abteilungen eine Schulung durchführen oder so. Einfache Lösung, die begrenzte Codierungsänderungen mit geringem Risiko erfordert (oder - sollte jedoch mit dem UI-Aspekt vorsichtig sein).

Während ich viele der Vorschläge hier bewundere und viele von ihnen wunderbare Ideen in ihrem Kern haben. Ich empfehle einen KISS, keinen BS-Ansatz, und denke immer daran, dass Sie beim Hinzufügen zu Ihren Systemen das Risiko eingehen, Ihre Unsicherheit zu erhöhen.

Nur meine 2 Cent.

Biometrie ist derzeit recht kostengünstig und funktioniert mindestens 80% der Zeit. Ich finde es großartig auf TabletPCs und wollte biometrische Tastaturen bereitstellen, weil es schneller ist (zumindest in 80% der Fälle).

Ich wette, dies war bei Win2000 bei weitem kein so großes Problem , WinXP, Win2003 und WinVista, da das Feld Benutzername standardmäßig bereits mit dem letzten erfolgreichen Benutzernamen gefüllt war. Nicht genau sicher, welche Version von ActiveDirectory oder Workstation geändert wurde, aber die Standardeinstellung ist jetzt, dass das Feld für den Benutzernamen leer ist, wodurch dieses Problem häufiger auftritt.