Segurança de senha mínima do servidor Web com base em 100 tentativas por segundo

3

Este artigo perspicaz propõe que as senhas não precisam ser muito seguras: link ?

Há uma linha específica aqui que eu acho preocupante:

The actual number varies, but most web applications would not be capable of handling more than 100 sign-in requests per second.

É verdade que a maioria das aplicações web só precisa ser capaz de proteger contra 100 tentativas por segundo? Parece um número muito baixo quando você lida com sistemas distribuídos que podem ser atacados por vários intrusos.

EDITAR Mais esclarecimentos sobre minha pergunta: Com base no desempenho médio atual da maioria dos servidores da Web, qual é o número máximo de tentativas de login possíveis durante um ataque de força bruta? Não estou perguntando sobre ataques de senha off-line em que alguém pode realmente fazer tentativas de login.

Coloque em perspectiva, digamos que você tenha um requisito para um sistema que não pode usar tarp pitting ou desabilitação temporária de conta (para impedir que hackers façam tentativas de login), o número de tentativas reais de login por segundo em uma web sistema baseado em computador é muito útil.

    
por pokstad 16.04.2011 / 00:56

4 respostas

3

but most web applications would not be capable of handling more than 100 sign-in requests per second.

O que isto significa é: O autor desse artigo faz uma alegação infundada (mas não totalmente irracional) de que enviar mais de 100 assinaturas por segundo seria um efetivo ataque de negação de serviço contra "a maioria" aplicações web.

Para cada entrada, um aplicativo da web típico teria que hash a senha e compará-la com a representação em hash no banco de dados. Se o webapp usar uma boa função de hash , isso de fato usa uma boa quantidade de CPU. Portanto, a alegação talvez não seja totalmente irracional, mas, na minha experiência, a maioria dos aplicativos da Web usa apenas um hash simples como o MD5, o SHA1 ou o SHA256, que não exige muita CPU.

O grande erro nesse artigo vem aqui:

Note: The examples below are based on 100 password request per second.

Nos próximos parágrafos, o autor faz sugestões para a força da senha, com base em uma taxa máxima de ataque de 100 tentativas por segundo. Esse pode ser um número razoável para um ataque on-line , em que o invasor se conecta ao aplicativo da Web ao vivo.

Mas, para um ataque off-line , em que o invasor fez o primeiro download de todo o banco de dados por meio de um ataque de injeção SQL, isso é totalmente errado. Por exemplo, aqui está uma implementação da NVIDIA CUDA para o SHA1 , que pode ser 47 milhões de hashes por segundo em um pequeno cluster de servidores.

web applications only need to be able to protect against 100 attempts per second?

Desculpe, mas não, você está entendendo mal essa parte. Agora, você está analisando do ponto de vista do proprietário do webapp tentando proteger um ataque de adivinhação de senha de força bruta on-line. Você deve tomar uma ação longa antes de chegar a isso.

  1. Se as contas individuais tiverem um determinado número de tentativas de login com falha (3,5,10,25 todas podem ser números razoáveis), a conta deverá ser desativada temporariamente. (Ou melhor ainda, não desabilite a conta, mas diminua as tentativas de login, ou seja, limitação de tarjeta / taxa.)
  2. Se você estiver obtendo centenas de tentativas de login com falha por segundo em todo o sistema, sua estrutura de registro / monitoramento (Nagios etc) deverá estar gritando alertas para que você fique ciente do ataque.

Por último, você pode querer ler as Perguntas frequentes que acompanham o artigo , torna os autores mais claros. Ele está falando sobre como os usuários finais podem gerar senhas razoavelmente seguras e ainda fáceis de lembrar - não sobre o tratamento das senhas no servidor.

Atualização, após a edição da pergunta:

Based on the current average performance of most web servers, what is the maximum number of login attempts possible during a brute force attack?

