Da dove viene la casualità
crypto.getRandomValues chiede al CSPRNG del sistema operativo (getrandom() su Linux, SecRandomCopyBytes su macOS, BCryptGenRandom su Windows), che viene inizializzato da eventi hardware e, sulle CPU moderne, dall’istruzione RDRAND. È imprevedibile in entrambe le direzioni: conoscere un milione di output non dice nulla sul successivo. Math.random() non lo è; è un PRNG veloce con un piccolo stato interno, buono per i giochi e mai per i segreti.
Quanti byte
| Scopo | Byte | Perché |
|---|---|---|
| ID di sessione, token CSRF | 16–32 | 128 bit sono oltre la forza bruta; 32 byte è il default comune. |
| Chiave / segreto API | 32 | 256 bit; hashata con SHA-256 per la memorizzazione, come una password ma senza bisogno di hash lento perché è casuale. |
| Chiave di firma HMAC / JWT | 32–64 | Pari all’output dell’hash: 32 per SHA-256, 64 per SHA-512. |
| Chiave AES | 16 / 32 | AES-128 o AES-256. |
| Salt | 16 | Conta l’unicità; 128 bit la garantiscono. |
| Token di reset password in un URL | 16–24 | Base64URL lo tiene corto; memorizzane l’hash, fallo scadere presto. |
Interi casuali senza bias
Prendere byte_casuale % 6 per un dado è sottilmente sbagliato: 256 non è divisibile per 6, quindi 1–4 escono leggermente più spesso di 5–6. Il metodo corretto estrae un valore, lo rifiuta se cade nell’intervallo residuo in alto, e riprova; è quello che fa questo generatore e quello che fanno secrets.randbelow, crypto.randomInt e rand.Intn.
Chiavi con prefisso
Prefissi come sk_live_, ghp_ o AKIA non aggiungono sicurezza ma rendono le chiavi riconoscibili nei log e permettono agli scanner di segreti (quello di GitHub, gitleaks) di trovare quelle trapelate. Scegli un prefisso unico per il tuo servizio e tieni la parte casuale a 32 byte.
Domande
È buono quanto openssl rand o /dev/urandom?
Sì: il browser chiama lo stesso generatore del sistema operativo che quegli strumenti leggono. L’output è adatto a chiavi e segreti. Se comunque ti serve in una shell: openssl rand -hex 32, oppure head -c 32 /dev/urandom | base64.
Dovrei memorizzare le chiavi API hashate?
Sì, con un hash veloce come SHA-256; poiché la chiave è casuale, un hash lento da password non serve. Mostra la chiave una sola volta alla creazione e conserva solo l’hash, come fanno GitHub e Stripe.
Cos’è Base64URL?
Base64 con - e _ al posto di + e /, di solito senza padding, così il valore può stare in un URL o in un cookie senza escape. I JWT e la maggior parte dei token moderni lo usano.
Perché non usare semplicemente un UUID come token?
Un UUIDv4 ha 122 bit casuali, che bastano, ma il suo formato fisso dichiara cos’è e spreca caratteri nei trattini. Per i segreti, byte casuali grezzi in Base64URL sono più corti e più forti. Gli UUID sono per gli identificatori, non per i segreti.