Gerador de Segredos e Chaves de API

Continuar na ferramenta

Mais páginas desta ferramenta

gerar string aleatória hex base64 openssl rand

String aleatória segura em hex ou base64: equivalente a openssl rand

Nos formatos Hex, Base64, Base64URL e Base32 do gerador, o parâmetro é o número de bytes aleatórios. Abaixo, a tabela de tamanhos e a explicação de por que o sorteio de caracteres exige rejeição.

Bytes, caracteres e bits: a conta de cada codificação

Todo comando openssl rand N entrega N bytes aleatórios, e a codificação só decide como escrevê-los em texto. O hex usa 2 caracteres por byte (openssl rand -hex 32 imprime 64 caracteres). O base64 usa 4 caracteres a cada 3 bytes, com preenchimento = no fim: 32 bytes dão 44 caracteres. O base64url, de python3 -c "import secrets; print(secrets.token_urlsafe(32))", troca + e / por - e _ e omite o preenchimento, o que dá 43 caracteres. O base32 usa 8 caracteres a cada 5 bytes, e 20 bytes (160 bits) viram 32 caracteres. Em todos os casos, a entropia é o número de bytes vezes 8, não o de caracteres.
Quando o segredo não vem de bytes, e sim de um alfabeto (letras e dígitos, por exemplo), a conta muda para comprimento vezes log2 do tamanho do alfabeto: 32 caracteres de 62 símbolos dão cerca de 190,5 bits, e 43 chegam a 256. O erro clássico é sortear com resto da divisão. Como 256 = 4 x 62 + 8, tirar byte módulo 62 faz os 8 primeiros símbolos saírem 5 vezes em 256, contra 4 dos demais, ou seja, 25% a mais. O gerador descarta os bytes de 248 a 255 (cerca de 3% dos sorteios) e usa o resto, de modo que os 62 símbolos fiquem igualmente prováveis.
Para escolher, pense no destino. Hex serve para quase tudo e é fácil de ler e comparar. Base64url é o melhor para URLs, cabeçalhos e JWT. Base64 padrão aparece em APP_KEY e AUTH_SECRET. Base32 vale quando alguém digitará o valor, pois usa só maiúsculas e dígitos de 2 a 7, sem o 0 e o 1 que se confundem com O e I. Em qualquer caso, 16 bytes (128 bits) é o piso razoável para uma chave e 32 bytes (256 bits) o tamanho comum para HMAC. O gerador dá o comando de terminal de cada formato, e para valores de produção esse comando em máquina própria é a opção mais prudente.

Tamanhos conferidos

openssl rand -hex 32

Entrada: 32 bytes em hex
Saída esperada: 64 caracteres, 256 bits

2 caracteres por byte.

openssl rand -base64 32

Entrada: 32 bytes em base64
Saída esperada: 44 caracteres, 256 bits

Termina em um = porque 32 não é múltiplo de 3.

token_urlsafe(32)

Entrada: 32 bytes em base64url
Saída esperada: 43 caracteres, 256 bits

Sem preenchimento.

Base32 de 20 bytes

Entrada: 20 bytes em base32
Saída esperada: 32 caracteres, 160 bits

O tamanho comum de segredos TOTP.

Alfanumérico de 32

Entrada: 32 caracteres de 62 símbolos
Saída esperada: cerca de 190,5 bits

32 x log2(62).

FAQ da ferramenta completa

Como gerar um JWT secret seguro para HS256?

Use pelo menos 32 bytes aleatórios (256 bits): a RFC 7518, seção 3.2, diz que a chave HMAC deve ter o tamanho da saída do hash ou mais, ou seja, 256 bits para HS256, 384 para HS384 e 512 para HS512. Uma frase curta ou palavra de dicionário como segredo pode ser quebrada por força bruta offline a partir de um único token.

O que é o APP_KEY do Laravel e como gerar?

Como é a SECRET_KEY do Django gerada aqui?

Qual o tamanho do secret_key_base do Rails?

Como gerar o AUTH_SECRET do Auth.js ou NextAuth?

Quantos bits de entropia um segredo precisa ter?

É seguro gerar segredos de produção em um site?

Por que não usar Math.random para gerar segredos?

Qual a diferença entre hex, base64 e base64url?

Para que serve o sufixo de verificação da chave de API?

Perguntas frequentes

Hex ou base64: qual é mais seguro?

Nenhum. A segurança vem do número de bytes aleatórios, e as duas codificações escrevem os mesmos bytes. O base64 só gasta menos caracteres para o mesmo valor.

Por que não usar uuidgen como segredo?