Para um simples hash como o SHA1, eu diria que um único servidor quad-core, assumindo boas técnicas de programação, poderia lidar com um número muito grande de 10.000 solicitações por segundo. Dependerá totalmente do framework webapp & programação utilizada, porque a sobrecarga de manipulação da conexão HTTP dominará a velocidade de cálculo do SHA1. Se estivermos usando o Apache no modo Prefork com o fx PHP, os números serão muito bons, talvez 2.000 solicitações por segundo por servidor.

let's say you have a requirement for a system that cannot use tar-pitting or temporary account disabling

Em seguida, altere os requisitos - isso está além do reparo.

the number of actual login attempts per second on a web-based system is very useful.

Mais uma vez, você deve alertar sobre um ataque de força bruta longo antes que ele fique tão grande.

    
por 17.04.2011 / 10:41
0

Como devemos responder algo sobre "a maioria" de aplicativos da web? A maioria provavelmente está nas intranets da empresa, para começar, mas você provavelmente está fora da "maioria" quando acessa os aplicativos da Web que estão sendo executados em dois ou mais servidores.

De qualquer forma, não acho que você receba apenas 100 solicitações por segundo, então é só para isso que você precisa se defender, que é como sua pergunta soa, mas provavelmente você só pode lidar com 100 solicitações por segundo (o que é de 60.000 / minuto), de modo que o nível faz uma boa troca.

Se o seu aplicativo conseguir lidar com logins de 1000x por segundo, talvez repensar as coisas.

O artigo não menciona tar-pitting, que é a prática de retardar as respostas de login, de modo que a força bruta se torna impossível - você pode ter visto você mesmo onde tentou fazer o login 5 vezes e depois disso digitar uma senha Ele fica lá, agitando por anos antes de dizer que ele falhou, e depois de 10 tentativas, o atraso aumenta. Continue tentando e continue desacelerando, mas saia e volte em vinte minutos e é rápido novamente.

Fazer isso pode tornar a força bruta quase impossível.

    
por 16.04.2011 / 13:36
0

O autor desse artigo está fazendo uma suposição enorme sobre o número de solicitações que aplicativos da Web "normais" podem manipular. Se o seu site estiver em um servidor dedicado com código bem escrito, ele poderá lidar com 1.000 solicitações por segundo sem suar a camisa. Um servidor mais antigo, sem qualquer tipo de otimização, só pode conseguir 10 solicitações por segundo antes de começar a parar. O autor teve que escolher um número para basear seus cálculos e 100 parece ser um lugar razoável para começar.

Se você está tentando se defender contra ataques de força bruta ou de dicionário, pode usar uma variedade de técnicas, como tar-pitting, como mencionado por TessellatingHeckler, ou colocar bloqueios temporários na conta, conforme sugerido pelo artigo. Eu até vi sistemas que simplesmente ignoram solicitações de qualquer IP que ele veja solicitações de envio acima de uma determinada taxa.

Quanto à pergunta original, o invasor poderá tentar o maior número possível de senhas, sem deixar o servidor inativo. Portanto, não é necessário "defender-se" de um determinado número de solicitações por segundo, como o invasor limitará suas próprias ferramentas se o virem causando lentidão no servidor, pois é de seu interesse não chamar atenção para si. Basta projetar seu aplicativo para poder lidar com a carga normal esperada, além de uma margem razoável de crescimento e o pico ocasional de tráfego.

Se você está preocupado com ataques DDoS genéricos, isso é totalmente diferente e não tem nada a ver com solicitações por segundo para tentativas de senha.

    
por 17.04.2011 / 06:55
0

Você pode implementar uma cadeia fácil para os forçadores de brute. Digamos que depois de 3 logins com falha você bloqueie logins daquele ip por 1 (ou mais) minuto (a), mas continue enviando para a falta de correspondência de usuário / senha do cliente

Outra maneira é separar logins de usuários e administradores. digamos, você está fazendo alguma forma principal para logins de usuários e colocar perto dele um botão falso para login de admin sempre irá dizer "Incorect password". e faça alguma página oculta para login real de admin: D

    
por 18.04.2011 / 14:15