Devo supportare Unicode nelle password?

Question

Vorrei consentire ai miei utenti di utilizzare Unicode per le loro password.

Tuttavia, vedo che molti siti non lo supportano (ad esempio Gmail, Hotmail).

Quindi mi chiedo se c'è qualche problema tecnico o di usabilità che sto trascurando.

Sto pensando a qualcosa che deve essere un problema di usabilità dato che per impostazione predefinita .NET accetta Unicode e se Hotmail - er, la nuova posta Live - è costruita su questo, non vedo perché restringerebbero esso.

Qualcuno ha riscontrato problemi simili?

Answer 1

Sono sicuro che non ci sono problemi tecnici ma forse Gmail e Hotmail non lo supportano apposta. Questo tipo di siti web ha un vasto pubblico e dovrebbe essere accessibile da qualsiasi luogo.

Immaginiamo che l'utente abbia una password in giapponese ma è in viaggio e va in un cyber cafè e non c'è supporto giapponese che l'utente non sia in grado di accedere.

Un altro problema è quello di analizzare la complessità della password, non è così difficile assicurarsi che l'utente non abbia digitato una parola comune in inglese ma che dire in cinese/russo/tailandese. È molto più difficile analizzare la complessità di una password mentre aggiungi più lingue.

Quindi, nel caso in cui si desideri che il proprio sistema sia accessibile, è meglio assicurarsi che l'utente possa digitare la propria password su ogni tipo di dispositivo/sistema operativo/ambiente, quindi la password alfanumerica con i simboli più comuni (!<>"#$%& ecc.) è una specie di buon set di caratteri disponibile ovunque.

Answer 2

Sono sicuro che le controparti multilingue di questi siti supportano l'unicode. Sembra un problema con i requisiti degli utenti piuttosto che una sfida tecnica.

Answer 3

non sarei sorpreso se c'è un problema tecnico con il server non essere certi della codifica del client invia la password in.

Tuttavia, direi che, per esempio, i siti con principalmente Nativa il pubblico giapponese, cinese o russo che parla usa il rispettivo set di caratteri non ASCII comunemente usati (Big5, EUC-KR, koi8, ecc.) per le password. Forse puoi ricercare ciò che stanno facendo per far fronte ai client web più vecchi utilizzando una delle cose non Unicode.

Answer 4

In genere sono fortemente favorevole a non limitare i tipi di caratteri consentiti nelle password. Tuttavia, ricorda che devi confrontare qualcosa con qualcosa memorizzato che potrebbe essere la password o un hash. Nel primo caso devi assicurarti che il confronto sia fatto correttamente, che è molto più complesso con Unicode che con ASCII da solo; in quest'ultimo caso dovrai assicurarti di eseguire l'hashing esattamente lo stesso ogni volta che viene inserito. I moduli di normalizzazione possono aiutare qui o essere una maledizione, a seconda di chi li applica.

Ad esempio, in un'applicazione a cui sto lavorando Sto usando un hash su una conversione UTF-8 della password che è stata normalizzata in precedenza per eliminare potenziali problemi con la combinazione di caratteri e così via.

Il problema più grande per l'utente potrebbe essere che faccia non è possibile accedervi in ​​alcuni punti, come su un altro layout di tastiera. Questo è già il caso di una delle mie password ma non è mai stato un problema finora. E dopo tutto, questa è una decisione che l'utente deve prendere nella scelta della propria password e non quella che l'applicazione dovrebbe fare per conto dell'utente.Dubito che ci siano utenti che usano felicemente l'Unicode arbitrario nelle loro password e non pensano ai problemi che potrebbero sorgere quando si usa un altro layout di tastiera. (Tuttavia, questo potrebbe essere un problema per i servizi basati sul Web più di ogni altra cosa).

Esistono casi in cui Unicode è giustamente vietato. Uno di questi esempi è TrueCrypt che impone l'uso del layout di tastiera statunitense per le password di avvio (per la crittografia a pieno volume). Non ci sono altri layout e quindi Unicode o qualsiasi altro layout di tastiera produce solo problemi.

Tuttavia, ciò non spiega perché vietano Unicode in normali password. Un avvertimento potrebbe essere bello ma apertamente vietato è sbagliato nei miei occhi.

Answer 5

