Toda página de login pública começa a ser varrida por ferramentas automatizadas pouco depois de entrar no ar. Os atacantes tentam nomes de usuário e senhas previamente vazados, martelam uma única conta com tentativas de senha ou usam bots para abusar do formulário de login.
Esses ataques não se parecem iguais. Às vezes muitas tentativas vêm de um único endereço IP. Às vezes o mesmo nome de usuário é tentado novamente de muitas fontes diferentes. Às vezes senhas vazadas são aplicadas a milhares de contas diferentes em baixa velocidade, em um padrão distribuído.
É por isso que defesas estáticas ficam aquém. Bloquear apenas por IP deixa ataques distribuídos passarem e pode bloquear erroneamente usuários reais que chegam por redes compartilhadas. Bloquear apenas por conta dá aos atacantes outra vantagem — eles podem bloquear muitas contas e causar negação de serviço. Forçar CAPTCHA em cada login único arruína a experiência do usuário real.
O erro maior é deixar a avaliação de bots e riscos no momento do login inteiramente para um serviço de nuvem de terceiros. Esse modelo cria dependência externa, custo por usuário ou por avaliação, problemas de visibilidade de dados e um ponto de interrupção extra no caminho de autenticação.
A proteção de login não deve ser uma parede uniforme. Deve ser uma camada de segurança local que aumenta a fricção conforme o risco aumenta, responde com base na origem e no alvo do ataque e não penaliza usuários reais desnecessariamente.
Porque proteger a página de login não é apenas sobre deter o atacante — é também sobre manter o usuário real capaz de continuar seu trabalho com segurança.
Fricção graduada, política multi-escopo e um desafio auto-hospedado — tudo na plataforma que você já possui.
Cada política roda três limiares: um aviso que aparece no log de auditoria, um desafio CAPTCHA que filtra automação sem bloquear humanos e um bloqueio que fecha a porta completamente. Usuários legítimos raramente veem o segundo estágio e quase nunca o terceiro; atacantes escalam rapidamente.
Cada política se aplica em um de três escopos: por IP de origem, por nome de usuário ou por ambos juntos. Um ataque de força bruta em uma conta de um IP é capturado pelo escopo de IP; credential stuffing em muitos nomes de usuário de IPs rotativos é capturado pelo escopo de nome de usuário; o escopo combinado lida com ataques direcionados que misturam os dois.
O desafio CAPTCHA é gerado no lado do servidor como imagem, com cinco níveis de dificuldade, um charset que ignora caracteres confusos (I, L, O, 0, 1), e cores, dimensões e ruído configuráveis. Não há Google reCAPTCHA, não há Cloudflare Turnstile, não há taxa por avaliação — e o momento mais sensível da autenticação nunca sai do seu perímetro.
Os contadores de bloqueio se coordenam com o mesmo rastreamento de tentativas usado por cada canal MFA. Um usuário não pode fazer força bruta em um fator enquanto outro fator fica em uma tentativa paralela, e um CAPTCHA acionado na etapa de senha se propaga para o restante do fluxo que protege a mesma identidade.
Os primitivos de defesa em detalhes, mais o roadmap que os aprofundará.
Cada política é vinculada a um dos três escopos. O escopo de IP captura um único atacante martelando muitas contas de uma rede. O escopo de nome de usuário captura credential stuffing onde cada tentativa rotaciona o IP de origem. O escopo combinado captura o caso direcionado onde um atacante conhecido foca em uma conta específica de uma rede específica.
Cada política roda três limiares que escalam em ordem. O limiar de aviso sinaliza atividade suspeita no log de auditoria sem afetar o usuário. O limiar de CAPTCHA coloca um desafio de imagem auto-hospedado na frente da próxima tentativa. O limiar de bloqueio fecha a porta por uma duração configurável — e a ordem, os valores e a janela de decaimento são todos por política.
CAPTCHAs são gerados localmente como imagens — cinco níveis de dificuldade de dicas de leitura leve a distorção pesada, cores e dimensões configuráveis para combinar com a marca, e um charset que omite intencionalmente caracteres visualmente similares (I, L, O, 0, 1) para manter a experiência do usuário legítimo limpa.
A proteção de login é gerada, servida, validada e auditada inteiramente na plataforma. Não há taxa por avaliação, sem dependência externa, sem implicação de privacidade de enviar cada tentativa de login a um fornecedor, e sem serviço de pontuação opaco entre seus usuários e sua autenticação.
Tentativas de senha falhadas, desafios MFA falhados e respostas CAPTCHA falhadas alimentam contadores coordenados por escopo de política. Um atacante não pode fazer força bruta em um fator enquanto uma tentativa paralela espera em outro, e um bloqueio acionado em um passo se propaga para cada canal que protege a mesma identidade.
Cada política define uma janela de decaimento. Tentativas falhadas mais antigas que a janela param de contar para os limiares atuais, de modo que um usuário legítimo que digitou a senha errada três vezes na semana passada não começa hoje já no estágio de CAPTCHA. A janela, o formato de decaimento e os limiares são todos ajustáveis por política.
Cada tentativa de login — sucesso, aviso cruzado, CAPTCHA acionado, bloqueio disparado — escreve uma entrada de auditoria estruturada com timestamp, IP de origem, user agent, escopo e resultado da política. Informações do destinatário (e-mail, telefone) são mascaradas no fluxo de auditoria por padrão para que a trilha de auditoria não se torne um caminho secundário de vazamento.
Um motor de correlação planejado vinculará contadores de tentativas entre serviços, de modo que um atacante que testa credenciais em uma aplicação de baixo valor não possa então se mover para uma de alto valor com um histórico limpo. Feeds de reputação de IP serão integrados ao mesmo motor de política para escalar automaticamente a fricção para redes notoriamente maliciosas.
Os mecanismos que fazem a defesa graduada parecer invisível para bons usuários e clara para atacantes.
Cor de fundo, cor do texto, largura, altura, tamanho de fonte, espaçamento de caracteres, linhas de ruído e pontos de ruído são todos configuráveis. O desafio pode combinar a identidade visual do portal de login que protege sem revelar que um serviço externo está envolvido — porque nada externo está envolvido.
O charset padrão ignora I, L, O, 0 e 1 — caracteres que são fáceis de confundir entre si em forma distorcida. Usuários legítimos resolvem CAPTCHAs mais rápido e com menos tentativas; o valor defensivo contra resolvedores automatizados é preservado em todos os níveis de dificuldade.
Limiar de aviso, limiar de CAPTCHA, limiar de bloqueio, janela de decaimento e duração de bloqueio são todos configuráveis por política. Uma interface de gerenciamento de usuários tem tolerâncias diferentes de um login público de help desk ou um console administrativo; o mesmo motor os serve com números diferentes.
Contadores e estado de bloqueio vivem no Redis, de modo que qualquer pod de gateway pode ver o número atual de tentativas para qualquer escopo. Implantações com escalonamento horizontal veem estado consistente sem sobrecarga de coordenação, e uma decisão de bloqueio tomada em um pod é imediatamente visível para todos os outros pods.
Um usuário bloqueado ou espera o bloqueio expirar no seu próprio relógio ou é desbloqueado por um administrador pela interface de administração do gateway. A ação de recuperação é ela mesma auditada; um desbloqueio de emergência durante um incidente é um evento rastreável em vez de uma solução invisível.
Limiares adaptativos que se apertam automaticamente quando uma fonte upstream de inteligência de ameaças sinaliza risco aumentado — redes sabidamente maliciosas, campanhas ativas de credential stuffing, listas de credenciais vazadas — estão no roadmap. O mesmo motor de política recebe o sinal; a mesma trilha de auditoria registra a mudança.
Um atacante com uma lista de usuários/senhas vazados rotaciona IPs e tenta cada par na página de login. Políticas de escopo de nome de usuário capturam esse padrão — contadores sobem por conta, o estágio de CAPTCHA filtra automação e o bloqueio fecha a porta para alvos repetidos.
Um único atacante, um único IP de origem, uma única conta alvo, muitas tentativas. Políticas de escopo de IP capturam isso em segundos — o aviso aparece na auditoria, o estágio de CAPTCHA filtra tentativas scriptadas e a duração do bloqueio se multiplica rápido o suficiente para tornar o ataque antieconômico.
Agentes automatizados tentam fazer login para fazer scraping, spam ou aguardar uma conta desbloqueada. O estágio de CAPTCHA é exatamente onde esses são capturados — gerado localmente, validado localmente e completamente fora do alcance de serviços automatizados de resolução de CAPTCHA que visam desafios SaaS externos.
PCI-DSS, HIPAA e ISO 27001 exigem evidência de que o monitoramento de login falhado está em vigor, com limiares e trilhas de auditoria. O fluxo de auditoria por tentativa dá ao auditor uma única linha do tempo para revisar, com limiares expressos como configuração em vez de texto escrito.
Fricção graduada em três estágios, cobertura de política em três escopos e CAPTCHA auto-hospedado — tudo na plataforma que você já possui. Vamos percorrer uma implantação ao vivo nas suas aplicações.