La maggior parte delle volte, quando vedo una password generata casualmente, è esadecimale, cioè utilizzo solo il set di caratteri [0-9a-f] . Non sarebbe molto più sicuro se il set di caratteri fosse [0-9a-z] , figuriamoci [0-9a-zA-Z] ?
Arminius ha menzionato la semplicità dell'esagono, e penso che sia qualcosa su cui valga la pena espandersi.
Generatori di numeri casuali di solito lavorano su bit, quindi l'intervallo di numeri che possono generare è una potenza di due. Un intervallo di caratteri come [0-9a-zA-Z] ha 62 caratteri, il che equivale a due volte una potenza di due (64), quindi il computer deve eseguire alcune conversioni tra gli intervalli.
Questo può essere fatto, ma è facile sbagliarlo. Il modo "standard" consiste nel prendere il numero effettivo, dividerlo per l'intervallo desiderato e prendere il resto come numero casuale. Ciò introduce però pregiudizi. Per un semplice esempio, supponi di generare numeri in [0-3] ma invece li vuoi in [0-2] . L'intervallo [0-3] verrebbe mappato sull'intervallo [0-2] in questo modo:
0 => 0 mod 3 => 0
1 => 1 mod 3 => 1
2 => 2 mod 3 => 2
3 => 3 mod 3 => 0
Nota come puoi ottenere 0 in due modi diversi: 0 e 3 entrambi vanno a 0 . L'approccio è distorto verso la generazione di 0 s, che renderà la tua password più facile da indovinare.
Il modo corretto comporta il calcolo del padding corretto per rendere uniformemente ciò che hai generato nell'intervallo, il che è complicato e potrebbe potenzialmente rendere la tua password molto più lunga a seconda di come il tuo intervallo di output è comparabile a quello del generatore di numeri casuali.
Un approccio più semplice consiste semplicemente nell'utilizzare un intervallo che è già una potenza di due in modo da poter ignorare completamente il pregiudizio. La maggior parte ha problemi.
[0-9a-zA-Z] . Per espandere un po 'il motivo per cui base-64 è un problema, considera cosa succede quando provi a codificare un singolo byte (8 bit). Non è possibile farlo con un singolo carattere base 64 poiché questo ottiene solo 6 degli 8 bit. Ma se usi due caratteri, devi capire come riempire il tuo byte da 8 bit con un output a 12-bit senza introdurre bias o suggerendo che potrebbe esserci un byte extra.
Esadecimale, al contrario, è quasi banale codificare i byte. Basta cercare ogni byte in una tabella di 256 elementi per ottenere due caratteri e sputarli fuori. Dà password ragionevolmente brevi, non usa simboli strani, ed è semplice da implementare. È la scelta migliore per i generatori di password attenti alla sicurezza.
Forse la cosa migliore è che la maggior parte dei linguaggi di programmazione supportano l'hex out of the box. La libreria C ha printf() , che può essere formattato come ottale, decimale o esadecimale. Allo stesso modo, C ++ ha I manipolatori IO che usano gli stessi formati. Non c'è però un supporto integrato per altre basi (nemmeno la base-64), quindi devi farlo da solo (difficile) o trovare una libreria che funzioni correttamente (violando la regola NIH (e probabilmente anche un sacco di lavoro per verificarlo)). È molto più semplice usare semplicemente ciò che è nella libreria standard, specialmente quando funziona.
È vero che hai meno sicurezza per personaggio con l'esagono che con altre codifiche, ma come Eric Lagergren ha sottolineato utilmente nei commenti, hex(random_bytes) è esattamente sicuro quanto random_bytes . È solo più lungo è tutto. In realtà, tutto ciò di cui hai bisogno sono 16 byte (codificati come 32 cifre esadecimali) per avere una password così strong che qualsiasi attaccante brucerà tutta l'energia nel sistema solare prima che ottengano una minuscola possibilità di indovinarlo. La maggior parte dei siti Web accetta volentieri le password di 32 caratteri, quindi non ci sono problemi a utilizzarle.
(Hai prove che le password casuali sono di solito hex?)
Ecco alcuni possibili motivi per cui trovi frequentemente password esadecimali:
Le password che vedi potrebbero essere già state sottoposte a hash. Poiché le funzioni di hash restituiscono stringhe binarie, le vedrai spesso memorizzate in forma esadecimale.
L'hashing di una sequenza binaria casuale (ad esempio da /dev/urandom ) è un modo economico ma ragionevolmente sicuro per creare una password casuale. Occasionalmente vedrai qualcosa di simile in natura:
$ head -c 100 /dev/urandom | sha256sum | head -c 25
c9ea6b67af36753a68ef42429
Tutti i personaggi sono facili da distinguere. Cioè, non incontrerai problemi con confuso 1 e I , O e 0 , ecc. Se permetti solo esadecimali in primo luogo.
Le sequenze generate casualmente sono di solito binari, quindi la loro visualizzazione in forma esadecimale sembra logica ed efficiente.
Detto questo, scegliere una password casuale da un intervallo più ampio di [0-9a-f] è ovviamente più sicuro se non si regola la lunghezza. Di solito vado con il tuo suggerimento di [0-9a-zA-Z] che mi dà una vasta gamma ed evita caratteri speciali che potrebbero causare problemi con l'archiviazione e la trasmissione.
Inoltre, ecco cosa ho inserito nella mia shell di configurazione per generare rapidamente password su Linux:
function spw() {
cat /dev/urandom | tr -dc a-zA-Z0-9 | head -c ${1:-20}
}
Ad esempio, spw 25 mi darà una password di 25 caratteri di [0-9a-zA-Z] .
Panoramica
While there are many examples of "random" password generator programs available on the Internet, generating randomness can be tricky and many programs do not generate random characters in a way that ensures strong security.
Tipo e intensità della password generata
Random password generators normally output a string of symbols of specified length. These can be individual characters from some character set, syllables designed to form pronounceable passwords, or words from some word list to form a passphrase. The program can be customized to ensure the resulting password complies with the local password policy, say by always producing a mix of letters, numbers and special characters. It should be noted that such policies typically reduce strength slightly below the formula that follows, because symbols are no longer independently produced.
Con questo in mente, passiamo a PERCHÉ hai visto solo a-f e non a-z .
Set di simboli
Il motivo per cui hai visto a-f invece di a-z , è principalmente dovuto al suo Set di simboli. Ad esempio:
Hexadecimal Numerals: (0-9, A-F) (e.g. WEP Key)
Come puoi vedere, può essere creato per un WEP Key usando Hexadecimal Numerals Set simboli. Se vuoi qualcosa come (a-z, A-Z, 0-9), allora suggerirei il Case Sensitive Alphanumeric Set di simboli che è più complesso di un Set di simboli esadecimali.
Risorse
Puoi leggere di più nelle password e nei set di simboli generati con il link sottostante:
Speriamo che questo ti aiuti a risolvere il tuo problema.
Oltre ai programmatori che sono pigri (come dichiarato nella risposta di Arminuis, la generazione di una password esadecimale è una banale one-liner anche se non hai altro che la shell e gli strumenti standard), probabilmente le codifiche "migliori" che racchiudono più bit in ogni personaggio hanno problemi di usabilità.
Il problema non è tanto che la conversione dei numeri sia difficile o che ci siano numeri dispari di bit in ogni carattere che non si sommano facilmente a una potenza di due (sebbene la base-32 funzioni molto bene per es. o numeri di 160 bit).
Il codice di conversione è composto da una mezza dozzina di righe di codice e non precisamente dalla scienza missilistica (divisione, modulo e ricerca tabella). Il fatto che i bit non si sommano è leggermente fastidioso ma non è davvero un problema. Significa solo che gli ultimi 8 caratteri codificano leggermente meno di 40 bit (o gli ultimi 4 codificano leggermente meno di 24 bit per la base-64). Mentre ciò significa che c'è meno entropia in quei personaggi finali, tuttavia la password in quanto tale è perfettamente casuale, non c'è altro problema che essere "meno elegante di quanto si desideri". Anche il fatto che tu abbia quel = alla fine è un non-problema, puoi semplicemente lasciarlo fuori.
Il problema più grande è l'interazione umana. Base-32 e base-64 contengono un numero sufficiente di simboli per produrre parole casuali o frammenti di parole (casuali) significativi, alcuni dei quali sono più accettabili e alcuni generano una reazione meno favorevole.
Con esadecimale, dead , f001 o affe (scimmia in tedesco) è praticamente il peggiore che si possa ottenere, ma in base-32, le sottostringhe fuck o wanker sarebbero del tutto fattibili, come pure come praticamente ogni insulto che esiste in qualsiasi lingua che usa l'alfabeto romano. Ci sei, universale, internazionalizzato insult-o-matic per i tuoi utenti.
Inoltre, naive base-32 contiene i simboli 0 e O così come 1 e I che l'utente può confondere specialmente quando stampa o annota password e re -inserirli o dover comunicare al telefono.
In base-64 non hai solo 1 e I ma anche i e j e / per aumentare la tua gioia. E, naturalmente, dire a qualcuno una stringa di 20 caratteri con caratteri misti al telefono è pura beatitudine.
Esistono - almeno per la base 32 - diverse soluzioni alternative come l'alfabeto RFC4648 o la codifica di Crockford che tentano di risolvere i problemi di cui sopra (simboli confusi e insult-o-matic) in diverse estensioni.
Questi sono comunque "goffi" in un modo diverso. A qualcuno che usa regolarmente il sistema, diventa presto evidente che qualcosa non è giusto, alcuni simboli (in particolare 0 e 1 ) sembrano non apparire mai. Qualcosa deve essere rotto?
Ora, l'esadecimale è un po 'più lungo, qualche carattere in più da digitare, ma non ha nessuno dei problemi precedenti, ed è il più banale da generare.