Quanto dovrebbe essere lunga una chiave API?

Per una nuova chiave API opaca, usa almeno 128 bit di casualità imprevedibile; 256 bit casuali rappresentano una solida scelta predefinita quando il sistema ricevente lo accetta. Ciò non significa che ogni chiave debba contenere 256 caratteri. Lo stesso valore a 256 bit si può rappresentare con 64 caratteri esadecimali, 43 caratteri Base64URL senza padding, 44 caratteri Base64 con padding o 52 caratteri Base32 senza padding.

Usa il Generatore di chiavi API ClockTools per scegliere prima la quantità di casualità desiderata, poi il formato. Lo strumento calcola i byte e i caratteri necessari prima di generare la chiave: puoi così rispettare i limiti del campo senza confondere la lunghezza visibile con la sicurezza.

Qual è la lunghezza corretta della chiave API?

Non esiste un conteggio universale dei caratteri perché un carattere non è un'unità di sicurezza fissa. Un carattere esadecimale trasporta 4 bit. Un carattere Base64URL uniformemente casuale trasporta quasi 6 bit, a parte il gruppo parziale finale. Una cifra decimale contiene circa 3,32 bit. L'alfabeto, il metodo di generazione e il numero di scelte indipendenti determinano lo spazio di ricerca.

Per una pianificazione pratica, inizia da qui:

La documentazione del modulo Python secrets indica che 32 byte, ovvero 256 bit, sono sufficienti per gli impieghi tipici del modulo. Precisa però che la quantità di casualità necessaria cambia con la capacità di calcolo e le minacce. I 256 bit sono quindi una scelta predefinita ragionevole, non una garanzia automatica di conformità.

Il servizio che accetta la credenziale controlla comunque il formato reale. Se un'API esistente specifica 32 caratteri esadecimali, un prefisso fisso o un token emesso dal provider, segui tale contratto. Non allungare, troncare o ricodificare la chiave del provider senza rispettarne le specifiche.

Perché l'entropia e il conteggio dei caratteri differiscono?

L'entropia risponde a una domanda migliore dell'apparenza: quanti segreti equiprobabili avrebbe potuto produrre il generatore? Un valore uniformemente casuale a 128 bit ha 2^128 possibilità. Un valore a 256 bit ha 2^256 possibilità. L'aggiunta di più caratteri visibili aiuta solo se tali caratteri aggiungono scelte indipendenti e imprevedibili.

RFC 4086 illustra perché la distinzione è importante. Un risultato lungo generato da un seme piccolo o prevedibile può contenere molta meno informazione effettiva di quanto suggerisca la sua lunghezza. Per esempio, un valore che sembra avere 128 bit ma deriva da un seme di soli 8 bit corrisponde comunque ad appena 256 possibili semi. La lunghezza non può compensare una casualità debole.

Questo è anche il motivo per cui Math.random(), timestamp, ID sequenziali, nomi utente o dati del dispositivo concatenati non sono basi idonee per i segreti API. In un browser, MDN descrive crypto.getRandomValues() come metodo per ottenere valori casuali crittograficamente robusti. ClockTools richiede tale API e non ricorre a Math.random().

Per gli alfabeti dei caratteri, il calcolo teorico è:

entropy bits = character count × log2(number of distinct characters)

Un alfabeto di 62 caratteri composto da lettere e cifre richiede 22 caratteri indipendenti per superare 128 bit e 43 per superare 256 bit. Usando solo cifre, ne servono rispettivamente 39 e 78. Un alfabeto ristretto non è automaticamente debole: richiede semplicemente più caratteri per raggiungere lo stesso obiettivo.

Quanto è lunga una chiave API a 256 bit in ciascuna codifica?

La codifica modifica la rappresentazione, non i byte casuali sottostanti. Lo strumento live ClockTools e i relativi test di regressione utilizzano 32 byte casuali per un obiettivo di 256 bit. Tali byte si espandono come segue:

I conteggi seguono le regole di codifica in RFC 4648. Il formato esadecimale è il più facile da controllare ed è ampiamente accettato, ma richiede due caratteri per ogni byte. Base64URL è più compatto ed evita i caratteri + e / che possono essere scomodi negli URL e nei nomi dei file. La codifica Base64 standard può includere questi caratteri e usa il padding. Base32 non fa distinzione tra maiuscole e minuscole in molti flussi di lavoro ma è più lungo.

Scegli il formato che l'applicazione ricevente può analizzare in modo affidabile. Non rimuovere il padding se il protocollo non lo consente. Un alfabeto compatibile con gli URL non significa che sia sicuro esporre il valore in un URL. I segreti API possono essere divulgati attraverso la cronologia del browser, i dati dei referrer, i log dei reverse proxy e gli strumenti di analisi.

Quando sono sufficienti 128 bit?

