E 'una buona idea usare l'intera gamma Unicode per generare una password casuale piuttosto che intervalli limitati? [duplicare]

Questa è una buona idea dal punto di vista della sicurezza. Una password contenente caratteri Unicode sarebbe più difficile da applicare a una forza bruta rispetto a una password contenente caratteri ASCII della stessa lunghezza. Questo regge anche se confronti la lunghezza dei byte invece della lunghezza dei caratteri, perché Unicode usa il bit più significativo mentre ASCII no.

Tuttavia, penso che non sarebbe pratico dal momento che i bug Unicode sono così comuni. Penso che se si usano le password Unicode ovunque si incontrino più di un paio di siti in cui si avrebbero problemi ad accedere, perché gli sviluppatori non hanno implementato correttamente il supporto Unicode per le password.

Sembra molto simile a Fencepost Security. Immagina di avere una struttura che ha una recinzione a catena intorno ad essa alta 500 piedi. Quanto migliorerebbe la sicurezza rendendo quella recinzione alta 3.000 piedi? Nessuno - perché chiunque cerchi di entrare non salirà i 500 piedi; stanno andando a scavare sotto, a fare un buco, ecc.

Allo stesso modo, hai una password che è, diciamo, 20 caratteri alfanumerici casuali. Sono 62 ^ 20 possibilità. Stai considerando di cambiarlo in 20 caratteri unicode casuali. Il che aumenta lo spazio delle possibilità molto più in alto, tranne che forzare brutemente una password randomizzata di 20 caratteri non è come le cose vadano compromesse.

Ignorando l'argomento Sicurezza per Oscurità, si tratta di una questione fondamentale di entropia. Una password Unicode di 8 caratteri è più sicura di una password ASCII a 8 caratteri ma meno sicura di una password ASCII a 64 caratteri.

In generale sono d'accordo con Sjoerd - è probabile che causino più disagi che benefici. Oltre a questo, se mai hai bisogno di inserire manualmente una password, Unicode probabilmente renderà la tua vita infelice.

Tuttavia, per il caso limite in cui è necessario utilizzare un servizio che supporta attivamente l'Unicode mentre si applica un limite massimo di lunghezza della password (di nuovo ignorando questo di solito indica altri errori di sicurezza) c'è un argomento per questo.

L'unica ragione valida per cui posso pensare di usare i caratteri Unicode nelle password è se il numero di caratteri (non i byte) in una password per un particolare sito è limitato (come questo banchetto stupido che previously aveva un massimo di 10 caratteri), in modo che potesse essere facilmente indovinato in un giorno o due. In questo caso, puoi utilizzare Unicode (se i proprietari del sito ti consentono) di ottenere più entropia nella tua password nel frattempo mentre chiedi ai proprietari del sito di rispettare NIST 800-63-3 e rimuovi le restrizioni di lunghezza (e l'hash correttamente, quindi l'archiviazione delle password non è un problema).

Volevo anche correggere un equivoco qui:

Unicode uses the most significant bit whereas ASCII does not.

Sebbene sia vero per ASCII normale, l'ASCII esteso che alcuni gestori di password (ad es. KeePass) possono utilizzare nella generazione di password utilizza ogni singolo bit di ogni byte, avendo così una densità entropica superiore persino a Unicode, che ha ancora una struttura per indica quanti dei seguenti byte fanno parte dello stesso carattere (nota che è qualcosa come un sequenza byte non valida in Unicode ).

