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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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?

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!

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.

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.