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

Noto una cosa strana (bene, 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 sudocon 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.

— phunehehe
fonte

Ho notato questo non solo nel terminale ma anche al login della sessione iniziale dopo l'avvio o quando il laptop è in modalità di sospensione. Sbloccare la password corretta è istantaneo, felice di vedere sollevate queste domande :)

— krozaine,

Risposte:

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

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).
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 ).

L'ingegneria della sicurezza ( 2ed, amazon | 1ed, gratuito ) fornisce una spiegazione molto migliore di questi problemi.

— xenoterracide
fonte

// offtopic g non è un bug, è una caratteristica ;-)

— echox

Il tuo link di affiliazione è stato automaticamente riscritto da SE, tra l'altro.

— Gelatina,

@Tshepang: vedi capitolo 2 , in particolare §2.4 e §2.5.3.3.

— Gilles,

La differenza tra fallimento precoce e tardivo durante il confronto di un hash della password viene misurata in nanosecondi. Con una codifica corretta (confronto costante della memoria temporale) non vi è alcuna differenza. Questa non è una giustificazione per aggiungere un ritardo.

— Codici A Caos il

Sono d'accordo con CodesInChaos: il secondo punto della risposta è errato. Quello che sta realmente accadendo è il seguente: 1. viene calcolato un hash del tuo input; 2. che l'hash viene confrontato con l'hash memorizzato (ogni byte di esso, anche se è già stata rilevata una differenza); Si noti che questi due passaggi non sono in alcun modo più veloci o più lenti a seconda che la password inserita sia corretta. (e come altri hanno già sottolineato, l'aggiunta di una durata del sonno non riparerebbe un attacco di temporizzazione se fosse possibile)

— esempio

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

— Michael Mrozek
fonte

Questo per prevenire qualcosa di più della semplice forza bruta. ma punti bonus per sapere dove configurarlo.

— xenoterracide,

Penso che il fail_delay sia anche configurabile in /etc/pam.d/login. Cercapam_faildelay.so delay=

— Steven D,

cosa ti impedisce di scrivere un wrapper per sudo che avvia una nuova istanza di sudo quando un tentativo non funziona entro, diciamo, 0.1 secondi?

— Janus Troelsen,

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 cambiando FAIL_DELAYin /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 la mia distribuzione Linux (arch) configura le cose, system-authviene incluso lo stesso file 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 include solo i file condivisi di autenticazione del sistema.

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. Ovviamente, puoi ancora fermare sudo con Ctrl-Z, poiché 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 le loro shell root invece di uscire da loro per evitare di dover ripetere l'operazione.

— user3188445
fonte

Lo stesso con Fedora. Analisi straordinaria

— Freedom_Ben

Risposta brillante. Pensavo anche che FAIL_DELAY sia diventato obsoleto nei moderni sistemi desktop. Dovresti fare affidamento sulla crittografia della partizione / del disco rigido e nient'altro. In genere, non esiste un secondo utente che potrebbe tentare di forzare la password di root forzata. Tuttavia , programmi potenzialmente dannosi potrebbero abusare di un FAIL_DELAY non sicuro e quindi ottenere l'accesso root.

— phil294,

impostando pam-unix nodelay, il tempo di attesa verrà impostato su 0 a proposito, e FAIL_DELAY viene quindi ignorato.

— phil294,

Perché non disabilitare il ritardo, quindi disabilitare l'accesso con password remota (solo SSH)? Questo non risolve il problema senza introdurre alcuna vulnerabilità di sicurezza?

— Radon Rosborough,