it-swarm.com.de

Warum gibt es eine große Verzögerung nach der Eingabe eines falschen Passworts?

Ich bemerke eine seltsame (meiner Meinung nach) Sache mit Passwörtern. Wenn ich beispielsweise während der Anmeldung ein falsches Kennwort eingebe, dauert es einige Sekunden, bis das System dies mir mitteilt. Wenn ich versuche, Sudo mit einem falschen Passwort zu verwenden, muss ich auch warten, bis die Shell "Entschuldigung, versuchen Sie es erneut" sagt.

Ich frage mich, warum es so lange dauert, ein falsches Passwort zu "erkennen". Dies wurde bei mehreren von mir verwendeten Distributionen (und sogar bei OSX) beobachtet, daher denke ich, dass es keine verteilungsspezifische Sache ist.

93
phunehehe

Dies ist eine Sicherheitssache, es dauert nicht lange, sie zu realisieren. 2 Schwachstellen, die dadurch behoben werden:

  1. dies drosselt Anmeldeversuche, was bedeutet, dass jemand das System nicht so schnell schlagen kann, wie es versuchen kann, es zu knacken (1 Million Versuche pro Sekunde? Ich weiß nicht).

  2. Wenn dies der Fall war, sobald überprüft wurde, dass Ihre Anmeldeinformationen falsch waren, können Sie die Zeit verwenden, die erforderlich war, um Ihre Anmeldeinformationen ungültig zu machen, um zu erraten, ob ein Teil Ihrer Anmeldeinformationen korrekt war, wodurch sich die Zeit für das Erraten erheblich verkürzt.

um diese beiden Dinge zu verhindern, benötigt das System nur eine gewisse Zeit, um dies zu tun. Ich denke, Sie können die Wartezeit mit PAM konfigurieren ( siehe Michaels Antwort ).

Security Engineering ( 2ed, Amazon | 1ed, free ) bietet eine viel bessere Erklärung für diese Probleme.

94
xenoterracide

Dies ist beabsichtigt, um zu versuchen, das brutale Forcen zu begrenzen. Sie können es normalerweise ändern, indem Sie in FAIL_DELAY Nach dem Konfigurationseintrag /etc/login.defs Suchen und seinen Wert ändern (meiner ist standardmäßig 3 Sekunden), obwohl der Kommentar in dieser Datei dies bewirkt klingt so, als würde PAM mindestens eine 2 zweite Verzögerung erzwingen, egal was passiert

42
Michael Mrozek

Bei modernen Linux-Systemen liegt der Grund darin, dass pam_unix.so eine solche Verzögerung verursacht. Wie bereits berichtet, kann dies durch Ändern von FAIL_DELAY In /etc/login.defs Bis zu zwei Sekunden lang konfiguriert werden. Wenn Sie die Verzögerung weiter reduzieren möchten, müssen Sie pam_unix.so die Option "nodelay" geben. Wenn Sie beispielsweise auf meinem System die Includes ab /etc/pam.d/Sudo Verfolgen, müssen Sie die folgende Zeile von /etc/pam.d/system-auth Bearbeiten:

auth      required  pam_unix.so     try_first_pass nullok

und ändern Sie es zu diesem:

auth      required  pam_unix.so     try_first_pass nullok nodelay

Leider wird bei der Konfiguration meiner Linux-Distribution (Arch) dieselbe system-auth - Datei von system-remote-login Eingeschlossen, die von sshd verwendet wird.

Obwohl es sicher ist, die Verzögerung in Sudo zu beseitigen, da diese protokolliert wird, nur von lokalen Benutzern verwendet wird und von lokalen Angreifern ohnehin umgangen werden kann, möchten Sie diese Verzögerung bei Remote-Anmeldungen wahrscheinlich nicht beseitigen. Sie können das Problem natürlich beheben, indem Sie ein benutzerdefiniertes Sudo schreiben, das nicht nur die freigegebenen Systemauthentifizierungsdateien enthält.

Persönlich denke ich, dass die Verzögerung bei Sudo (und das Ignorieren von SIGINT) ein großer Fehler ist. Dies bedeutet, dass Benutzer, die wissen, dass sie das Kennwort falsch eingegeben haben, den Vorgang nicht beenden und frustriert werden können. Natürlich können Sie Sudo immer noch mit Strg-Z stoppen, da Sudo SIGTSTP nicht fängt, und nachdem Sie es gestoppt haben, können Sie es mit kill -9 (SIGKILL) töten. Es ist nur nervig zu tun. Das bedeutet, dass ein automatisierter Angriff Sudos auf Pseudo-Terminals mit einer super hohen Rate abfeuern könnte. Aber die Verzögerung frustriert legitime Benutzer und ermutigt sie, ihre Root-Shells auszusetzen, anstatt sie zu verlassen, um zu vermeiden, dass sie erneut Sudo müssen.

12
user3188445