Por que existe um grande atraso depois de inserir uma senha errada?

Percebo uma coisa estranha (bem, na minha opinião) sobre senhas. Por exemplo, se eu digitar uma senha incorreta durante o login, haverá um atraso de alguns segundos antes que o sistema me informe. Quando tento sudocom uma senha errada, também tenho que esperar antes que o shell diga "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é no OSX), então acho que não é uma coisa específica da distribuição.

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

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

2. Se o fizesse assim que verificasse que suas credenciais estavam incorretas, você poderia usar o tempo necessário para invalidar suas credenciais para ajudar a adivinhar se parte de suas credenciais estava correta, reduzindo drasticamente o tempo de adivinhação.

Para evitar essas duas coisas, o sistema leva um certo tempo para fazer isso, acho que você pode configurar o tempo de espera com o PAM ( consulte a resposta de Michaels ).

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

Isso é intencional, tentar limitar a força bruta. Geralmente, você pode modificá-lo procurando a FAIL_DELAYentrada de configuração /etc/login.defse alterando seu valor (o meu é 3segundos por padrão), embora o comentário nesse arquivo pareça que o PAM imporá pelo menos um 2segundo atraso, não importa o que

Nos sistemas linux modernos, o motivo é que o pam_unix.so impõe esse atraso. Conforme relatado anteriormente, isso pode ser configurado em até dois segundos, alterando FAIL_DELAY-o /etc/login.defs. Se você deseja reduzir ainda mais o atraso, é necessário 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, você precisará 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, da maneira como minha distribuição Linux (arch) configura as coisas, esse mesmo system-autharquivo é incluído por system-remote-login, o qual é usado pelo sshd.

Embora seja seguro eliminar o atraso no sudo, porque ele é registrado, usado apenas por usuários locais e ignorável pelos invasores locais de qualquer maneira, você provavelmente não deseja eliminar esse atraso para logins remotos. Obviamente, você pode corrigi-lo escrevendo um sudo personalizado que não inclui 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 interromper o processo e ficar frustrados. Obviamente, você ainda pode parar o sudo com Ctrl-Z, pois o sudo não captura o SIGTSTP e, depois de interrompê-lo, você pode matá-lo com o kill -9 (SIGKILL). É apenas chato de fazer. Isso significa que um ataque automatizado pode disparar sudos em pseudo-terminais a uma taxa super alta. Mas o atraso frustra usuários legítimos e os incentiva a suspender suas conchas raiz em vez de sair deles para evitar ter que sudo novamente.