Um UUID v4 tem 122 bits aleatórios em 36 caracteres e serve de identificador. Como chave de assinatura fica abaixo de 128 bits, e o formato revela a estrutura. Prefira 32 bytes em hex ou base64.

Preciso me preocupar com o = no fim do base64?

Em arquivos .env e variáveis de ambiente funciona sem aspas. Em URLs e cabeçalhos, use base64url, que não tem = nem os caracteres + e / que exigem escape.

Próximos passos

Bytes, caracteres e bits: a conta de cada codificação

Todo comando openssl rand N entrega N bytes aleatórios, e a codificação só decide como escrevê-los em texto. O hex usa 2 caracteres por byte (openssl rand -hex 32 imprime 64 caracteres). O base64 usa 4 caracteres a cada 3 bytes, com preenchimento = no fim: 32 bytes dão 44 caracteres. O base64url, de python3 -c "import secrets; print(secrets.token_urlsafe(32))", troca + e / por - e _ e omite o preenchimento, o que dá 43 caracteres. O base32 usa 8 caracteres a cada 5 bytes, e 20 bytes (160 bits) viram 32 caracteres. Em todos os casos, a entropia é o número de bytes vezes 8, não o de caracteres.

Quando o segredo não vem de bytes, e sim de um alfabeto (letras e dígitos, por exemplo), a conta muda para comprimento vezes log2 do tamanho do alfabeto: 32 caracteres de 62 símbolos dão cerca de 190,5 bits, e 43 chegam a 256. O erro clássico é sortear com resto da divisão. Como 256 = 4 x 62 + 8, tirar byte módulo 62 faz os 8 primeiros símbolos saírem 5 vezes em 256, contra 4 dos demais, ou seja, 25% a mais. O gerador descarta os bytes de 248 a 255 (cerca de 3% dos sorteios) e usa o resto, de modo que os 62 símbolos fiquem igualmente prováveis.

Para escolher, pense no destino. Hex serve para quase tudo e é fácil de ler e comparar. Base64url é o melhor para URLs, cabeçalhos e JWT. Base64 padrão aparece em APP_KEY e AUTH_SECRET. Base32 vale quando alguém digitará o valor, pois usa só maiúsculas e dígitos de 2 a 7, sem o 0 e o 1 que se confundem com O e I. Em qualquer caso, 16 bytes (128 bits) é o piso razoável para uma chave e 32 bytes (256 bits) o tamanho comum para HMAC. O gerador dá o comando de terminal de cada formato, e para valores de produção esse comando em máquina própria é a opção mais prudente.

Tamanhos conferidos

openssl rand -hex 32

Entrada: 32 bytes em hex
Saída esperada: 64 caracteres, 256 bits

2 caracteres por byte.

openssl rand -base64 32

Entrada: 32 bytes em base64
Saída esperada: 44 caracteres, 256 bits

Termina em um = porque 32 não é múltiplo de 3.

token_urlsafe(32)

Entrada: 32 bytes em base64url
Saída esperada: 43 caracteres, 256 bits

Sem preenchimento.

Base32 de 20 bytes

Entrada: 20 bytes em base32
Saída esperada: 32 caracteres, 160 bits

O tamanho comum de segredos TOTP.

Alfanumérico de 32

Entrada: 32 caracteres de 62 símbolos
Saída esperada: cerca de 190,5 bits

32 x log2(62).

FAQ da ferramenta completa

Como gerar um JWT secret seguro para HS256?

O que é o APP_KEY do Laravel e como gerar?

Como é a SECRET_KEY do Django gerada aqui?

Qual o tamanho do secret_key_base do Rails?

Como gerar o AUTH_SECRET do Auth.js ou NextAuth?

Quantos bits de entropia um segredo precisa ter?

É seguro gerar segredos de produção em um site?

Por que não usar Math.random para gerar segredos?

Qual a diferença entre hex, base64 e base64url?

Para que serve o sufixo de verificação da chave de API?

Perguntas frequentes

Hex ou base64: qual é mais seguro?

Nenhum. A segurança vem do número de bytes aleatórios, e as duas codificações escrevem os mesmos bytes. O base64 só gasta menos caracteres para o mesmo valor.

Por que não usar uuidgen como segredo?

Um UUID v4 tem 122 bits aleatórios em 36 caracteres e serve de identificador. Como chave de assinatura fica abaixo de 128 bits, e o formato revela a estrutura. Prefira 32 bytes em hex ou base64.

Preciso me preocupar com o = no fim do base64?

Em arquivos .env e variáveis de ambiente funciona sem aspas. Em URLs e cabeçalhos, use base64url, que não tem = nem os caracteres + e / que exigem escape.