Domanda:
È una buona idea utilizzare l'intero intervallo Unicode per generare una password casuale anziché intervalli limitati?
person of entropy
2018-01-16 18:45:04 UTC
view on stackexchange narkive permalink

So per certo che alcuni siti / app con bassa sicurezza limitano le password solo a caratteri alfanumerici e alcuni consentono un intervallo ASCII leggermente più ampio. Alcuni siti / app supportano anche Unicode.

Le password sono generalmente pensate per essere digitate su qualsiasi tastiera generica, quindi sono generalmente generate utilizzando i caratteri comunemente disponibili. Ma per le password che verranno conservate solo digitalmente, sarebbe una buona idea massimizzare il tempo di indovinare utilizzando l'intera gamma di caratteri Unicode? O ci sono motivi per credere che alcuni o la maggior parte dei siti / app che supportano Unicode potrebbero ancora limitare il loro intervallo di caratteri consentito?

Ogni volta che mantieni una password "solo digitalmente" (che suona come "gestore di password" per me), non saresti sempre in grado di creare password con elevata entropia senza Unicode e solo caratteri alfanumerici?O, per dirla in altre parole, correggimi se sbaglio: presumo che i servizi che ti consentono di utilizzare Unicode per le password non abbiano limiti di lunghezza rigorosi, quindi l'entropia non è un problema quando si utilizzano caratteri alfanumerici.D'altra parte, i servizi con limitazioni di lunghezza non necessarie non consentono i caratteri Unicode.L'entropia sarà un problema in entrambi i casi.
Potresti semplicemente usare una password un po 'più lunga e proteggerti dal mal di testa.
Fai attenzione a come i diversi sistemi possono interpretare le stringhe unicode, non tutte le app, host, dbs, ecc. Gestiranno necessariamente unicode allo stesso modo: https://security.stackexchange.com/a/85664/36538
Correlato anche: [I caratteri non della tastiera rendono la mia password meno suscettibile alla forzatura bruta?] (Https://security.stackexchange.com/questions/4632/do-non-keyboard-characters-make-my-password-less-suscettibile alla forzatura bruta), [L'uso di caratteri Unicode nella mia password aumenterà la sicurezza?] (https://security.stackexchange.com/questions/4943/will-using-unicode-chars-in-my-password-aumentare la sicurezza), [Perché limitare le password a caratteri stampabili ASCII?] (https://security.stackexchange.com/questions/5694/why-limit-passwords-to-ascii-printable-characters?rq=1)
Dovresti stare * molto * attento a quali servizi usi questo.Se all'improvviso ti ritrovi a dover digitare la password su una macchina sconosciuta, potresti trovarti in notevoli difficoltà.Il mio esempio goto di questo è una situazione che ho affrontato più di una volta: dover accedere per stampare i biglietti elettronici in un centro commerciale di un hotel (non sono stati resi disponibili fino a dopo che ero uscito di casa; la stampa era necessaria perchénon possono strappare mezzo PDF dal telefono per soddisfare il loro sistema antiquato).La perdita consequenziale può essere piuttosto costosa
concordato.Recentemente ho incollato una tale password generata nel mio account amministratore di una VM, supponendo che avrei sempre usato copia / incolla da Keypass per gli accessi.tuttavia, il prompt di accesso non accetta di incollare e nemmeno di digitare automaticamente Ascii alto da Keypass.Ho dovuto passare diverse ore per imparare e scrivere 64 codici Alt per poter accedere di nuovo.
Forse usa solo una password più lunga.Se viene elaborato a livello di codice, la lunghezza non è un problema.
Se non è utilizzato per l'input umano, perché non solo una sequenza di byte casuale?Altrimenti, se mi costringi a digitare `ᚷᛖ ώд ლ ಸ இ 을 身` come password predefinita, probabilmente vorrò farti scorticare vivo.
Inoltre correlato: [Gli utenti dovrebbero essere autorizzati a utilizzare qualsiasi carattere speciale che desiderano durante la creazione di una password?] (Https://ux.stackexchange.com/q/72568/46361).(Sì, è una domanda popolare.)
Non che sia davvero importante, ma penso che la maggior parte degli usi di "Unicode" nella domanda e nelle risposte dovrebbe tecnicamente essere "UTF-8".(Unicode mappa tra caratteri e numeri; UTF-8 mappa tra numeri e sequenze di byte.)
Hai intenzione di chiedere alle persone di copiare e incollare la password?Altrimenti non vedo la differenza tra chiamarla "una password Unicode casuale" e semplicemente generare una sequenza casuale di byte della stessa lunghezza e chi se ne frega se corrispondono a una codifica valida per Unicode.
Quale ti aspetti dal vantaggio derivante dalla generazione di una lunga sequenza di byte casuali?Potrebbero essere codificati usando base64 se vuoi che siano scrivibili, ma l'entropia sarebbe la stessa.
Non sembra che qualcun altro ne abbia parlato: *** La maggior parte delle persone non usa l'inglese. *** Supporta l'unicode, non come una strana tattica di sicurezza, ma perché la maggior parte delle persone sulla terra e su Internet nonnon usare l'inglese.
Ho capito che OP stava chiedendo se i sistemi di indovinello bruteforce passeranno attraverso 208 caratteri della tastiera per posizione piuttosto che un UTF-8 molto più grande o un altro set Unicode per posizione e renderebbe più difficile per un sistema di indovinello bruteforce ottenere la tua password.
Unicode è un barattolo di worm, con caratteri non stampabili, combinati, a larghezza zero, che cambiano direzione, confronto di stringhe dipendente dalla localizzazione e crapload di cose che non voglio sapere.A meno che tu non sappia veramente cosa stai facendo, stai lontano, altrimenti renderà la tua vita infelice davvero facile.
@TomK."Ogni volta che mantieni una password" solo digitalmente "(che suona come" gestore di password ")" - Potrebbe essere necessaria una password per accedere al gestore di password.
Quattordici risposte:
#1
+119
Kevin
2018-01-16 20:39:47 UTC
view on stackexchange narkive permalink

Questo suona molto come Fencepost Security. Immagina di gestire una struttura che ha una recinzione a maglie intorno ad essa alta 150 metri. Quanto migliorerebbe la sicurezza rendendo quella recinzione alta 3000 piedi? Nessuno - perché chiunque cerchi di entrare non salirà i 500 piedi; scaveranno sotto, faranno un buco, ecc.

Allo stesso modo, hai una password che è, diciamo, 20 caratteri alfanumerici casuali. Sono 62 ^ 20 possibilità. Stai pensando di cambiarlo in 20 caratteri Unicode casuali. Il che aumenta lo spazio delle possibilità molto più in alto, tranne per il fatto che forzare brute a una password casuale di 20 caratteri non è il modo in cui le cose verranno compromesse.

Mi piace l'idea, ma più possibilità per carattere con la stessa lunghezza di stringa (in caratteri) rappresenterebbero probabilmente una recinzione più spessa, nello stesso modo in cui lo farebbero più caratteri ASCII.
@Baldrickk La maggior parte degli algoritmi di hashing comunemente usati non supera comunque i 72 byte.Una password da 12k byte è sicura quanto una password da 72 byte.
@Baldrickk Penso che ciò che si intende è che qualcosa come l'ingegneria sociale o il bypass dello schema di autenticazione è più probabile che le password siano esposte a un attacco di forza bruta.
Dovrei notare che per idea - intendevo la metafora.Avrei dovuto essere più chiaro.
+1 per @RickyNotaro-Garcia Questo è il fatto più credibile e probabile (e spaventoso) che abbia letto sulla sicurezza delle password da molto tempo.Significa anche che per qualsiasi cosa diversa da una ricerca nel dizionario il metodo bruteforce può essere ottenuto con qualsiasi tipo di stringhe di input e formati, una semplice stringa di cifre esadecimali probabilmente funzionerà se il tempo non ha conseguenze.
#2
+80
Sjoerd
2018-01-16 18:51:14 UTC
view on stackexchange narkive permalink

Questa è una buona idea dal punto di vista della sicurezza. Una password contenente caratteri Unicode sarebbe più difficile da forzare rispetto a una password contenente caratteri ASCII della stessa lunghezza. Ciò regge anche se si confronta la lunghezza dei byte anziché la lunghezza dei caratteri, perché Unicode utilizza il bit più significativo mentre ASCII no.

Tuttavia, penso che non sarebbe pratico poiché i bug Unicode sono così comuni . Penso che se usi le password Unicode ovunque incontrerai più di un paio di siti in cui avresti problemi di accesso, perché gli sviluppatori non hanno implementato correttamente il supporto Unicode per le password.

I commenti non sono per discussioni estese;questa conversazione è stata [spostata in chat] (http://chat.stackexchange.com/rooms/71947/discussion-on-answer-by-sjoerd-is-it-a-good-idea-to-use-the-intero intervallo unicode).
Per non parlare del fatto che tastiere diverse in diverse località ti daranno un unicode diverso.Ciò che funziona su un computer potrebbe non funzionare su un altro computer.
#3
+22
Hector
2018-01-16 19:03:46 UTC
view on stackexchange narkive permalink

Ignorando l'argomento Security by Obscurity, è una questione fondamentale di entropia. Una password Unicode di 8 caratteri è più sicura di una password ASCII di 8 caratteri ma meno sicura di una password ASCII di 64 caratteri.

In generale sono d'accordo con Sjoerd - è probabile che queste causino più disagi che benefici. Inoltre, se mai avessi bisogno di inserire manualmente una password casuale, Unicode probabilmente ti renderà la vita infelice.

Tuttavia, per il caso limite in cui devi utilizzare un servizio che supporta attivamente unicode mentre imponi un limite di lunghezza massima della password (di nuovo ignorare questo di solito indica altri errori di sicurezza) c'è un argomento per questo.

+1 per il commento di supporto attivo.Avere caratteri "sfuggiti" o meno del pieno supporto può essere molto problematico.Se non può essere utilizzato in modo affidabile, non è "sicuro".
"Una password Unicode di 8 caratteri è ... meno sicura di una password ASCII di 64 caratteri."Alcuni sistemi troncano le password a 8 caratteri, nel qual caso una password Unicode di 8 caratteri è più sicura di una password ASCII a 64 caratteri.
#4
+14
NH.
2018-01-16 21:56:37 UTC
view on stackexchange narkive permalink

L'unico motivo valido a cui posso pensare per utilizzare i caratteri Unicode nelle password è se il numero di caratteri (non byte) in una password per un determinato sito è limitato (come questa stupida banca che aveva un massimo di 10 caratteri), in modo che possa essere facilmente indovinato in un giorno o due. In questo caso, puoi utilizzare Unicode (se i proprietari del sito te lo consentono) per ottenere più entropia nella tua password nel frattempo mentre chiedi ai proprietari del sito di conformarsi a NIST 800-63-3 e rimuovere le restrizioni di lunghezza (e l'hash correttamente in modo che l'archiviazione della password non sia un problema).

Volevo anche correggere un malinteso qui:

Unicode usa il bit più significativo mentre ASCII non lo fa.

Sebbene sia vero per il normale ASCII, l'ASCII esteso che alcuni gestori di password (ad esempio KeePass) possono utilizzare nella generazione di password utilizza ogni singolo bit di ogni byte, avendo così una maggiore entropica densità persino di Unicode, che ha ancora una struttura per indicare quanti dei seguenti byte fanno parte dello stesso carattere (Nota che esiste una sequenza di byte non valida in Unicode).

Dal momento che un sito che ti limita a password brevi probabilmente non ha nemmeno l'hash delle password correttamente (causando il fallimento delle password Unicode o codifica errata), non dovresti quasi mai perdere tempo a preoccuparti delle password Unicode perché mentre sei così distratto dai tuoi personaggi divertenti (e dal fatto che devi reimpostare la password perché è stata memorizzata in modo strano), un attaccante potrebbe indovinare le tue domande (di) sicurezza o utilizzando la crittografia del cioccolato per accedere al tuo account.

Mentre alcuni raccomandano un caso d'uso aggiuntivo (["Mettersi in mostra ai tuoi amici"] (https://makemeapassword.ligos.net/Generate)), questo non è valido perché le password non dovrebbero essere mostrate ai tuoi amici :).
KeePass poteva utilizzare ogni bit di ogni byte solo se il server utilizzava una codifica a 8 bit, KeePass sapeva quale codifica era e ogni fase della trasmissione era trasparente a 8 bit.Dal codice sorgente (PwCharSet.cs) sembra che l'opzione "ANSI alta" di KeePass erroneamente denominata includa solo da U + 00A1 a U + 00AC e da U + 00AE a U + 00FF, ovvero i caratteri latini-1 non ASCII stampabili.Se la password è codificata come UTF-8, l'entropia per byte sarà effettivamente inferiore quando "ANSI alto" è selezionato rispetto a quando è deselezionato.
(Non che l'entropia per byte sia comunque importante, a meno che le password non vengano troncate prima di essere sottoposte ad hashing.)
@Sjoerd è corretto: ASCII è 7 bit.Una codifica a 8 bit potrebbe includere ASCII come sottoinsieme, ma non è ASCII, è un superset.E ci sono molte codifiche a 8 bit, anche solo nella serie ISO / IEC 8859.Il problema delle codifiche errate esiste anche con codifiche a 8 bit.
#5
+10
John Deters
2018-01-17 01:08:52 UTC
view on stackexchange narkive permalink

Questo approccio potrebbe ridurre la tua sicurezza complessiva in alcuni casi, non migliorarla.

La sicurezza delle informazioni consiste di tre attributi: Riservatezza, Integrità e Disponibilità (il Triade della CIA). Concentrandoti esclusivamente su uno, puoi facilmente trascurare l'importanza degli altri.

La riservatezza delle password si ottiene attraverso i principi dell'entropia: quanto è "indovinabile" la tua password? Questo è comunemente misurato dalla dimensione dello spazio di indovinazione della forza bruta, espressa in termini di potenze di 2 o bit. Un attaccante di forza bruta ha solo una tale capacità di indovinare; selezionando una password più lunga per aumentare questa entropia è possibile superare qualsiasi capacità nota o prevista di indovinare. Ottenere l'entropia oltre 80 bit (o scegliere il valore) metterà la password fuori dalla portata degli attori dello stato nazionale. Indipendentemente dalla descrizione eccessivamente semplificata sopra, il punto è che andare al di là di qualsiasi cosa "fuori portata" non aumenta in modo significativo la tua sicurezza. E non è rilevante per la sicurezza se si ottiene l'entropia desiderata utilizzando 10 caratteri Unicode o 17 caratteri ASCII.

Disponibilità significa "posso accedere ai miei dati quando ne ho bisogno?" Se utilizzi set di caratteri Unicode completi, rischi di entrare in conflitto con vari siti che non supportano Unicode, browser o sistemi operativi che implementano Unicode in modo errato o siti che traducono invisibilmente Unicode in ASCII dietro le quinte. La confusione che ne deriva aumenta il rischio di limitare il tuo futuro accesso ai dati. Ciò rappresenta una potenziale diminuzione della disponibilità futura.

In generale, la probabilità che un bruto malintenzionato forzi la tua password a 80 bit non è così alta quanto la probabilità di incontrare un sito mal codificato che non gestisce Unicode propriamente. Pertanto, la tua sicurezza complessiva potrebbe essere ridotta anziché aumentata.

Naturalmente, molti siti hanno la lunghezza della password e altre restrizioni che limitano drasticamente anche l'entropia delle tue password. In questi casi, l'utilizzo dell'intero set Unicode può aumentare l'entropia delle tue password, supponendo che non abbiano altri difetti nascosti. Quindi, su questi siti, potresti migliorare la tua sicurezza; ma è praticamente impossibile stabilire dall'esterno se un sito gestisce correttamente i dati della tua password.

Con uno scarso supporto per UTF-8 molte volte, anche Integrity è a rischio (almeno della password, forse non dei dati protetti dalla password).
Se un sito ti limita a dire 10 caratteri, dubito fortemente che consentirà 10 caratteri cinesi.Immagina che il sito in cui inserisci la password prima la converta silenziosamente in UTF-8 e rimuove il bit più alto.Adesso sei bloccato.
#6
+3
Tom
2018-01-17 01:07:16 UTC
view on stackexchange narkive permalink

Questa potrebbe non essere una risposta diretta, ma se la password è conservata solo digitalmente, dovresti chiederti perché stai generando una password invece di un array di byte. Una volta che guardi l'intera cosa come semplici byte, la domanda non è più applicabile.

Inoltre, lunghezza> complessità in tutte le cose relative alle password.

La maggior parte delle applicazioni semplicemente non accetta un array arbitrario di byte come password.Per esempio.prova a inserire un byte nullo nella password del tuo sito web preferito.
@DmitryGrigoryev forse Tom stava suggerendo una rappresentazione HEX del suo array di byte.La fonte dell'entropia non può essere determinata indovinando se c'è più di quanto un attacco del dizionario possa trovare.
Non è chiaro dalla domanda se l'OP stia cercando una password che può inserire ovunque o un'implementazione di login da utilizzare per il proprio sito.
#7
+3
Patrick Mevzek
2018-01-18 09:19:37 UTC
view on stackexchange narkive permalink

C'è una RFC sul tuo problema: Preparazione, applicazione e confronto di stringhe internazionalizzate che rappresentano nomi utente e password il cui abstract è:

Questo documento descrive i metodi aggiornati per la gestione di stringhe Unicode che rappresentano nomi utente e password. L'approccio precedente era noto come SASLprep (RFC 4013) ed era basato su Stringprep (RFC 3454). I metodi specificati in questo documento forniscono un approccio più sostenibile alla gestione di nomi utente e password internazionalizzati.

Se leggi il francese, puoi anche trovare una buona spiegazione qui: http : //www.bortzmeyer.org/8265.html.

La sezione 8 dell'RFC tratta specificamente della sicurezza delle password utilizzando "qualsiasi" carattere Unicode, con le seguenti sezioni:

  • 8.1. Forza password / passphrase
  • 8.2. Confronto password / passphrase
  • 8.3. Confronto degli identificatori
  • 8.4. Riutilizzo di PRECIS
  • 8.5. Riutilizzo di Unicode
Questo.L'implementazione di Unicode è [incredibilmente] (https://eev.ee/blog/2015/09/12/dark-corners-of-unicode/) [difficile] (https://stackoverflow.com/questions/6162484/why-does-modern-perl-avoid-utf-8-by-default / 6163129% 236163129) e cose come l'utilizzo di una normalizzazione definita sono essenziali anche per avere la possibilità di farlo funzionare.
#8
+2
Boldewyn
2018-01-18 15:39:01 UTC
view on stackexchange narkive permalink

Aggiungendo alle altre buone risposte, voglio solo far notare cosa può andare storto usando l'intero set Unicode per le password.

Supponendo che tu usi casualmente un stringa UTF-8 più o meno valida,

  • ci sono caratteri interpretati come interruzioni di riga nel mezzo del piano multilingue di base come separatore di paragrafo U + 2029. potresti non essere in grado di inserirli in un semplice campo <input> .
  • ci sono entrambi i caratteri di spazio che potrebbero o non potrebbero essere rimossi da una lingua trim () metodo
  • se ti capita di utilizzare caratteri surrogati (U + D800-U + DFFF), non caratteri come U + FDD0, caratteri ad uso privato o caratteri non assegnati (sebbene sequenze UTF-8 valide) il comportamento di un dato insieme di strumenti è fondamentalmente indefinito (rimozione, sostituzione, rifiuto, non fare nulla o qualsiasi combinazione di quelli)
  • se ti capita di aggiungere segni diacritici, qualsiasi strumento in corso potrebbe cambiarlo in rappresentazione NFC o NKD, cambiando i byte nella password.
  • e è solo dalla parte superiore della mia testa. Sono sicuro di aver dimenticato molti altri possibili problemi, se le password vengono scelte dall'intero intervallo Unicode.

Quindi, simile a quanto suggerito da @JohnDeters, potrebbe essere una cattiva idea perché il vantaggio di uno spazio sorgente più ampio viene superato dalle parti mobili dell'elaborazione del testo lungo il percorso.

#9
+1
gnasher729
2018-01-17 03:30:17 UTC
view on stackexchange narkive permalink

Ciò che conta per la sicurezza è l'entropia della password: quanti bit di informazioni effettive ci sono nella password.

L'altro lato del problema è quanto sia difficile ricordare la password e digitare la password. Immagina di provare a digitare la tua password su un iPhone e ti rendi conto che non puoi (non ho verificato quanto sia difficile digitare caratteri Unicode arbitrari). Oppure ti rendi conto che è molto, molto difficile digitarlo correttamente al 100%. Oppure ci vogliono solo anni: potrei avere una password con la stessa entropia e più caratteri, ma due volte più veloce da digitare. E hai bisogno di quattro tentativi per farlo bene, mentre il mio è giusto la prima volta.

#10
+1
Luis Casillas
2018-01-19 02:14:45 UTC
view on stackexchange narkive permalink

Altri hanno ampiamente sottolineato il rischio che i servizi per i quali usi quelle password non implementino correttamente Unicode. Aggiungerò che i servizi che oggi fanno potrebbero domani cessare di farlo, ma altrimenti salterò questo argomento.

Un elemento che ho pensare che deve essere considerato qui è chiedersi: quanto tempo deve essere una password per raggiungere un certo livello di sicurezza? Supponiamo di volere che le nostre password siano forti come una chiave crittografica a 128 bit (che è probabilmente eccessivo per la maggior parte delle password dei siti Web; consiglio 80 bit). Se ti attieni a password ASCII casuali, una password di 19 caratteri tratta dai ~ 95 caratteri ASCII stampabili raggiunge quel livello. (La matematica: un insieme di circa 100 elementi è circa 6,6 bit / elemento (poiché log2 (10) ≈ 3,3 e log2 (100) è il doppio), e 128 ÷ 6,6 ≈ 19,4. Quindi 19 caratteri ASCII in realtà sono circa 126 bit, non 128, ma meh.)

Unicode ha attualmente circa 130.000 codepoint definiti, un numero che approssimeremo solo come 2 ^ 17. Ciò significa che per raggiungere il livello di 128 bit sono necessari 7 codepoint Unicode (128 ÷ 17 ≈ 7.5, quindi 7 codepoint sono solo circa 119 bit, ma, di nuovo, meh.)

Per la sicurezza a 80 bit livello, che penso sia più sensato per la maggior parte dei siti Web, sono 12 caratteri ASCII contro 5 punti di codice Unicode.

Sei disposto a subire un enorme successo di usabilità e rischiare bug del sito Web solo per poter avere 5 o Password di 7 caratteri invece di 12 o 19 caratteri? Non credo che ne valga la pena.

#11
  0
JonnyRobbie
2018-01-17 00:34:28 UTC
view on stackexchange narkive permalink

Bene, Unicode è "solo" un elenco di qualcosa che supera i 130000 caratteri. UTF-8 è la codifica più comune che prende quel numero grande e lo 'converte' in un numero in base 256 (o più precisamente, le regole hanno più senso negli ottetti binari) secondo un insieme di regole. Pertanto, se desideri utilizzare una codifica utf-8, sarai vincolato a molte regole che riducono efficacemente la casualità che potresti desiderare. E non so come potresti usare l'intera interpretazione Unicode.

Se non sei preoccupato per i caratteri stampabili, potresti considerare l'intero ASCII (o più preferibilmente un'estensione a 8 bit), ma a a questo punto, perché preoccuparsi anche solo degli standard di interpretazione dei caratteri? Allora non potresti semplicemente usare qualche semplice struttura binaria casuale senza forma?

#12
  0
David M
2018-01-17 09:35:18 UTC
view on stackexchange narkive permalink

Anche se utilizzi solo l'archiviazione digitale, non vorrei essere l'utente che aveva bisogno di digitare qualcosa e non ha riconosciuto la differenza tra (e (. (Suggerimento: sono doppie e singole spaziato)

Usando questo esempio sensibile alla larghezza, come notato in altre risposte, ti aspetti che il supporto di questi funzioni - a seconda delle regole di confronto SQL impostate qui, una password errata sarebbe corretta!

#13
  0
allo
2018-01-18 20:25:10 UTC
view on stackexchange narkive permalink

No. Vuoi aumentare la base di una funzione esponenziale rischiando che molte cose si rompano (ad esempio dispositivi che non possono digitare i tuoi caratteri speciali, ecc.) Calcola l'entropia della tua password Unicode e allunga la tua password ASCII finché non ha più entropia.

az da solo è 26 ^ (lunghezza). diciamo che ottieni 256 ^ (lunghezza) e possibilmente 2 byte per carattere con unicode. Quindi puoi trovare il break even 26 ^ (ascii_length) > 256 ^ (2 * unicodelength) da qualche parte. Scegli questa lunghezza come ascii_length e puoi comunque scrivere la tua password e avere la stessa sicurezza.

Se il sito non supporta password lunghe (peccato per loro), sospetto non possono garantire nemmeno un buon supporto Unicode. Forse sarai bloccato la prossima volta che aggiorneranno una libreria interna. Allora perché rischiare un problema lì? E un problema, difficile da spiegare al supporto utente, che sa a malapena cosa significhi unicode.

#14
  0
Jonathan Rosenne
2018-01-19 01:34:59 UTC
view on stackexchange narkive permalink

Non è una buona idea generare password Unicode casuali, perché la password generata potrebbe essere illeggibile per l'utente. Ma il testo della domanda parla dell'utilizzo di password Unicode, e questa è una buona idea e raccomandata dalla sezione 5.1.1.2 Memorized Secret Verifiers del NIST 800-63-3 che dice:

I verificatori DEVONO richiedere che i segreti memorizzati scelti dall'abbonato abbiano una lunghezza di almeno 8 caratteri. I verificatori DOVREBBERO consentire segreti memorizzati scelti dall'abbonato di almeno 64 caratteri. Tutti i caratteri ASCII [RFC 20] di stampa e il carattere spazio DOVREBBERO essere accettabili nei segreti memorizzati. Dovrebbero essere accettati anche i caratteri Unicode [ISO / ISC 10646].

Ai fini dei requisiti di lunghezza di cui sopra, ogni punto di codice Unicode DEVE essere conteggiato come un singolo carattere.

Continua:

Se i caratteri Unicode sono accettati nei segreti memorizzati, il verificatore DOVREBBE applicare il processo di normalizzazione per le stringhe stabilizzate utilizzando la normalizzazione NFKC o NFKD definita nella Sezione 12.1 dell'allegato 15 dello standard Unicode .

Riassumendo: l'uso di Unicode aumenta l'entropia e rende la vita più facile per gli utenti che non conoscono bene l'inglese.

Potresti elaborare ciò che questo aggiunge alle altre risposte?
Ho sottolineato la differenza tra la generazione di una password Unicode e la scelta di una, e che l'entropia non viene ridotta come affermato da altre risposte ma aumentata poiché si dovrebbero contare i caratteri piuttosto che i bit.Inoltre, il NIST non solo consente Unicode ma in realtà ne consiglia l'uso, che è una risposta diretta alla domanda.


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...