Un segreto opaco di 128 bit generato in modo uniformemente casuale offre uno spazio enorme di possibili tentativi online. In molti sistemi, i limiti alle richieste, il monitoraggio, l'isolamento delle credenziali e la difficoltà di verificare i tentativi rendono impraticabile una ricerca esaustiva. L'aumento del valore casuale a 256 bit crea un margine maggiore e costa poco per la maggior parte dei nuovi progetti lato server.

La scelta dovrebbe comunque seguire un modello di minaccia e un contratto di sistema. Considera 256 bit quando controlli il formato delle credenziali, il costo di archiviazione è trascurabile e la chiave protegge accessi di valore elevato o di lunga durata. Una chiave a 128 bit ben generata può essere appropriata quando un protocollo fissa la dimensione, la credenziale ha vita breve o un campo legacy non può contenerne di più.

Un numero maggiore di bit non compensa un segreto esposto. Una chiave di 256 bit inserita in un repository pubblico può essere copiata immediatamente: nessuno deve indovinarla con un attacco a forza bruta. Se una chiave potrebbe essere stata divulgata, revocala o ruotala invece di limitarti a sostituirla con una stringa più lunga.

Un prefisso rende più forte una chiave API?

No, non quando il prefisso è fisso o prevedibile. Testo come live_, test_ o sk_ può aiutare le persone e gli strumenti di rilevamento dei segreti a identificare una credenziale, ma non aggiunge entropia. Un valore casuale a 256 bit rimane 256 bit casuali indipendentemente dal fatto che la sua rappresentazione testuale inizi con cinque caratteri noti o con nessuno.

I prefissi possono ancora essere utili. Possono distinguere le chiavi di produzione da quelle di test, identificare una famiglia di credenziali e ridurre la possibilità che una chiave venga incollata nel sistema sbagliato. Mantieni questo scopo separato dalla robustezza dell'autenticazione.

Lo stesso avvertimento si applica ai suffissi e agli identificativi pubblici delle chiavi. Un identificatore pubblico può individuare il record corretto del database senza rivelarne il segreto, ma l'ID non dovrebbe essere accettato come prova di autorizzazione. ClockTools riporta separatamente i prefissi e suffissi fissi e gli ID pubblici, senza includerli nel totale dei bit casuali.

Cos'altro conta oltre alla lunghezza?

La lunghezza è solo la fase di creazione. La guida di OWASP alla gestione dei segreti considera un segreto come un ciclo di vita: creazione, rotazione, revoca e scadenza. La guida di Google Cloud alle chiavi API sottolinea anche l'importanza di restrizioni, isolamento, monitoraggio, prevenzione dell'esposizione nel codice client e rotazione.

Prima di emettere una chiave di produzione, controlla tutti e tre i livelli:

1. Casualità: genera almeno 128 bit imprevedibili con una fonte crittograficamente sicura; preferisci 256 bit per una nuova chiave opaca quando il sistema li supporta.
2. Rappresentazione: scegli una codifica accettata dal sistema ricevente; conta solo la parte casuale, non un prefisso o un separatore fisso.
3. Ciclo di vita: limita le autorizzazioni, trasmetti tramite HTTPS, conserva la chiave in un gestore di segreti, evita i log in chiaro, monitora l'utilizzo, definisci una scadenza quando opportuno e consenti una revoca rapida.

In molte architetture, le chiavi API sono credenziali bearer: chiunque ne possieda il valore può esercitare le autorizzazioni associate. Di solito sono più adatte a identificare un'applicazione o un progetto chiamante che ad autenticare una persona. Per le azioni sensibili degli utenti, combinale o sostituiscile con un metodo di autenticazione e autorizzazione progettato a tale scopo.

Come puoi generare la chiave in modo sicuro?

Per generare rapidamente un valore nel browser, apri il Generatore di chiavi API, mantieni l'obiettivo di casualità a 256 bit e seleziona il formato richiesto. L'impostazione Base64URL predefinita produce 32 byte casuali rappresentati da 43 caratteri. La generazione e la preparazione dell'esportazione avvengono localmente nel browser e la pagina esclude intenzionalmente i valori segreti dalle impostazioni condivise.

Per l'infrastruttura di produzione, genera la chiave all'interno dell'ambiente attendibile che memorizzerà il segreto quando possibile. Node.js crypto.randomBytes, Python secrets o OpenSSL possono evitare un trasferimento negli appunti. La pagina ClockTools visualizza i comandi per tali ambienti senza incorporare una chiave generata.

Dopo la generazione, registra il valore nell'applicazione che lo verificherà. La stringa casuale non diventa una credenziale funzionante semplicemente perché assomiglia a una chiave API. Autorizzazioni, scadenza, revoca e verifica della richiesta appartengono al sistema ricevente. La metodologia di ClockTools per le chiavi API spiega la fonte di casualità del browser, il campionamento per rifiuto, le lunghezze verificate e i limiti; il Generatore GUID è disponibile per gli identificatori che non sono segreti condivisi.