Aumentar proteção nos processos de Cadastro e Login

[filipedeschamps]

Contexto

Apesar de que hoje temos um Firewall que, na medida do possível, identifica abusos e desfaz operações, é interessante dificultarmos abusos (por automações) e com isso veio a idéia de implementar um CAPTCHA na hora do Cadastro e Login.

Execução

Dois pontos a se considerar:

Segurança VS Usabilidade

Aqui batemos naquela velha história de, quanto mais seguro um sistema é, pior é a usabilidade dele. Então sugiro não destruirmos a usabilidade simples do TabNews e implementar um CAPTCHA que seja simples de resolver, como aquele de dar um único clique ou qualquer outra forma que seja simples. Mas a minha preocupação não é com o client do TabNews, mas sim com clients externos.

Clients externos

O que fazer neste caso? Pois hoje é tão simples bater na API e criar um usuário, ou criar uma sessão. Ao implementar este recurso nós iremos destruir esta funcionalidade para clientes que não possuem uma interface convencional, como um TUI (Text-based user interface).

[filipemoraes]

Uma das soluções para o frontend do Tabnews seria utilizar o reCAPTCHA v3 que sequer necessita de qualquer resolução por parte do utilizador. A versão 3 retorna um token e associado a esse token um score com base na interação. Com o token enviado pelo frontend, no backend (através da API do Google) é possível recuperar qual o score e decidir se o pedido segue em frente ou será bloqueado. O bom dessa versão é que o proprietário do software decidi até que ponto está disposto a arriscar pedidos com baixo score. Outro ponto positivo é que o utilizador não é "atormentado" com aquela modal para resolver praticamente um enigma e sequer precisa dar um check em um checkbox e declarar que não é um bot, é tudo em background.

Clients externos

Uma vez que o Tabnews também é utilizador da própria API, outra solução seria o utilizador definir um token na área privada e utilizar esse token nos requests. Utilizo essa solução em serviço de terceiros, onde preciso registrar um access token na área de cliente para poder utilizar na API e esse token está limitado a X requests por segundo.

Como utilizar o token na API de cadastro se preciso ter uma conta com um token válido?

Presumo que essa funcionalidade será utilizada por terceiros que já estejam previamente registados no Tabnews e com um token válido. O token representa um client válido e que está associado a uma conta válida no Tabnews.

Mesclar as 2 soluções

Uma outra solução seria utilizar as 2 opções, reCaptcha ou access token. A API poderia identificar se o request possui uma das 2 propriedades e decidir qual strategy utilizar. Para interface gráfica espera-se um recaptcha token, via TUI espera-se um access token.

[rodrigoKulb]

Podemos montar um CAPTCHA próprio que brinca com o usuário, basicamente montando palavras de tecnologia, exemplo:

• php mysql
• banco de dados
• javascript
• postgre

Não iria diferenciar caixa alta de caixa baixa. E o resultado dessa API poderia ser ID e um base64 com a imagem contendo o texto da frase. Assim os clientes que utilizaram a API também podem utilizar o CAPTCHA!

Apenas completando desta forma vamos bloquear o cadastro / login via robô, então se alguém utilizar a API para cadastro ou login precisará de uma pessoa para validar o CAPTCHA.

[eletroswing]

@rodrigoKulb @aprendendofelipe

Podemos montar um CAPTCHA próprio que brinca com o usuário, basicamente montando palavras de tecnologia, exemplo:

Indo um pouco para aspectos técnicos. Tipo, ter uma tabela só de captchas onde tenho um 'id', o valor, se foi ou não validado podendo ser um enum tipo "não usado", "Invalidado", "Valido" e a conta associada? Assim poderia ter uma métrica disso, ou sem alguns campos ou até, sem uma tabela em banco de dados?

[aprendendofelipe]

Apesar de que hoje temos um Firewall que, na medida do possível, identifica abusos e desfaz operações, é interessante dificultarmos abusos (por automações) e com isso veio a idéia de implementar um CAPTCHA na hora do Cadastro e Login.

Acho que essa ideia foi antes de conseguirmos bloquear totalmente qualquer acesso direto sem passar pela Cloudflare, ou não foi?

Agora que não tem como desviar da Cloudflare, será que vamos conseguir implementar algo melhor do que o serviço deles? Ou o "implementar" era no sentido de adotar algum serviço do tipo, e não desenvolver algo próprio?

Se era no sentido de adotar algum serviço, então já está feito, pois a Cloudflare já identifica e bloqueia os bots, e com impacto quase nulo na experiência dos usuários.

Não acho que valha a pena prejudicar a experiência dos usuários, sendo que, a princípio, já estamos protegidos em certo nível contra abusos envolvendo bots, e o melhor é que ainda permitimos bots que não abusam, como as automações justificáveis, sejam da Turma ou indexadores, e também os aplicativos desenvolvidos pela Turma.

Não acho que essa proteção da Cloudflare seja perfeita, longe disso, mas acho inviável implementarmos algo com um equilíbrio melhor.

Caso a ideia seja mesmo implementar algo próprio, então alguns pontos que devem ser observados são:

• Permitir a adoção opcional por um período razoável para dar oportunidade aos aplicativos da Turma se adequarem;
• Para manter a acessibilidade, é preciso ter diferentes versões, como em áudio e imagem;
• Precisa ter métricas para sabermos se o sistema está sendo efetivo na proteção ao mesmo tempo que não está prejudicando demais a experiência dos usuários;
• Enquanto não houver dados suficientes para sabermos que não estamos impedindo acessos legítimos, deve ser fácil ignorar o captcha.
• A parte pública da implementação não pode facilitar burlar a proteção.

[aprendendofelipe]

Encerrando a issue devido a implementação do Turnstile no PR #1613.