Por que há um grande atraso depois de digitar uma senha errada?

Question

Eu noto uma coisa estranha (bem, de acordo comigo) sobre senhas. Por exemplo, se eu digitar uma senha incorreta durante o login, haverá um atraso de alguns segundos antes que o sistema me diga isso. Quando tento sudo com uma senha errada, eu também teria que esperar antes que o shell dissesse "Desculpe, tente novamente".

Eu me pergunto por que demora tanto para "reconhecer" uma senha incorreta? Isso foi visto em várias distribuições que eu uso (e até mesmo OSX), então eu acho que não é uma coisa específica de distribuição.

    

Answer 1

Isso é uma questão de segurança, não está demorando muito para perceber isso. 2 vulnerabilidades que isso resolve:

1. isso limita as tentativas de login, o que significa que alguém não pode bater o sistema o mais rápido possível para tentar quebrá-lo (1 milhão de tentativas por segundo? Não sei).

2. Se isso acontecesse assim que a verificação das suas credenciais estivesse incorreta, você poderia usar o tempo necessário para invalidar suas credenciais para ajudar a adivinhar se parte das suas credenciais estava correta, reduzindo drasticamente a suposição. tempo.

para evitar essas duas coisas, o sistema leva apenas um certo tempo para fazê-lo, eu acho que você pode configurar o tempo de espera com o PAM ( Veja a resposta do Michaels ).

Engenharia de segurança ( 2ed, amazon | 1ed, free ) fornece uma explicação muito melhor desses problemas.

    

Answer 2

Isso é intencional, para tentar limitar a força bruta. Geralmente, é possível modificá-lo procurando a entrada de configuração FAIL_DELAY em /etc/login.defs e alterando seu valor (a mina é 3 segundos por padrão), embora o comentário nesse arquivo faça parecer que o PAM aplicará pelo menos um 2 segundo atraso não importa o que

    

Answer 3

Em sistemas Linux modernos, a razão é que o pam_unix.so impõe tal atraso. Conforme relatado anteriormente, isso pode ser configurado em até dois segundos, alterando FAIL_DELAY em /etc/login.defs . Se você quiser reduzir ainda mais o atraso, você deve dar ao pam_unix.so a opção "nodelay". Por exemplo, no meu sistema, se você rastrear as inclusões a partir de /etc/pam.d/sudo , verá que precisa editar a seguinte linha de /etc/pam.d/system-auth :

auth      required  pam_unix.so     try_first_pass nullok

e mude para isso:

auth      required  pam_unix.so     try_first_pass nullok nodelay

Infelizmente, a maneira como meu Linux distro (arch) configura as coisas, esse mesmo arquivo system-auth é incluído por system-remote-login , que é usado pelo sshd.

Embora seja seguro eliminar o atraso no sudo, porque isso é registrado, usado apenas por usuários locais e ignorado por atacantes locais de qualquer maneira, você provavelmente não quer eliminar esse atraso para logins remotos. É claro que você pode corrigi-lo escrevendo um sudo personalizado que não inclua apenas os arquivos de autenticação do sistema compartilhados.

Pessoalmente, acho que o atraso no sudo (e ignorar o SIGINT) é um grande erro. Isso significa que os usuários que sabem que digitaram incorretamente a senha não podem matar o processo e ficarem frustrados. Claro, você ainda pode parar o sudo com Ctrl-Z, já que o sudo não pega o SIGTSTP, e depois de pará-lo você pode matá-lo com kill -9 (SIGKILL). É chato de fazer. Isso significa que um ataque automatizado poderia disparar sudos em pseudo-terminais a uma taxa super alta. Mas o atraso frustra os usuários legítimos e os encoraja a suspender seus shells de raiz em vez de deixá-los para evitar ter que suar novamente.