Ferramentas para desenvolvedores · Gerador UUID
Um UUID aleatório é seguro como redefinição de senha ou token de sessão?
· Por que é importante
uuid criptografia APIs do navegador
Um UUID v4 de um CSPRNG tem muita entropia, então por que os revisores de segurança ainda desaprovam os tokens UUID? Esta postagem separa a questão da entropia da questão do design.
O link de redefinição que usa o UUID da linha — um atalho comum e dois motivos muito diferentes pelos quais pode ser inseguro
Um atalho comum: use o identificador de linha UUID do usuário como token de redefinição de senha. A tabela possui uma coluna uuid; é único; é difícil adivinhar (se for um v4). O URL é /reset? token=550e8400-e29b-41d4-a716-446655440000. Um revisor de segurança o rejeita imediatamente, não porque o UUID seja fraco, mas porque une duas preocupações que deveriam ser independentes. A linha UUID é estável e geralmente visível publicamente (em URLs, APIs, logs). O token de redefinição deve ser de uso único e secreto. Reutilizar a linha UUID como um token significa que a identidade do usuário e sua credencial de redefinição têm o mesmo valor e a credencial dura para sempre em vez de expirar. Um invasor que conhece o ID do usuário pode realizar uma redefinição. Um usuário que copiou e colou um link de redefinição há cinco anos ainda pode usá-lo. Estas são falhas de design, não falhas de entropia.
Verificação de entropia: 122 bits aleatórios - por que um v4 gerado por CSPRNG não pode ser adivinhado por força bruta
A verificação da aleatoriedade é necessária, mas não suficiente. A versão 4 reserva quatro bits de versão e dois bits variantes, deixando 128 - 4 - 2 = 122 posições aleatórias quando a implementação preenche os outros campos aleatoriamente. Essa derivação nada diz sobre expiração, armazenamento ou autorização. A verificação do gerador pergunta se esses campos vieram de um CSPRNG em vez de Math.random ou de um carimbo de data/hora. ToolAcre satisfaz o limite do gerador. A verificação de design permanece específica do aplicativo: uma credencial de redefinição precisa de um ciclo de vida separado, uma representação armazenada unidirecional, invalidação após uso bem-sucedido e uma expiração escolhida na política de risco do serviço. A reutilização do ID de registro permanente do usuário falha nessa separação, mesmo quando o ID foi gerado com segurança.
Verificação do gerador: onde os tokens UUID realmente falham — geração baseada em Math.random, carimbos de data/hora v1 e endereços MAC e sementes previsíveis
Um exemplo prático: um esquema de redefinição de senha que falha e depois passa nas três verificações. Falha na verificação de entropia: o servidor emite um token de redefinição via Math.random(), compactado como v4 UUID. Um invasor observa três tokens e prevê o quarto. Falha na verificação do gerador: o servidor usa um UUID v1 como token de redefinição, incluindo o carimbo de data/hora de criação e o endereço MAC no valor. Um invasor lê o carimbo de data/hora, descobre quando a redefinição foi emitida e restringe a janela de pesquisa. Passa na verificação de entropia, mas falha na verificação de design: o servidor usa um UUID v4 de crypto.getRandomValues, mas o armazena em texto simples no banco de dados e não define uma expiração. Um invasor que viola o banco de dados lê tokens de redefinição e os usa para redefinir contas semanas depois. As três verificações são independentes; você deve passar por todos os três.
Verificação de design: identificador versus credencial — por que reutilizar a chave primária de um registro como um segredo une duas coisas que deveriam girar independentemente
Um esquema de token de redefinição que passa nas verificações de entropia e gerador, mas falha na verificação de design (sem hash, sem expiração, sem invalidação por uso) ainda é vulnerável. Tratamento do token no lado do servidor: quando um usuário solicitar uma redefinição de senha, gere um novo token aleatório (não a linha UUID) de crypto.getRandomValues. Armazene uma representação unidirecional em vez do valor apresentado, defina uma expiração específica da política e invalide o registro após o uso bem-sucedido. Quando o usuário clicar no link, procure o usuário por e-mail, busque o hash armazenado, compare o token fornecido com o hash, verifique a expiração e execute a redefinição somente se o token for válido e ainda não tiver expirado. Invalide imediatamente o token (exclua-o ou marque-o como usado) para que não possa ser reutilizado. Nunca registre o token bruto; registre apenas o ID do usuário e a ação.
Manipulação do token no lado do servidor – armazene um hash, defina uma expiração, invalide no uso e nunca registre o valor bruto
O token nunca deve aparecer em mensagens de erro ou no banco de dados, a menos que esteja com hash. O design de autenticação completa está além do escopo de um artigo UUID, mas os princípios são válidos: um token aleatório de 122 bits não é inerentemente um token de acesso. A aleatoriedade é a parte fácil; o gerador ToolAcre fornece UUIDs apoiados por CSPRNG. A parte difícil é o design: hashing antes do armazenamento, definição de prazos de validade, invalidação no uso, prevenção da reutilização de IDs permanentes como segredos temporários, auditoria de quem acessou o quê e quando. Um revisor de segurança que aprova um esquema de link de redefinição baseado apenas na entropia do token está pulando o restante da análise. Um desenvolvedor que pensa que um CSPRNG apoiado por UUID é suficiente para um link de redefinição de senha sem hash, expiração e invalidação está subestimando a ameaça. A aleatoriedade defende contra adivinhações; o design protege contra repetição, expiração e uso indevido.
Exemplo resolvido - revisando um esquema de link de redefinição em relação a cada verificação e reescrevendo as partes fracas
O gerador ToolAcre faz a parte da aleatoriedade corretamente; o aplicativo deve fazer a parte do design corretamente. Teste seu próprio código de link de redefinição em todas as três verificações: ele usa CSPRNG (crypto.getRandomValues, crypto.randomUUID ou uma biblioteca de criptografia), não Math.random? O token tem prazo de validade? O token é criptografado antes do armazenamento? O token é invalidado após o uso? O código evita a reutilização do ID permanente do usuário como token temporário? Se você responder sim a todas essas perguntas, o design do seu link de redefinição é correto. O gerador ToolAcre é a parte CSPRNG; o resto é código do aplicativo que você deve revisar cuidadosamente. Compreender as três camadas de segurança ajuda você a auditar bibliotecas e estruturas UUID de terceiros. Ao avaliar uma biblioteca, verifique se ela usa um CSPRNG (verificação de entropia), e não uma fonte aleatória fraca. Verifique se documenta quais fontes usa e por quê (verificação do gerador).
O que isso não cobre – design de autenticação completo, MFA e limitação de taxa, que são tão importantes quanto a entropia do token
Verifique se o código de exemplo e a documentação enfatizam os princípios de design: hashing, expiração, invalidação (verificação de design). Bibliotecas que passam nas três verificações são raras; a maioria se concentra apenas na entropia. O gerador ToolAcre passa nas verificações de entropia e gerador usando crypto.getRandomValues. A verificação do projeto é de sua responsabilidade; a biblioteca não pode saber seus requisitos de expiração ou estratégia de hash. A depuração de um sistema de link de redefinição quebrado geralmente revela uma das três falhas. Se os usuários relatarem o recebimento de links de redefinição que não funcionam mais, o problema provável é a expiração: o token foi emitido, mas expirou antes de o usuário clicar no link. Se os tokens forem reutilizados várias vezes, a invalidação será interrompida. Se os tokens aparecerem em mensagens de erro ou na saída de depuração, o registro em log os está vazando. Se os links de redefinição funcionarem para um usuário, mas não para outro, pode haver atraso na replicação do banco de dados ou problemas de fuso horário com o cálculo de expiração. Se as solicitações de redefinição legítimas falharem aleatoriamente, o CSPRNG poderá ser quebrado (raro).
Conclusão: a aleatoriedade é a parte fácil — o gerador ToolAcre fornece UUIDs apoiados por CSPRNG; o resto é disciplina de design
Comece com o registro: habilite registros de auditoria detalhados para geração e verificação do link de redefinição e, em seguida, reproduza o problema e rastreie o fluxo. O gerador ToolAcre garante que as duas primeiras verificações sejam aprovadas; solucionar problemas de link de redefinição quase sempre se enquadra na categoria de design. As melhores práticas para sistemas de link de redefinição de produção incluem: gerar um novo token aleatório para cada solicitação de redefinição e não reutilizar tokens antigos. Armazene uma representação unidirecional junto com os metadados da conta e da criação e, em seguida, escolha um vencimento na política de risco documentada do serviço. Invalide o token imediatamente após a verificação bem-sucedida. Registrar solicitações de redefinição e sucessos para auditoria. Implemente limitação de taxa para evitar ataques de força bruta. Envie links de redefinição somente por e-mail, não por SMS ou canais não criptografados. Notifique o usuário sobre tentativas de redefinição de senha (para que ele possa detectar redefinições não autorizadas). O gerador ToolAcre fornece a aleatoriedade; seguir essas práticas lhe dá segurança.