A redefinição de senha é o ponto fraco silencioso da maioria dos stacks de acesso
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.
Nossa abordagem
Três fluxos coordenados, todos rodando no mesmo gateway que login e MFA.
Alteração autenticada para o usuário que conhece a senha
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.
Solicitação de esqueci a senha que não vaza identidade
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.
Redefinição com token de e-mail de uso único
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.
Cada operação está no log de auditoria
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.
Capacidades
Três fluxos em detalhe.
Alteração autenticada que valida a senha atual
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.
Fluxo de solicitação de esqueci a senha com resposta neutra
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.
Link de redefinição de e-mail de uso único e janela curta
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.
Mascaramento do destinatário em todas as superfícies de UI
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.
Abstração de provedor — as senhas ficam onde pertencem
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.
Proteção CSRF em cada submissão de formulário
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.
Profundidade operacional
A mecânica que mantém os fluxos de senha self-service seguros na camada de acesso.
Action tokens de uso único com TTL curto
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.
Estado de token coordenado via Redis entre pods de gateway
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.
Roteamento de provedor de identidade baseado em serviço
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.
Tratamento criptografado em trânsito e em repouso
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 é.
Coordenado com os contadores de login-attack-protection
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.
Em quais cenários é usado
Rotação self-service rotineira
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.
Recuperação de esqueci a senha
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.
Onboarding e offboarding de contratado
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.
Evidência de conformidade sobre o tratamento de credenciais
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.
Perguntas frequentes
Por quanto tempo o link de e-mail de redefinição de senha permanece válido?
O formulário de esqueci a senha vaza se uma conta existe ou não?
Onde vivem hoje as regras de complexidade — comprimento, classes de caracteres, histórico?
Um usuário pode alterar a senha enquanto está logado?
O que acontece se um usuário perder tanto a senha quanto o acesso ao e-mail de recuperação?
Traga as operações de senha para o mesmo motor que o login
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.