Estou tentando tornar meu sistema mais seguro e no momento estou passando por uma questão de prevenção de bruteforce da qual não consigo encontrar uma solução. Atualmente implemento um simples contador na action toda vez que alguém tenta logar e empurro esse contador pra session no retorno da action para em seguida verificar por js o valor antes de prosseguir e, dependendo do valor desse contador exibo ou não um REcaptcha para o usuário.
Meu problema é que se o usuário simplesmente limpar os cookies o contador reseta e ele pode tentar mais N vezes. Essa falha é facilmente exploitável…
Teria alguma forma eficiente de fazer isso trabalhando com a idéia de session? Afinal não quero bloquear um IP pois pode ter vários usuários acessando de uma rede empresarial.
Estou tentando tornar meu sistema mais seguro e no momento estou passando por uma questão de prevenção de bruteforce da qual não consigo encontrar uma solução. Atualmente implemento um simples contador na action toda vez que alguém tenta logar e empurro esse contador pra session no retorno da action para em seguida verificar por js o valor antes de prosseguir e, dependendo do valor desse contador exibo ou não um REcaptcha para o usuário.
Meu problema é que se o usuário simplesmente limpar os cookies o contador reseta e ele pode tentar mais N vezes. Essa falha é facilmente exploitável…
Teria alguma forma eficiente de fazer isso trabalhando com a idéia de session? Afinal não quero bloquear um IP pois pode ter vários usuários acessando de uma rede empresarial.
Obrigado.[/quote]
só manter a session global no servidor. usou 3x incorreto, aparece até a pessoa digitar o captcha ou até exceder um tempo de expiração 30 min por exemplo.
não precisa se preocupar com IP.
imagina quanto tempo leva para um ataque de bruteforce com uma senha que contenha: 8+ caracteres, letras maiusculas e minusculas e numeros. 200+^8+ * 30 minutos
Session também não deve ser muito eficaz, afinal limpando os cookies a associação com a Session vai embora também.
Editado: Mas você pode fazer com o usuário, seguindo a lógica do que o rapaz aí de cima falou. Se errou 3 vezes tem que esperar. A quantidade de erros pode ficar no banco ou mesmo no escopo Application.
Obrigado pelas respostas. O que seria essa session global no servidor?
Achei que a session fosse client side apenas.
Pergunto isso, pois existe uma outra parte do sistema que utiliza um sistema semelhante ao de login onde seria aplicável essa idéia. Realmente para a parte de login com BD deve ser suficiente.
[quote=dambros]Obrigado pelas respostas. O que seria essa session global no servidor?
Achei que a session fosse client side apenas.[/quote]
session fica no servidor,
em .NET C# temos o conceito de Aplication Scope, onde os dados ficam temporariamente guardados na memória do servidor e acessiveis a todos os usuários, sei que o spring prove este mecanismo, mas não sei como funciona.
a idéia do tentativas você não achou legal ?
pode implementar outro lance onde se verifica a quantidade de tentativas erradas para determinado IP para todos os usuários.
dessa forma:
IP xxxxx tenta acesso com usuário dambros1: grava-se +1 na coluna tentativas no registro do usuário dambros, e também grava-se o IP e quantidade de erros no login,
dessa forma se o IP xxxxx tentar acessar 3x com usuário dambros1, 3x com usuário dambros2, 3x com usuário dambros3 etc…a partir de determinado numero de tentativas por IP, você pode colocar esse IP em uma lista negra e verificar se é um atack se bruteforce, se sim, você bloqueia tentativas desse IP
Em instituições bancárias, a quantidade de vezes que alguém erra uma senha fica em uma tabela no banco de dados.
Se isso é realmente preocupante para você, pode tentar fazer algo semelhante.
É óbvio que isso quer dizer que, se o usuário realmente não tiver culpa disso, vai ficar lhe ligando para resetar a senha, o que é sempre algo indesejável porque aumenta os custos de operação do site (você precisaria comprar o serviço de um help desk, o que é surpreendentemente bem caro.)
[quote=entanglement]Em instituições bancárias, a quantidade de vezes que alguém erra uma senha fica em uma tabela no banco de dados.
Se isso é realmente preocupante para você, pode tentar fazer algo semelhante.
É óbvio que isso quer dizer que, se o usuário realmente não tiver culpa disso, vai ficar lhe ligando para resetar a senha, o que é sempre algo indesejável porque aumenta os custos de operação do site (você precisaria comprar o serviço de um help desk, o que é surpreendentemente bem caro.)[/quote]
mas só exibir o captcha não vai fazer o usuário ligar no help-desk.
[quote=douglaskd][quote=dambros]Obrigado pelas respostas. O que seria essa session global no servidor?
Achei que a session fosse client side apenas.[/quote]
session fica no servidor,
em .NET C# temos o conceito de Aplication Scope, onde os dados ficam temporariamente guardados na memória do servidor e acessiveis a todos os usuários, sei que o spring prove este mecanismo, mas não sei como funciona.
a idéia do tentativas você não achou legal ?
pode implementar outro lance onde se verifica a quantidade de tentativas erradas para determinado IP para todos os usuários.
dessa forma:
IP xxxxx tenta acesso com usuário dambros1: grava-se +1 na coluna tentativas no registro do usuário dambros, e também grava-se o IP e quantidade de erros no login,
dessa forma se o IP xxxxx tentar acessar 3x com usuário dambros1, 3x com usuário dambros2, 3x com usuário dambros3 etc…a partir de determinado numero de tentativas por IP, você pode colocar esse IP em uma lista negra e verificar se é um atack se bruteforce, se sim, você bloqueia tentativas desse IP[/quote]
Para a parte de login realmente essa idéia de usar uma tabela resolve meu problema. Agora existe uma outra parte do site que é acessada apenas através de uma chave de acesso e ele enxerga apenas 1 informação. Nessa parte não há o conceito de login, mas o sistema ainda é exploitável pois essa chave pode ser conseguida com brutefoce (mesmo demorando).
[quote=douglaskd]cada caracter a mais na chave aumentará o número de tentativas ao quadrado.
acho que da pra implementar sim, se a chave for grande demais pense no conceito de Token. ou arquivo que contem a chave criptografada etc.
explique um pouco mais sobre esta chave…[/quote]
Essa chave são 8 dígitos aleatórios que é enviado junto da NF do produto e permite que o cara acesse um pdf com algumas informações pelo site. Diferente do site onde ele tem uma visão mais completa quando ele loga, nessa opção por chave ele verá apenas o PDF mesmo.
Acontece que para xploit eu posso simplesmente tentar todas combinações até achar uma válida que me exibirá o PDF. Concordo que não seja muita coisa que ele terá acesso, mas de qualquer forma é xploitável.
Nesse caso não há erro, pois pense:
Tento a chave AAAA-AAAA que é inválida, vou incrementando até chegar na AAAA-AAAZ que é válida. Agora o sistema vai deixar ele passar, mesmo ele já tendo errado N x.
[quote=dambros][quote=douglaskd]cada caracter a mais na chave aumentará o número de tentativas ao quadrado.
acho que da pra implementar sim, se a chave for grande demais pense no conceito de Token. ou arquivo que contem a chave criptografada etc.
explique um pouco mais sobre esta chave…[/quote]
Essa chave são 8 dígitos aleatórios que é enviado junto da NF do produto e permite que o cara acesse um pdf com algumas informações pelo site. Diferente do site onde ele tem uma visão mais completa quando ele loga, nessa opção por chave ele verá apenas o PDF mesmo.
Acontece que para xploit eu posso simplesmente tentar todas combinações até achar uma válida que me exibirá o PDF. Concordo que não seja muita coisa que ele terá acesso, mas de qualquer forma é xploitável.[/quote]
bom, ai é aquela história, quanto mais mordomia menos segurança.
os bancos possuem um mecanismo de comprovantes assim;
você paga um boleto no banco, ele te da a opção de enviar o comprovante no e-mail de alguem, então esse alguem recebe no e-mail com link com acesso a este comprovante que fica disponivel por x dias… se expirar o tempo, a pessoa que pagou o comprovante deve solicitar novamente este envio de código.
[quote=dambros][quote=douglaskd]no seu caso, você quer que seja possivel consultar o PDF pedido, somente com o código, mesmo não sendo o comprador.
bom, será que essas informações do PDF então, não devia conter nenhum dado sigiloso, ou literalmente não existir.[/quote]
Infelizmente é uma regra de negócio esse PDF. Creio que o jeito será utilizar um misto de bloqueio por IP + essa idéia de session inicial, certo?
Caso o IP faça N tentativas, exijo que sempre passe um captcha… [/quote]
algo nesse sentido…
3 tentativas em qualquer código: mostra captha para aquele IP
mas é um paliativo né, se a empresa é grande e possuí apenas um IP externo para 200 computadores que precisam acessar esses PDFs, com certeza sempre aparecerá os captchas. mas ja elimina o bruteforce.
[quote=douglaskd][quote=dambros][quote=douglaskd]no seu caso, você quer que seja possivel consultar o PDF pedido, somente com o código, mesmo não sendo o comprador.
bom, será que essas informações do PDF então, não devia conter nenhum dado sigiloso, ou literalmente não existir.[/quote]
Infelizmente é uma regra de negócio esse PDF. Creio que o jeito será utilizar um misto de bloqueio por IP + essa idéia de session inicial, certo?
Caso o IP faça N tentativas, exijo que sempre passe um captcha… [/quote]
algo nesse sentido…
3 tentativas em qualquer código: mostra captha para aquele IP
mas é um paliativo né, se a empresa é grande e possuí apenas um IP externo para 200 computadores que precisam acessar esses PDFs, com certeza sempre aparecerá os captchas. mas ja elimina o bruteforce.[/quote]
outra solução é o cara colocar uma coluna na tabela login:, tentativas
e ir incrementando a cada tentativa sem sucesso, ao passar de 3, dali pra frente eternamente vai aparecer pedindo captcha até o cara acertar.[/quote]
Alem do captcha poderia pedir alguma outra informação para comprovar que de fato, é a pessoa dona do Login que esta ali, por exemplo, algum dado do cadastro do cliente (ex: data de nascimento, nome do pai, da mãe, cidade onde mora…).