Ajuda em encontrar uma outra solução

[Omar~ 87]

Então, queria uma ajuda do pessoal que pudessem dar sugestões/idéias sobre como fazer algo assim de forma eficiente.

 

Uma das condições seria.... Por exemplo, ao falhar digitando errado no processo de login X vezes, bloquear aquela pessoa de tentar logar novamente durante um período de tempo.

Certo, mas isso é fácil, vejam uma questão que pensei.

<?php
if (isset($_COOKIE['errou']) && $_COOKIE['errou'] == 3) {
    setcookie('bloqueio', true, time() + (60 * 5), '/');
} else if (isset($_COOKIE['errou'])) {
    $up = $_COOKIE['errou'] += 1;
    setcookie('errou', $up, time() + (60 * 2), '/');
} else {
    setcookie('errou', 1, time() + (60 * 2), '/');
}
echo ("<pre>");
var_dump($_COOKIE);

No caso aqui se errou 3x um novo cookie é gerado, então no login checaria a existência desse cookie se sim não executaria o restante do código.

Beleza, funciona né.... Porém.....

Vamos supor que a pessoa configurou o navegador para não armazenar dados de navegação, ou o mesmo está em janela anônima, basta que ele fechando e abrindo o navegador para tentar descobrir senhas alheias.

 

Recentemente um amigo me passou um programa que ele mesmo fez ao qual faz isso: Abre o browser, acessa website e tenta logar com dados aleatórios, e armazena esses dados para não usar novamente, e fica repetindo a ação até descobrir o acesso de qualquer pessoa executando o login, foi até assustador a velocidade com que ele descobre dados de acesso! E foi por isso que me veio a preocupação de achar uma solução eficiente.

 

Lógico um captcha já solucionaria isso, mas francamente é muito chato obrigar o usuário a ter que ficar digitando um código para logar.

 

Outro caso que pensei seria armazenar no banco o IP e dados peculiares da máquina cujo teve erro ao logar. Mas isso não é eficiente, uma vez que isso não possui precisão, e o bloqueio pode acontecer com quem não tem nada haver com a história.

[Matheus Tavares 167]

2 horas atrás, Omar~ disse:

Lógico um captcha já solucionaria isso, mas francamente é muito chato obrigar o usuário a ter que ficar digitando um código para logar.

Concordo que um captcha é chato, mas:

1 - Você conhece aquele captcha do google onde você simplesmente clica em "Não sou um robô"?

2 - Você pode colocar o captcha apenas após a segunda tentativa falha. E apenas depois tomar outras atitudes.

 

Sobre o IP, você pode bloquear se for um IPv6, pois não tem o problema da "imprecisão", já que ele é único para cada dispositivo.

Se for um IPv4, que é mais comum obviamente, você pode bloquear assim, por exemplo: sha1( IP + USER_AGENT ).

Isso iria pegar toda a descrição do navegador/sistema do usuário, com versão e tudo mais, unir com o IP e bloquear com uma razoável margem de segurança de que não estaria bloqueando outros usuários juntos indevidamente.

 

Daí você me diz: bom, ele pode mudar IP, pode mudar de navegador ou até mesmo declarar um user agent qualquer.

Sim, ele pode. Mas você já dificultou em 50% o processo que ele terá, que unidos com o captcha na X tentativa, vão impedir os ataques.

[BrunoBit 82]

Cookie nesse caso pode descartar, não é eficiente. O que você está procurando se chama Rate Limit:

https://github.com/sunspikes/php-ratelimiter

https://github.com/touhonoob/RateLimit

Tem vários outros e tem uns tutoriais ensinando a fazer também.

 

 

[Matheus Tavares 167]

Ah, uma forma muito eficiente de prevenir SPAM (e XSRF) é utilizando tokens. Veja um exemplo: https://pt.wikihow.com/Prevenir-Ataques-CSRF-em-PHP

Essa proteção é muito importante.

 

Outra que me lembrei, que não é tão eficaz, mas ajuda e é bem simples de implementar, é essa:

Coloque um input text com display:none com um name que pareça ser importante. Exemplo:

<input type="text" name="confirmation" id="confirmation">
<!-- e no css define que esse cara possui display:none -->

Agora basta verificar se esse campo foi digitado. Se for um bot automático (e não um ataque premeditado), vai enviar o form com isso preenchido, daí você bloqueia.

[Omar~ 87]

3 horas atrás, Matheus Tavares disse:

 

Outra que me lembrei, que não é tão eficaz, mas ajuda e é bem simples de implementar, é essa:

Coloque um input text com display:none com um name que pareça ser importante. Exemplo:

<input type="text" name="confirmation" id="confirmation">
<!-- e no css define que esse cara possui display:none -->

Agora basta verificar se esse campo foi digitado. Se for um bot automático (e não um ataque premeditado), vai enviar o form com isso preenchido, daí você bloqueia.

 

 

Na verdade contra o programa que mencionei, testei e funciona como era de se esperar. Algo simples, que por sua vez um BOT não pode distinguir o que é válido um inválido em um formulário.

Eficiente com exceção se algum sacana querer mesmo ferrar o sistema de alguém, o que ele teria que estudar o código fonte do html e css para configurar seu programa de ataque para ignorar isso. Em todo caso daria um trabalho a mais para o sujeito.

 

Na verdade a questão de inputs aleatórios passou por minha cabeça. Pois acredito eu que o modo mais eficiente contra isso é fazer com que um programa automatizado não saiba o que fazer.

 

3 horas atrás, BrunoBit disse:

Cookie nesse caso pode descartar, não é eficiente. O que você está procurando se chama Rate Limit:

https://github.com/sunspikes/php-ratelimiter

https://github.com/touhonoob/RateLimit

 

Sim já conhecia isso, achei também viável.

 

Sobre dados da máquina + IP, USER_AGENT etc... Em testes, máquina idênticas em rede lan não foi possível distinguir uma da outra.

 

O caso do login foi só uma das pautas pois esse caso é mais fundo, recentemente mesmo aqui o iMasters sofreu um ataque similar, onde diversos tópicos foram criados. (Para mim quem planeja isso é uma pessoa sem carácter mesmo, pois não existe ganho pessoal ou material em tal ação)

 

Agora, tal segurança é desnecessário mediante a importância da aplicação. Então antes que algum leigo leia esse tópico e fique preocupado é bom deixar claro essa questão. Se você tem lá seu blogzinho... site... sei lá, algo que não armazene dados importante das pessoas não há o que se preocupar, dificilmente ou quase impossível alguém irá lançar um tipo de ataque contra sua aplicação.