O fluxo de redefinição de senha é um dos caminhos mais visados de qualquer sistema de autenticação. Os atacantes sabem que, se conseguirem disparar uma mensagem de redefinição para um endereço que controlam, reproduzir um link de redefinição vazado ou entrar no formulário de alteração com uma sessão roubada, contornam todas as defesas do momento do login que a plataforma oferece.
Muitos gateways tratam a redefinição como algo adicionado depois: links de redefinição de vida longa, endereços de destinatário visíveis em aberto na UI, formulários de alteração de senha sem CSRF e ausência de auditoria sobre quem redefiniu o quê e quando. Cada um é uma pequena lacuna; juntos, formam uma porta lateral paralela à parede de MFA da porta da frente.
O outro extremo — manter as operações de senha desajeitadas e abertas apenas ao administrador — produz transbordamentos da central de suporte, senhas de administrador compartilhadas em post-its e usuários que nunca alteram as credenciais porque o processo é difícil.
As operações de senha devem ser self-service, seguras e auditadas de ponta a ponta — o mesmo motor que defende o login deve defender também a alteração, o esqueci e a redefinição.
Três fluxos coordenados, todos rodando no mesmo gateway que login e MFA.
Um usuário logado altera sua senha inserindo a senha atual e a nova. Action tokens, proteção CSRF e janelas curtas de uso único defendem o formulário de alteração contra replay de sessão e exploração cross-site; a operação vive no mesmo fluxo de auditoria que todas as demais decisões de acesso.
Um usuário que não consegue fazer login insere a identidade de usuário no formulário de esqueci. A UI não confirma se a conta existe — sempre mostra a mesma resposta neutra — e a mensagem de redefinição é entregue através do provedor de identidade configurado; assim, o endereço nunca é revelado de volta a quem solicita.
O link de redefinição carrega um token de uso único e com limite de tempo armazenado no Redis. Uma vez consumido, o token é invalidado; quando a janela expira, o link morre. Reproduzir uma URL de redefinição vazada falha, e o caminho para recomeçar para quem fez a solicitação original é claro.
Tentativas de alteração, solicitações de esqueci, consumos de link de redefinição e rejeições de política escrevem entradas de auditoria estruturadas. O fluxo de auditoria é alimentado ao destino SIEM da plataforma; assim, padrões da central de suporte, concentrações de anomalias e eventos individuais ficam visíveis a partir da mesma linha do tempo que a telemetria de login.
Três fluxos em detalhe — mais a expansão de política no roadmap.
O usuário logado abre o formulário de alteração, fornece a senha atual junto com a nova; e o gateway valida o valor atual através do provedor de identidade configurado antes de aplicar o novo valor. Tokens CSRF, action tokens de uso único com TTL curto e log de auditoria protegem toda a operação.
Um usuário anônimo insere a identidade de usuário no formulário de esqueci. A resposta é a mesma independentemente de a conta existir ou não — sem vazamento de enumeração de conta, sem caminhos de erro diferentes. Se a identidade de usuário corresponder a uma conta real, o provedor de identidade configurado gera um token de redefinição e o envia ao endereço registrado do usuário.
Os links de redefinição carregam um token armazenado no Redis que o gateway valida na chegada do link. Os tokens são de uso único e com limite de tempo — uma vez consumido, o token é invalidado, e quando a janela configurada expira, o link para de funcionar. Reproduzir um link vazado ou usar um e-mail encaminhado após a expiração da janela falha de forma limpa.
Os endereços de e-mail, números de telefone e valores de identidade de usuário exibidos de volta ao usuário nos fluxos de esqueci e redefinição são sempre mascarados. Um atacante que conhece a senha mas não possui a caixa de entrada não consegue ler o endereço de destino; quem olha por cima do ombro de outra pessoa não consegue coletar os detalhes de contato.
O AAM não armazena senhas diretamente. As ações de alteração, esqueci e redefinição delegam ao provedor de identidade que é o proprietário da credencial — LDAP/AD, banco de dados local, OIDC pass-through ou outro provedor configurado. O fluxo permanece o mesmo; o armazenamento fica no provedor em que você já confia.
Cada formulário de senha — alteração, esqueci, redefinição — requer um token CSRF válido vinculado à sessão do usuário ou ao contexto da ação. As requisições cross-site que tentam explorar a página de senha de um usuário logado falham no gateway antes de chegarem ao provedor de identidade.
As regras de complexidade — comprimento, classes de caracteres, rejeição de senhas fracas/vazadas, horizonte de histórico — são hoje aplicadas por cada provedor de identidade. Uma política central no nível AAM, com um único conjunto de regras configurável que se sobrepõe a todos os provedores, está no roadmap; assim, as equipes de conformidade podem expressar uma única política e fazê-la ser avaliada em cada backend.
A política de rotação de expiração de senha e a integração com listas de credenciais vazadas (para que os usuários não possam definir uma senha conhecida em um vazamento público) estão no roadmap. O mesmo fluxo de auditoria registrará os eventos de rotação forçada e as rejeições de lista de vazamentos junto com as operações de ciclo de vida comuns.
A mecânica que mantém os fluxos de senha self-service seguros na camada de acesso.
As operações de senha usam action tokens de uso único deliberadamente com janela de tempo curta. O action token do formulário de alteração vive por 30 segundos enquanto está aberto; o token do link de redefinição vive apenas durante a janela configurada. Replay, encaminhamento de link e exploração de token de sessão batem primeiro nessas janelas curtas.
A geração e o consumo de token vivem no Redis; assim, qualquer pod de gateway pode validar qualquer token. As implantações escaladas horizontalmente permanecem consistentes sem sobrecarga de coordenação; um token consumido em um pod torna-se inválido instantaneamente em todos os demais pods.
Cada serviço pode mapear as operações de senha para um provedor de identidade diferente — LDAP/AD para funcionários, banco de dados local para contratados, OIDC pass-through para identidades federadas. A superfície do fluxo permanece a mesma; os usuários sempre veem uma experiência de senha consistente.
Os valores de senha só são transportados via TLS e nunca são gravados em log, nunca refletidos em mensagens de erro, nunca exibidos no console de administração. Os metadados do operador (hora da última alteração, estado de bloqueio, tentativas de redefinição) são visíveis; a própria senha não é.
Tentativas de alteração falhas, links de redefinição expirados e submissões abusivas do formulário de esqueci alimentam os mesmos contadores de tentativa que a camada de login-attack-protection da plataforma usa. Um atacante não pode fazer brute do formulário de alteração enquanto aguarda uma tentativa paralela na página de login.
Um fluxo oficial de recuperação assistido pelo administrador para usuários que perderam seus autenticadores e o e-mail de recuperação está no roadmap. O fluxo reexecutará a autenticação, gerará um novo registro e criará um único registro auditado para a ação de recuperação.
Os usuários rotacionam suas senhas a partir da página de perfil sem abrir um chamado na central de suporte. O mesmo gateway que lhes concede login também lhes concede a alteração da credencial, e a operação cai no mesmo fluxo de auditoria que o restante das atividades de sessão.
Um usuário que não consegue fazer login solicita uma redefinição, conclui com um link de e-mail de uso único dentro da janela configurada e volta ao trabalho. Sem envolvimento da central de suporte, sem senha temporária compartilhada, sem e-mail de recuperação em texto puro preso como uma porta lateral.
Os contratados entram com um fluxo de alteração obrigatória no primeiro login e saem com uma redefinição disparada pelo administrador; a redefinição invalida instantaneamente todas as sessões ativas. Os momentos de ciclo de vida produzem entradas de auditoria visíveis à equipe de segurança.
As auditorias de PCI-DSS, HIPAA, GDPR e ISO 27001 procuram evidências de que as operações de senha são registradas, mantidas no escopo e não expostas em texto puro. O fluxo de auditoria por tentativa e a UI de destinatário mascarado produzem essa evidência como subproduto da operação normal.
Alteração, esqueci e redefinição — três fluxos seguros, uma única auditoria, sem porta lateral em texto puro. Vamos guiá-lo por uma instalação ao vivo nas suas próprias aplicações.