it-swarm.it

Perché c'è un grande ritardo dopo aver inserito una password errata?

Noto una cosa strana (beh, secondo me) sulle password. Ad esempio, se digito una password errata durante l'accesso, ci saranno alcuni secondi di ritardo prima che il sistema me lo dica. Quando provo a Sudo con una password errata, dovrei anche aspettare prima che la Shell dica "Scusa, riprova".

Mi chiedo perché ci vuole così tanto tempo per "riconoscere" una password errata? Questo è stato visto su diverse distribuzioni che uso (e persino su OSX), quindi penso che non sia una cosa specifica per la distribuzione.

93
phunehehe

Questa è una cosa di sicurezza, in realtà non ci vuole molto a realizzarla. 2 vulnerabilità risolte:

  1. questo rallenta i tentativi di accesso, il che significa che qualcuno non può battere il sistema il più velocemente possibile cercando di craccarlo (1 milione di tentativi al secondo? Non lo so).

  2. Se lo ha fatto non appena ha verificato che le credenziali erano errate, è possibile utilizzare il tempo necessario per invalidare le credenziali per aiutare a indovinare se parte delle credenziali fosse corretta, riducendo drasticamente il tempo di indovinare.

per evitare queste 2 cose il sistema impiega solo un certo tempo per farlo, penso che tu possa configurare il tempo di attesa con PAM ( Vedi la risposta di Michaels ).

Security Engineering ( 2ed, Amazon | 1ed, gratuito ) fornisce una spiegazione molto migliore di questi problemi.

94
xenoterracide

Questo è intenzionale, per cercare di limitare la forza bruta. Di solito puoi modificarlo cercando il FAIL_DELAY voce di configurazione in /etc/login.defs e cambiando il suo valore (il mio è 3 secondi per impostazione predefinita), sebbene il commento in quel file faccia sembrare che PAM imporrà almeno un 2 secondo ritardo, non importa quale

42
Michael Mrozek

Sui moderni sistemi Linux, la ragione è che pam_unix.so impone un tale ritardo. Come precedentemente riportato, questo può essere configurato fino a due secondi modificando FAIL_DELAY In /etc/login.defs. Se vuoi ridurre ulteriormente il ritardo, devi dare a pam_unix.so l'opzione "nodelay". Ad esempio, sul mio sistema, se si tracciano le inclusioni a partire da /etc/pam.d/Sudo, Si scopre che è necessario modificare la seguente riga di /etc/pam.d/system-auth:

auth      required  pam_unix.so     try_first_pass nullok

e cambiarlo in questo:

auth      required  pam_unix.so     try_first_pass nullok nodelay

Sfortunatamente, il modo in cui my Linux distro (Arch) configura le cose, lo stesso file system-auth Viene incluso da system-remote-login, Che viene usato da sshd.

Sebbene sia sicuro eliminare il ritardo su Sudo, poiché è registrato, utilizzato solo dagli utenti locali e comunque aggirabile dagli attaccanti locali, probabilmente non si desidera eliminare questo ritardo per gli accessi remoti. Ovviamente puoi risolverlo scrivendo un Sudo personalizzato che non includa solo i file di autenticazione di sistema condivisi.

Personalmente, penso che il ritardo su Sudo (e ignorando SIGINT) sia un grosso errore. Significa che gli utenti che sanno di aver sbagliato a digitare la password non possono interrompere il processo e sentirsi frustrati. Certo, puoi ancora fermare il Sudo con Ctrl-Z, poiché il Sudo non cattura SIGTSTP, e dopo averlo fermato puoi ucciderlo con kill -9 (SIGKILL). È solo fastidioso da fare. Ciò significa che un attacco automatizzato potrebbe innescare un sudos su pseudo-terminali a un ritmo super elevato. Ma il ritardo frustra gli utenti legittimi e li incoraggia a sospendere i loro root shell invece di uscire da loro per evitare di dover ricorrere nuovamente al Sudo.

12
user3188445