Supporto le password Unicode in tutte le mie applicazioni Web. Se si utilizza un browser recente, il visitatore può utilizzare qualsiasi punto di codice nei propri script preferiti o nativi.

Per maggiore sicurezza, memorizzo un hash salato anziché utilizzare la crittografia reversibile.

L'importante è normalizzare correttamente e codificare la stringa della password prima di aggiungere la sequenza di byte all'hash (preferisco UTF-8 per l'indipendenza di endian).

Answer 6

Unicode fa schifo se si deve fare la corrispondenza programmatica. Il "segno meno" e "trattino" sembrano uguali, ma potrebbero essere codici separati. "n con una tilde divertente su di esso" potrebbe essere una lettera, o un diacritico e una lettera.

Se le persone utilizzano metodi di codifica diversi, le loro password potrebbero non corrispondere, anche se le password hanno lo stesso aspetto. Vedi omg-ponies aka humanity=epic fail.

È possibile normalizzare, ma cosa succede quando:

• le regole di normalizzazione cambiare
• si dispone di alcuni utenti con segni diacritici nella propria password
• avete alcuni utenti con lettere combinate in propria password
• le password vengono sottoposte a hash, quindi non è possibile modificare le password

Indovina cosa - tu n eed per forzare una reimpostazione della password su alcuni dei tuoi utenti.

Answer 7

Buona idea.

Rende la password più sicura, offre maggiore libertà agli utenti. Ed è già stato fatto da Windows (almeno dal Win 2000), Active Directory e LDAP, Novell (almeno dal 2004)

Alcuni clienti vogliono (http://mailman.mit.edu/pipermail/kerberos/2008-July/013923.html) e c'è anche uno standard su come farlo destra (http://tools.ietf.org/html/rfc4013).

Answer 8

Quindi mi chiedo se c'è qualche problema tecnico o di utilizzo che sto trascurando.

C'è un problema tecnico con password non ASCII (e nomi utente, se è per questo) con l'autenticazione di base HTTP. Per quanto ne so, i siti che hai citato in genere non usano l'autenticazione di base, ma potrebbe essere una sbornia da sistemi che lo fanno.

Lo standard di autenticazione di base HTTP definisce un token con codifica Base64 username:password.Questo significa che se hai due punti nel nome utente o nella password i risultati sono ambigui. Inoltre, decodifica in base64 del token fornisce solo byte, senza indicazioni su come convertire quei byte in caratteri. E indovina cosa? I diversi browser usano diverse codifiche per farlo.

• Opera e Chrome utilizzano UTF-8.

• IE utilizza la tabella codici predefinita del sistema client (che ovviamente non è mai UTF-8) e manipola caratteri che non rientrano in esso utilizzando lo standard di Windows Prova a trovare un carattere che sembra un po 'simile, oppure Forse l'algoritmo Just Not (Who Cares).

• Safari utilizza ISO-8859-1 e rifiuta silenziosamente di inviare qualsiasi token di autenticazione quando il nome utente o la password contengono caratteri che non si adattano.

• Mozilla prende gli 8 bit più bassi del punto di codice (simile a ISO-8859-1, ma più rotto). Vedi bug 41489 per discussioni tortuose senza risultati o progressi.

Quindi, se si consente nomi utente non ASCII o password poi il processo di autenticazione di base saranno nella migliore delle ipotesi complicata e incoerente, con gli utenti chiedendosi perché funziona in modo casuale o non quando usano diversi computer o browser.

Answer 9

No. Limita le password ai caratteri ASCII.

Quando si immette una password, i proiettili vengono visualizzati per nascondere la password.

Tuttavia, quando si immettono il giapponese e altre lingue, è necessario utilizzare un metodo di input, convertendo le combinazioni di tasti nei caratteri desiderati. Questo richiede di vedere quali sono i personaggi.

Answer 10

con HTML 5, con la possibilità di inviare agli utenti un tipo di carattere, è possibile integrare una tastiera grafica sul vostro sistema, così gli utenti saranno in grado di utilizzare la lingua,

Suggerimento: usate Deja Vu font, e modificare usando FontForge così puoi renderlo più piccolo, quindi, con una tastiera visiva javascript, puoi renderlo possibile;)

Look here, è un progetto in cui ho fatto il trucco.