Um dos problemas que surgem diante dos recursos da WEB com contas pessoais é um ataque de força bruta. Sim, uma enumeração simples de todas as opções de senha para uma conta específica. Estupidamente? Talvez, mas esse ataque pode carregar muito o recurso. Além disso, se não houver controle sobre a complexidade da senha do usuário durante o registro, ela também poderá ser bem-sucedida.
Na maioria das vezes, o problema é resolvido de forma relativamente simples. Se o usuário digitar a senha incorretamente várias vezes, sua conta será bloqueada por algum tempo. Uma solução alternativa é exibir captcha. Imediatamente ou após várias tentativas malsucedidas. Bem, não vamos esquecer a autorização 2F, que é quase invulnerável. Parece - lucro! Mas, nem tudo é tão róseo ...
Vejamos alguns dos problemas descritos nas soluções:
Bloqueio temporário - a conta do usuário é temporariamente bloqueada e ele não pode entrar no sistema. O usuário real durante o ataque experimenta mágoa e tormento. Ele não pode entrar no sistema. E provavelmente carrega seu apoio. E o mais interessante é que talvez esse seja o objetivo do atacante.
Captcha é uma solução relativamente boa e eficaz. A verdade é inconveniente para o usuário, exigindo que você insira algo lá adicionalmente. Suficiente "desagradável" para incorporar no design. Ah, sim ... ainda assim, dependendo da implementação, pode estar sujeito a um ataque de negação de serviço.
Autorização 2F - Tudo está ótimo. É verdade ... na maioria das vezes isso é uma coisa opcional. Ligue-o para combater o ataque não funcionará. Ela está lá ou não está. E em alguns recursos, insira a autorização 2F, digamos, atire pardais do tanque.
Eu tento criar serviços convenientes e confiáveis. Portanto, eu decidi forçar um pouco meu cérebro. E foi o que aconteceu.
Se você usa o mail, por exemplo mail.ru, e possui a autorização 2F instalada, pode ter notado que a autorização 2F é solicitada apenas para um novo "dispositivo" no primeiro login. Além disso, o dispositivo é considerado confiável. E você só precisa digitar seu login e senha.
Coisa conveniente. Fácil de usar, por assim dizer. Isso é implementado por dois tokens. O primeiro identificador é "dispositivo" (definido como devid) e o segundo é um identificador de sessão (definido como sessão). O Devid, diferentemente da sessão, não perde sua relevância mesmo depois que um usuário termina uma sessão. Ele é transmitido na próxima tentativa de login e, se o nome de usuário / senha estiverem corretos, assim como devid trust, 2F não será mais solicitado. Porém, se a próxima tentativa de logon não tiver êxito, o token devid será imediatamente desativado. E agora você precisa seguir o caminho completo da autorização.
Este paradigma foi tomado como base. I.e. insira o token devid, que será emitido constantemente, com qualquer resposta do recurso WEB, é claro, se não estiver na solicitação.
Para o caso de autorização 2F, o algoritmo acima foi realmente implementado. E imediatamente todos ficaram felizes. T.ch. não faz sentido examiná-lo em detalhes. Mas os "sinos e assobios", é melhor considerar o diagrama, com explicações:
Mesmo que a autorização 2F não esteja instalada, mas o logon tenha sido bem-sucedido, o token devid será marcado como confiável. Parece que faz pouco sentido fazer isso sem a autorização 2F. Mas, tudo é um pouco mais complicado. Se sabemos que o devid é confiável, ou seja, ele teve um login bem-sucedido, pelo menos presumimos que foi a partir deste dispositivo que o usuário real entrou. Esta é uma informação muito importante que o algoritmo descrito utiliza em seu trabalho no modo de reflexão de ataques.
Uma estratégia foi adotada: qualquer autorização pode ocorrer apenas se houver um token devid válido. Um devid válido difere de um confiável, pois ainda não é confiável, ou seja, não houve logons bem-sucedidos, mas o sistema está pronto para processar solicitações de autorização. O número de tentativas é limitado a N vezes por token válido. Se um erro de autorização ocorrer mais de N vezes seguidas, o token será marcado como "comprometido". É transferido para um diário separado com estatísticas sobre a seleção. Os pedidos com sua participação continuam sendo processados, mas ... não é mais possível fazer login com ele. Tudo o que acontece é o acúmulo de estatísticas de atividades.
Então os ataques mais estúpidos revidam. Por exemplo, se um invasor, ignorando o devid, tenta efetuar login no sistema, ou se ele não consegue entender a lógica do devid (como ele sabe quantas tentativas de login são feitas com o mesmo devid?), Suas solicitações são encerradas.
A própria frente sabe que, depois de N vezes tentativas malsucedidas de login de um devid, ele já está "podre". Agora você precisa obter um novo token antes da próxima tentativa de login.
Parece, que tipo de estupidez? A frente para cumprir a tentativa de entrar ... mas, como eu disse acima, tudo é mais complicado. Se um usuário trabalha com uma frente padrão, a probabilidade de ele realmente estar tentando atacar o sistema é insignificante. Emparelhado com um sistema de controle de complexidade de senha durante o registro do usuário, isso é completamente inútil. Provavelmente, o usuário real está realmente tentando lembrar sua senha.
Então qual é o truque? No fato de que nas costas geramos o devid muito válido com um certo limite de tempo. Por exemplo, não mais que 1000 unidades por minuto. Se de repente esse limite for excedido, o modo de ataque será cortado. E aqui você pode ir radicalmente e parar a emissão de devidos por algum tempo, o que esfriará o ardor do atacante ou reduzirá a geração de devidos válidos. E você pode ativar o mesmo captcha para todos os devid válidos, mas não confiáveis.
Assim, é obtido um sistema flexível para controlar e gerenciar ataques. Métricas confiáveis são geradas pelas quais o monitoramento pode ser acionado, disparando um alarme. As estatísticas acumuladas podem ser convertidas em regras de bloqueio, etc.
Um sistema amigável é porque os usuários que fizeram o login anteriormente, ou seja, confiei no devid nem percebeu o ataque. Eles serão ignorados pelo sistema sem problemas.
Agora lucre. Este algoritmo está muito bem estabelecido em recursos com uma carga muito alta. Houve, inter alia, tentativas de DoS no próprio algoritmo, mas mesmo aqui ele provou ser digno.