Autenticando aplicações sem trafegar a senha com AWS Cognito

O processo de autenticar o usuário final em uma aplicação corporativa é crítico e concentra muitas das responsabilidades e riscos de segurança. Entre as preocupações, o simples ato de trafegar a senha na requisição para um autorizador dentro da rede a deixa exposta a riscos. Autenticar sem trafegar senhas não só é possível, mas é uma tecnologia prática e acessível que endereça esses riscos, reduzindo a superfície de ataque e facilitando auditorias.

Dentro de uma Virtual Private Cloud (VPC), a requisição é frequentemente descriptografada antes de chegar na aplicação, mesmo quando a transmissão ocorre por https (por exemplo, em um API Gateway ou em um Load Balancer configurado para terminar TLS). A partir daí, a informação atravessa vários componentes internos antes de ser validada, ficando vulnerável a logs inadvertidos, possíveis vazamentos, ou exploração por agentes mal-intencionados.

Esse percurso, embora confinado à rede privada, pode ser inspecionado, monitorado ou rastreado. Em outras palavras, se o tráfego entre componentes da rede interna não estiver protegido por TLS, a confidencialidade termina antes da requisição chegar no autorizador.

Simplesmente criptografar a senha em trânsito ou calcular um hash com uma chave fixa não evita este problema, pois a informação continua sendo válida para obter acesso em caso de vazamento.

É aí que entra o AWS Cognito. Ele é um serviço de autenticação e gestão de identidades com infraestrutura totalmente gerenciada, reduzindo a superfície de ataque, fornecendo recursos de segurança como MFA. Entre as suas funcionalidades, há suporte ao fluxo de autenticação Secure Remote Password (SRP).

O SRP é um protocolo de conhecimento-zero: Ao invés de o usuário provar que conhece a senha enviando-a ao servidor, o dispositivo do usuário e o servidor trocam informações criptográficas para provar matematicamente este conhecimento.

Para ilustrar a diferença, imagine que você precise provar que tem posse de uma chave que abre um certo cadeado, mas sem mostrar a chave a ninguém. Nesse caso, ao invés de pedir para ver a chave, eu te entrego uma moeda com um furo e um cadeado fechado que só abre com essa chave, os dois assinados por mim. Se você conseguir me devolver a moeda presa no cadeado, saberei que você tem posse da chave (ou acesso a ela) sem nunca a ver.

Protocolos conhecimento-zero combinam várias operações criptográficas que, como no exemplo do cadeado, demonstram conhecimento de uma informação secreta que permanece secreta. O resultado é que interceptar o tráfego revela apenas informação que não serve para um invasor falsificar novas requisições.

A senha também não é trafegada na requisição de registro (sign up), porque o cliente envia apenas informações derivadas da senha. Essas informações são usadas nos cálculos criptográficos da verificação, mas não permitem reconstruir a própria senha. Armazenar somente esse tipo de informação derivada não é específico do SRP, mas aqui, a senha não aparece nem mesmo no cadastro.

A experiência do usuário final é exatamente a mesma, só que a senha nunca deixa o dispositivo. A lógica das aplicações back-end também continua sendo a mesma, validando Access Tokens incluídos na requisição; somente o client front-end que dispara a requisição de login precisa ter a certeza de fazer as chamadas corretas ao Cognito.

A implementação é simples: criar um app client no Cognito com o fluxo USER_SRP_AUTH habilitado. Os SDKs, como o Amplify da AWS, se encarregam de realizar as operações matemáticas no próprio dispositivo do usuário. Nenhum cálculo criptográfico precisa ser implementado pelo programador.

import { signIn } from 'aws-amplify/auth'
// Nenhum cálculo criptográfico
// precisa ser implementado.
await signIn({
    username: "usuario@email.com",
    password: "senha",
})

Para as equipes de segurança e governança, outro benefício é reduzir o escopo de conformidade. Como a senha do usuário não é armazenada pela aplicação nem trafegada em nenhum momento, há um ganho em reduzir controles de gestão de segredos exigidos por normas como ISO 27001, já que é garantido que nenhum componente da solução conhece a senha – só o próprio usuário.

É claro, há proteções adicionais como MFA que continuam sendo importantes, e o uso de um Load Balancer e de TLS em trânsito continua sendo tão relevante quanto antes – o Cognito reforça a base. De fato, o Cognito integra nativamente com ainda mais recursos da AWS, como o CloudTrail para trilhas de auditoria e o AWS WAF para bloqueio de ameaças conhecidas nos endpoints do Cognito, como tráfego de origem suspeita e ataques massivos de força bruta. Além disso, ele está incluído no programa de conformidade da AWS, com relatórios de auditoria disponíveis pelo AWS Artifact.

Porém, vale uma advertência: se você estiver migrando contas de outro banco, ou precisar usar logins com fluxo federado, a opção de usar SRP não estará disponível quando a base de usuários estiver fora do Cognito; porém, há caminhos para importar verifiers gerados para possibilitar uma migração. Em novos projetos, usar um protocolo robusto é a primeira opção, e o Cognito oferece uma opção simples de entender, implementar e manter.

Por isso, autenticar o usuário sem transmitir a senha não é apenas uma ideia teórica, é uma prática acessível. Em uma arquitetura que já utiliza um gateway ou load balancer na borda da VPC, mas ainda encaminha senhas para dentro da rede sem TLS internamente, considere adotar um protocolo robusto como o SRP. A mudança traz um grande impacto positivo, pois simplifica auditorias, prepara a arquitetura para exigências regulatórias, reduz os impactos associados a ataques cibernéticos, e tudo isso sem sacrificar a experiência do usuário.

Muralis insigths | Escrito por: Rafael Takahashi, Arquiteto de Software.