Dato che un sito che limita le password brevi probabilmente non ha nemmeno cancellato correttamente le loro password (causando l'errore delle password Unicode o memorizzato con la codifica errata), non dovresti quasi mai perdere tempo con le password Unicode perché sei così distratto dai tuoi personaggi divertenti (e dal fatto che devi reimpostare la tua password perché è stata memorizzata in modo strano), un utente malintenzionato potrebbe indovinare il tuo (in) - domande sulla sicurezza o utilizzando crittografia al cioccolato per accedere al tuo account.

Questo approccio potrebbe ridurre la tua sicurezza generale in alcuni casi, non migliorarlo.

La sicurezza delle informazioni consiste di tre attributi: Riservatezza, integrità e disponibilità (la triade della CIA ). Concentrandoti esclusivamente su uno, puoi facilmente trascurare l'importanza degli altri.

La riservatezza delle password viene raggiunta attraverso i principi di entropia: quanto è "inaffidabile" la tua password? Questo è comunemente misurato dalla dimensione dello spazio indovinare forza bruta, espresso in termini di poteri di 2 o bit. Un attaccante di forza bruta ha solo tanta capacità di indovinare; selezionando una password più lunga per aumentare questa entropia, è possibile superare qualsiasi capacità nota o prevista da indovinare. Ottenere l'entropia di oltre 80 bit (o scegliere il tuo valore) metterà la password fuori dalla portata degli attori dello stato nazione. Indipendentemente dalla descrizione eccessivamente semplificata di cui sopra, il punto è che andare al di sopra e al di là di qualsiasi "fuori portata" non aumenta in modo significativo la sicurezza. Inoltre, non è rilevante per la sicurezza se si raggiunge l'entropia desiderata utilizzando 10 caratteri Unicode o 17 caratteri ASCII.

Disponibilità significa "posso accedere ai miei dati quando ne ho bisogno?" Se si utilizzano set di caratteri Unicode completi, si rischia di eseguire il controllo di vari siti che non supportano Unicode, o di browser o sistemi operativi che implementano Unicode in modo non corretto o siti che convertono in modo invisibile Unicode in ASCII sotto le copertine. La confusione che ne deriva aumenta il rischio di limitare il tuo futuro accesso ai dati. Ciò rappresenta un potenziale calo nella disponibilità futura.

In generale, la probabilità che un hacker attacchi bruta forzando la tua password a 80 bit non è tanto alta quanto la probabilità di incontrare un sito mal codificato che non gestisce correttamente Unicode. Pertanto la tua sicurezza complessiva potrebbe essere diminuita invece di aumentare.

Naturalmente, molti siti hanno una 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 quei siti, potresti migliorare la tua sicurezza; ma è praticamente impossibile sapere dall'esterno se un sito gestisce correttamente i dati della password.

Questa potrebbe non essere una risposta diretta, ma se la password viene mantenuta solo digitalmente, allora dovresti chiederti perché stai generando una password , invece di una matrice di byte. Una volta esaminato tutto come semplicemente byte, la domanda non si applica più.

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

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

This document describes updated methods for handling Unicode strings representing usernames and passwords. The previous approach was known as SASLprep (RFC 4013) and was based on Stringprep (RFC 3454). The methods specified in this document provide a more sustainable approach to the handling of internationalized usernames and passwords.

Se leggi il francese, puoi trovare una buona spiegazione qui: link .

La sezione 8 della RFC si occupa in particolare 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 tra identificatori
• 8.4. Riuso di PRECIS
• 8.5. Riutilizzo di Unicode

Aggiungendo alle altre buone risposte voglio solo sottolineare che può andare storto lungo la pipe usando l'intero set Unicode per le password.

Supponendo che usi in modo casuale una stringa UTF-8 più o meno valida,

• ci sono caratteri interpretati come interruzione di linea nel mezzo del piano multilingue di base come U + 2029 Separatore di paragrafi . potresti non essere in grado di inserirli in un campo <input> semplice.
• ci sono entrambi i caratteri di spazi bianchi che potrebbero o non potrebbero essere rimossi dal metodo trim() di una lingua
• se ti capita di utilizzare caratteri surrogati (U + D800-U + DFFF), non caratteri come U + FDD0 , caratteri di uso privato o caratteri non assegnati (sebbene sequenze UTF-8 valide) il comportamento di qualsiasi dato set di strumenti è fondamentalmente indefinito (stripping, 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 questo è solo in cima alla mia testa. Sono sicuro di aver dimenticato molti altri possibili problemi, se le password sono state scelte nell'intero intervallo Unicode.

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

Altri hanno ampiamente sottolineato il rischio che i servizi per i quali si utilizzano tali password non implementeranno correttamente Unicode. Aggiungerò che i servizi che oggi fanno potrebbero domani smettere di farlo, ma altrimenti salterò l'argomento.

Un elemento che ritengo debba essere considerato qui è chiedersi: per quanto tempo è necessaria una password per raggiungere un certo livello di sicurezza? Supponiamo che desideriamo che le nostre password siano forti quanto una chiave crittografica a 128 bit (che è probabilmente eccessiva per la maggior parte delle password dei siti Web; raccomando 80 bit). Se si passano a password ASCII casuali, una password di 19 caratteri disegnata dai caratteri ASCII stampabili ~ 95 raggiunge quel livello. (La matematica: un insieme di circa 100 elementi è di circa 6,6 bit / elemento (poiché log2 (10) ≈ 3.3 e log2 (100) è due volte quello), e 128 ÷ 6.6 ≈ 19.4. Quindi 19 caratteri ASCII è in realtà circa 126 bit, non 128, ma meh.)

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

Per il livello di sicurezza a 80 bit, che ritengo sia più sensato per la maggior parte dei siti Web, è composto da 12 caratteri ASCII e 5 codici Unicode.

Sei disposto a fare un enorme successo sull'usabilità e a mettere a rischio i bug del sito web solo per poter avere password di 5 o 7 caratteri anziché 12 o 19 caratteri? Non penso che ne valga la pena.

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

Se non ti preoccupi dei caratteri stampabili, potresti considerare l'intero ASCII (o più preferibilmente un'estensione a 8 bit), ma a quel punto, perché preoccuparti del tutto con lo standard di interpretazione dei caratteri? Non potresti semplicemente usare una semplice struttura binaria casuale senza forma, allora?

Anche se stai usando solo la memoria digitale, odio essere l'utente che ha bisogno di digitare qualcosa e non ha riconosciuto la differenza tra (e (. (Suggerimento: sono double- e single- distanziati)

Utilizzando questo esempio sensibile alla larghezza, come indicato in altre risposte, ci si aspetta che il supporto di questi funzioni - a seconda del set di regole SQL qui impostato, una password errata sia corretta!

No. Si desidera aumentare la base di una funzione esponenziale mentre si rischia di rompere un sacco di cose (ad esempio dispositivi che non possono digitare i caratteri speciali, ecc.). Calcola l'entropia della tua password unicode e rendi la tua password ascii più lunga finché non ha più entropia.

a-z solo è 26 ^ (lunghezza). diciamo che ottieni un 256^(length) e probabilmente 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 ancora annotare la tua password e avere la stessa sicurezza.

Se il sito non supporta password lunghe (vergogna su di esse), sospetto che non possano garantire un buon supporto Unicode. Forse verrai bloccato la prossima volta che aggiorneranno alcune librerie interne. Allora perché rischiare un problema lì? E un problema, che è difficile da spiegare al supporto utente, che non sa cosa significhi unicode.

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'uso delle password Unicode, e questa è una buona idea e raccomandata dalla sezione NIST 800-63-3 5.1.1.2 Verificatori segreti memorizzati che dice:

Verifiers SHALL require subscriber-chosen memorized secrets to be at least 8 characters in length. Verifiers SHOULD permit subscriber-chosen memorized secrets at least 64 characters in length. All printing ASCII [RFC 20] characters as well as the space character SHOULD be acceptable in memorized secrets. Unicode [ISO/ISC 10646] characters SHOULD be accepted as well.

For purposes of the above length requirements, each Unicode code point SHALL be counted as a single character.

Continua:

If Unicode characters are accepted in memorized secrets, the verifier SHOULD apply the Normalization Process for Stabilized Strings using either the NFKC or NFKD normalization defined in Section 12.1 of Unicode Standard Annex 15.

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