Random string generator

Computadores são máquinas determinísticas: dado o mesmo estado inicial, executam exatamente as mesmas operações e produzem exatamente os mesmos resultados. Isso é uma virtude enorme para confiabilidade e debugging, mas um problema sério quando você precisa de aleatoriedade. A solução histórica foi o gerador de números pseudoaleatórios (PRNG): um algoritmo que, dado um número inicial chamado semente, produz uma sequência que parece aleatória mas é completamente determinística. O Gerador Linear Congruencial (LCG), formalizado por D. H. Lehmer em 1948, foi por décadas o padrão: pegar o número anterior, multiplicar por uma constante, adicionar outro valor e tirar o resto da divisão por um módulo. Simples, rápido, implementável em poucas linhas. O problema é que LCGs têm padrões previsíveis com saída suficiente — em 1993, o jogo online Netrek foi comprometido porque seu gerador pseudoaleatório de tokens de autenticação era um LCG com parâmetros conhecidos e fáceis de reverter.

A Web Crypto API, disponível em todos os browsers modernos, resolve o problema com `window.crypto.getRandomValues()` — uma função que solicita entropia real do sistema operacional. Essa entropia vem de fontes físicas de ruído: movimentos do mouse, timings de disco, interrupções de hardware, atividade de rede. O Linux acumula essa entropia num pool especial e a disponibiliza para processos. O `Math.random()` do JavaScript — apesar de usar algoritmos modernos como xorshift128+ no motor V8 — não é adequado para fins de segurança porque sua semente pode ser previsível dependendo da implementação e não é protegida contra análise. Para qualquer string destinada a autenticação, tokens de sessão, IDs únicos ou tokens CSRF, `getRandomValues()` é o padrão correto.

Na prática, strings aleatórias são necessárias em mais lugares do que a maioria dos desenvolvedores percebe. IDs de recursos em APIs REST precisam ser únicos e preferencialmente não incrementais — IDs sequenciais expõem o volume de dados e facilitam a enumeração por atacantes. Tokens de acesso de API precisam ser suficientemente longos para resistir a força bruta: uma string hexadecimal de 32 bytes tem 256 bits de entropia, que é hoje o padrão mínimo aceitável para segredos. Senhas temporárias para fluxos de redefinição de acesso. Nomes únicos de arquivos temporários para evitar condições de corrida. O paradoxo do aniversário tem implicações práticas aqui: para IDs de 8 caracteres alfanuméricos (62 símbolos possíveis), a probabilidade de colisão começa a ser razoável já com cerca de 218 mil IDs gerados. Para 16 caracteres, o número sobe para 14 bilhões. Esta ferramenta usa `getRandomValues()` e suporta comprimento, alfabeto e codificação configuráveis.

Computers are deterministic machines: given the same initial state, they execute exactly the same operations and produce exactly the same results. This is an enormous virtue for reliability and debugging, but a serious problem when you need randomness. The historical solution was the pseudorandom number generator (PRNG): an algorithm that, given an initial number called a seed, produces a sequence that looks random but is entirely deterministic. The Linear Congruential Generator (LCG), formalized by D. H. Lehmer in 1948, was the standard for decades: take the previous number, multiply by a constant, add another value, and take the remainder of a modular division. Simple, fast, implementable in a few lines. The problem is that LCGs have predictable patterns given enough output — in 1993, the online game Netrek was compromised because its pseudorandom authentication token generator was an LCG with known parameters that were easy to reverse-engineer.

The Web Crypto API, available in all modern browsers, solves the problem with `window.crypto.getRandomValues()` — a function that requests genuine entropy from the operating system. This entropy comes from physical noise sources: mouse movements, disk timings, hardware interrupts, network activity. Linux accumulates this entropy in a special pool and makes it available to processes. JavaScript's `Math.random()` — despite using modern algorithms like xorshift128+ in the V8 engine — is not suitable for security purposes because its seed can be predictable depending on the implementation and is not protected against analysis. For any string intended for authentication, session tokens, unique IDs, or CSRF tokens, `getRandomValues()` is the correct standard.

In practice, random strings are needed in more places than most developers realize. Resource IDs in REST APIs need to be unique and preferably non-sequential — sequential IDs expose data volume and make enumeration easier for attackers. API access tokens need to be long enough to resist brute force: a 32-byte hex string has 256 bits of entropy, which is today's minimum acceptable standard for secrets. Temporary passwords for account reset flows. Unique temporary file names to avoid race conditions. The birthday paradox has practical implications here: for 8-character alphanumeric IDs (62 possible symbols), the probability of collision starts to be significant at around 218,000 generated IDs. For 16 characters, the number rises to 14 billion. This tool uses `getRandomValues()` and supports configurable length, alphabet, and encoding.

Los ordenadores son máquinas deterministas: dado el mismo estado inicial, ejecutan exactamente las mismas operaciones y producen exactamente los mismos resultados. Esto es una gran virtud para la fiabilidad y la depuración, pero un problema serio cuando se necesita aleatoriedad. La solución histórica fue el generador de números pseudoaleatorios (PRNG): un algoritmo que, dado un número inicial llamado semilla, produce una secuencia que parece aleatoria pero es completamente determinista. El Generador Lineal Congruencial (LCG), formalizado por D. H. Lehmer en 1948, fue el estándar durante décadas: tomar el número anterior, multiplicarlo por una constante, añadir otro valor y tomar el resto de una división modular. Simple, rápido, implementable en pocas líneas. El problema es que los LCG tienen patrones predecibles con suficiente salida — en 1993, el juego en línea Netrek fue comprometido porque su generador pseudoaleatorio de tokens de autenticación era un LCG con parámetros conocidos y fáciles de revertir.

La Web Crypto API, disponible en todos los navegadores modernos, resuelve el problema con `window.crypto.getRandomValues()` — una función que solicita entropía real al sistema operativo. Esa entropía proviene de fuentes físicas de ruido: movimientos del ratón, tiempos de disco, interrupciones de hardware, actividad de red. Linux acumula esta entropía en un pool especial y la pone a disposición de los procesos. El `Math.random()` de JavaScript — a pesar de usar algoritmos modernos como xorshift128+ en el motor V8 — no es adecuado para fines de seguridad, porque su semilla puede ser predecible según la implementación y no está protegida contra el análisis. Para cualquier cadena destinada a autenticación, tokens de sesión, IDs únicos o tokens CSRF, `getRandomValues()` es el estándar correcto.

En la práctica, las cadenas aleatorias son necesarias en más lugares de los que la mayoría de los desarrolladores percibe. Los IDs de recursos en las APIs REST deben ser únicos y preferiblemente no secuenciales — los IDs secuenciales exponen el volumen de datos y facilitan la enumeración por parte de atacantes. Los tokens de acceso a la API deben ser suficientemente largos para resistir la fuerza bruta: una cadena hexadecimal de 32 bytes tiene 256 bits de entropía, que es hoy el mínimo aceptable para secretos. Contraseñas temporales para flujos de restablecimiento de acceso. Nombres únicos de archivos temporales para evitar condiciones de carrera. La paradoja del cumpleaños tiene implicaciones prácticas aquí: para IDs alfanuméricos de 8 caracteres (62 símbolos posibles), la probabilidad de colisión empieza a ser significativa con alrededor de 218.000 IDs generados. Para 16 caracteres, el número asciende a 14.000 millones. Esta herramienta usa `getRandomValues()` y admite longitud, alfabeto y codificación configurables.