Ferramentas de texto e do dia a dia · Gerador de senhas
crypto.getRandomValues vs Math.random: por que é importante para senhas
· Como funciona
senhas criptografia da web aleatoriedade
Explica a diferença entre o gerador de números aleatórios de uso geral de um navegador e o gerador criptográfico, por que a previsibilidade é fatal para senhas e como saber qual ferramenta usa.
Aleatório o suficiente para um jogo de dados, não para uma senha – os dois tipos de aleatoriedade que um navegador oferece
Um navegador pode oferecer mais de uma fonte de valores que parecem irregulares, mas a desordem visual não é evidência de que uma sequência seja adequada para uma credencial. ToolAcre traça um limite rígido de produto: cada escolha de palavra, escolha de delimitador, escolha de caractere e troca aleatória passa por uma função inteira segura apoiada por `crypto.getRandomValues`. Se esse API não puder ser usado, a página desabilitará a geração em vez de produzir um substituto de aparência plausível.
Essa recusa é mais importante do que o fato de duas amostras de resultados parecerem igualmente confusas. Uma fonte previsível ainda pode imprimir letras, dígitos e palavras que pareçam convincentes para uma pessoa. A implementação, portanto, torna a fonte auditável e a falha visível. Não afirma que qualquer valor gerado seja seguro para todos os ambientes; um navegador ou dispositivo comprometido ainda pode ler o que a página exibe.
Para que serve Math.random - pseudo-aleatoriedade rápida e semeada cuja saída pode ser reconstruída a partir de algumas observações
A pasta de trabalho descreve Math.random como pseudo-aleatoriedade semeada reconstrutível a partir de algumas observações, mas essas são reivindicações gerais de implementação que este repositório não estabelece para cada mecanismo JavaScript. O fato local é mais simples e forte para este produto: os arquivos do gerador de produção não chamam `Math.random`. Um teste de nível de origem remove comentários, verifica o código executável e falha se tal chamada aparecer em qualquer lugar do mecanismo ou do aplicativo de senha.
Essa distinção evita que o artigo transforme uma regra de implementação em uma palestra universal sobre o histórico do navegador. ToolAcre não precisa caracterizar todos os algoritmos Math.random possíveis para rejeitar o API para geração de senha. Seu pacote aceita Web Crypto ou uma fonte segura injetada usada por testes e não expõe nenhuma opção de produção para uma semente, modo determinístico ou substituto fraco.
O que este repositório prova sobre Math.random: está ausente da geração de produção
`createWebCryptoSource` procura por um `getRandomValues` que pode ser chamado e, em seguida, agrupa esse método como a origem aleatória do pacote. O aplicativo realiza uma investigação adicional antes de ativar os controles: ele solicita ao objeto criptográfico global que preencha um array digitado de um elemento dentro de um bloco try. Isso captura ambientes restritos onde a propriedade existe, mas é lançada quando usada, em vez de confiar em uma verificação superficial de recursos.
A origem para no limite do navegador API. Ele não prova qual pool de sistema operacional, instrução de hardware ou design de nova propagação está sob um navegador específico. Esses detalhes variam abaixo da interface e precisam de documentação da plataforma. O que o código prova é que os bytes chegam através do método Web Crypto nomeado e que a geração não é tentada quando a investigação falha.
O que crypto.getRandomValues faz aqui: preenche arrays digitados através do navegador API
A previsibilidade é perigosa porque um gerador de credenciais deve fazer novas escolhas que um observador não pode reproduzir a partir de resultados anteriores. ToolAcre apoia esse objetivo recusando caminhos de produção determinísticos, centralizando cada sorteio e testando se o API fraco está ausente. Ele não promete imunidade contra captura de tela, extensões, malware, phishing, reutilização de senha ou serviço que manipule incorretamente a credencial após o envio.
Essa fronteira evita um erro de categoria comum: a geração trata de como um candidato é selecionado, e não de tudo o que acontece com ele posteriormente. O pacote retorna uma string e não a registra nem a armazena. A página contém um valor atual na memória e o renderiza como texto. O armazenamento de senhas, a transmissão, a recuperação de contas e a política de autenticação permanecem responsabilidades de outros sistemas.
Lendo o código — como verificar qual API uma página usa e por que é mais fácil confiar em páginas abertas e inspecionáveis
A leitura do código começa em `packages/password-generator/src/index.js`, cujo contrato diz que cada decisão aleatória chega a `secureRandomInt`. O arquivo de implementação mostra então `getRandomValues`, amostragem de rejeição e erros explícitos. Finalmente, `no-math-random.test.js` e o conjunto mais amplo de segurança de senha tornam a garantia negativa executável em vez de deixar “nunca usamos Math.random” como um comentário não testado.
O código aberto por si só não torna o código correto, mas dá ao revisor pontos concretos para inspecionar. Procure a fonte aleatória, siga os chamadores através de escolhas e embaralhamentos e inspecione o que acontece quando API está faltando. Uma revisão confiável deve ser capaz de nomear tanto o caminho do sucesso quanto o caminho da recusa, em vez de inferir a segurança da marca.
Exemplo resolvido - a mesma rotina de seleção de palavras escrita nos dois sentidos e o que um invasor poderia fazer com cada um
Considere uma solicitação de um número inteiro abaixo de 100. `secureRandomInt` precisa de um byte, cujo intervalo contém valores 256. Aceita apenas o maior prefixo divisível por 100, que termina antes de 200, e rejeita a cauda restante. Um teste determinístico alimenta o byte 200 seguido pelo byte 7. A implementação descarta 200 e retorna 7; um atalho de módulo direto teria retornado zero do byte rejeitado.
A mesma função inteira segura escolhe índices para palavras e caracteres, portanto este exemplo não é um brinquedo separado da geração. Os bytes exatos em produção não são exemplos repetíveis e nunca devem ser publicados como credenciais. O artefato útil é a prova do fluxo de controle: o Web Crypto preenche o buffer, uma cauda irregular é rejeitada e apenas um valor aceito se torna uma escolha limitada.
Exemplo resolvido: rastreie um sorteio limitado através do caminho secureRandomInt enviado
Este repositório não implementa ou compara geradores do lado do servidor, geradores de números aleatórios de hardware ou ferramentas de linha de comando do sistema operacional. Ele também não pode auditar os aspectos internos da implementação de criptografia do navegador de JavaScript. Esses tópicos precisam de material de origem próprio, modelos de ameaças e verificações operacionais, em vez de uma analogia colada no caminho do código ToolAcre.
A página também não é um gerenciador de senhas. Não salva, sincroniza, transmite ou preenche automaticamente o que gera. O leitor não deve interpretar “fonte criptográfica aleatória” como um conselho para reutilizar um resultado ou movê-lo através de um canal inseguro. A reivindicação pertence apenas à seleção dentro da guia atual do navegador.
Conclusão: o Gerador de senha usa o gerador criptográfico de números aleatórios do navegador e você pode verificá-lo na própria página
A escolha verificável de ToolAcre é criptografada ou nada. A página chama o navegador API durante a detecção de suporte, desativa os controles quando falha e permite que o mecanismo lance `InsecureRandomError` se a geração de alguma forma atingir a mesma condição ausente. Não há substituto Math.random escondido atrás de nenhuma ramificação.
Use esse padrão ao revisar um gerador: identifique a fonte, rastreie cada sorteio limitado, inspecione a redução e o embaralhamento e force o caminho da fonte indisponível. Em seguida, avalie o dispositivo e o destino separadamente. Uma fonte aleatória de som é necessária para o trabalho deste gerador, mas não é um certificado universal para toda a vida da credencial.