Serviço de autenticação sob ataque e indisponibilidade
O internet banking do banco usa um serviço de autenticação que valida credenciais e emite tokens JWT. Nos últimos três dias, o tempo médio de resposta subiu de 180 ms para 2,4 s, e 12% das requisições retornam HTTP 503. Os logs mostram picos de 40 mil tentativas de login por minuto, vindas de 3 mil IPs distintos, com 99% de falhas de senha e user-agents variados. O banco tem WAF, mas a regra de rate limit está em 5.000 requisições por minuto por IP. O serviço de autenticação usa um banco relacional com pool de 50 conexões e não possui cache de sessão. O time de plantão precisa decidir a ação imediata sem derrubar clientes legítimos.
1. Classifique o incidente e proponha uma sequência de contenção em curto prazo que reduza o impacto sem bloquear usuários legítimos.
Read the worked answer
O padrão - muitas origens, alto volume de falhas de senha, user-agents variados e alvo no login - indica credential stuffing distribuído, não força bruta de um único IP. A contenção deve ser em camadas:
- Rate limit por conta e por ASN/rede, não só por IP, pois o atacante troca de IP. Ex.: limitar tentativas por CPF/usuário e por faixa de rede, com backoff exponencial.
- Desafio adaptativo: CAPTCHA ou prova de trabalho após N falhas por conta, preservando o fluxo de quem acerta a senha.
- Bloqueio temporário de contas sob ataque com notificação ao cliente, evitando lockout permanente.
- Listas de reputação e geoimpedimento para ASNs com histórico, com revisão manual.
- Proteção do backend: aumentar o pool de conexões e adicionar cache de validação de token para reduzir pressão no banco relacional.
A ordem importa: primeiro aliviar o banco e conter a automação, depois investigar. Bloquear IPs isoladamente é ineficaz e arrisca atingir clientes atrás de NAT corporativo.
2. O JWT atual é assinado com HS256 e a chave secreta é compartilhada entre autenticação e APIs de negócio. Avalie o risco e a correção arquitetural.
Read the worked answer
Com HS256, qualquer serviço que conheça a chave pode emitir tokens válidos, não apenas verificá-los. Compartilhar o segredo entre o serviço de autenticação e várias APIs amplia a superfície: um vazamento em qualquer API compromete a emissão de identidade de todo o ecossistema. Além disso, HS256 não permite que terceiros validem sem poder forjar.
Correção: migrar para assinatura assimétrica, como RS256 ou ES256, com a chave privada restrita ao serviço de autenticação e as APIs recebendo apenas a chave pública via JWKS. Aplicar também: iss, aud, exp curtos (5–15 min), rotação de chaves com kid, revogação por lista de refresh tokens e validação de algoritmo no verificador para impedir ataques de confusão de algoritmo (alg: none ou troca para HS256 usando a chave pública). Em cenário de ataque ativo, rotacionar o segredo atual e invalidar tokens emitidos.