Perché non consentire caratteri speciali in una password?

Una spiegazione che non ho visto qui è che molte istituzioni finanziarie sono strettamente integrate con i sistemi più vecchi e sono vincolate alle limitazioni di tali sistemi.

L'ironia di questo è che ho visto sistemi che sono stati costruiti per essere compatibili con i sistemi più vecchi, ma ora i vecchi sistemi sono spariti e la politica deve ancora esistere per compatibilità con il nuovo sistema che è stato costruito per essere compatibile con i vecchi sistema.

(la lezione qui è che se devi essere compatibile con un vecchio sistema, consenti l'eliminazione futura di queste limitazioni).

E il costo del supporto? Diciamo che abbiamo permesso a chiunque di creare una password composta da € caratteri. Evviva, siamo in grado di utilizzare caratteri speciali nelle nostre password. Ma aspetta - come diavolo possiamo digitare quella password se vogliamo ottenere l'accesso alla nostra banca dal telefono cellulare? È più semplice digitare € dalla nostra tastiera che dal cellulare.

E riguardo le vacanze? Siamo nel Regno Unito, che ha accesso solo alla tastiera del Regno Unito. Invece di € possiamo facilmente digitare £ . La parola easily è molto importante qui. Per alcuni utenti medi, il tingersi dei caratteri per la "nuova" tastiera potrebbe essere un problema. Come cercherà di risolverlo? Chiamerà probabilmente il supporto bancario per chiedere di cambiare la password o chiedere why the € character dissapeared from his keyboard .

Questo può essere (debolmente) giustificato come misura di difesa in profondità - se c'è un'iniezione o un altro bug di interpretazione dei dati, limitare il set di caratteri della password e la lunghezza potrebbe essere in grado di impedirne lo sfruttamento. Inoltre semplifica in qualche modo l'implementazione, poiché se si occupano solo di caratteri ASCII a 7 bit, la gestione delle stringhe di caratteri Unicode e multibyte è irrilevante, e le implementazioni più semplici sono di norma meno probabilità di contenere bug.

Tuttavia, valutare questo diminuito rischio contro l'aumento del rischio a causa della bassa qualità della password non è semplice - mi aspetterei che man mano che aumenta il numero di utenti di un sistema, aumenta anche il numero di password che potrebbero essere compromesse, facendo un investimento nel sollevare tali restrizioni più proficue. Detto questo, la password della maggior parte degli utenti sarà terribile anche se il campo è completamente libero.

La mia ipotesi è che la politica esista per tutti i campi inseriti dall'utente e lo stesso criterio di input dell'utente (nessun carattere speciale) è stato applicato ai campi, comprese le password per semplicità. O ad un certo punto alcune banche non erano password di hashing e avevano un attacco SQLi attraverso il loro campo di password, e una politica è stata decisa che le password non possono avere caratteri speciali (e la ragione per la politica è stata dimenticata una volta introdotto l'hashing). / p>

C'è sicuramente un vantaggio per la sicurezza di non consentire caratteri speciali in altri campi immessi dall'utente che non sono hash e potrebbero essere utilizzati per vari attacchi come SQLi o XSS (su un amministratore di banca che guarda un account). Tuttavia, queste minacce vengono generalmente risolte usando sempre i parametri associati in SQL e sempre sanificando l'input dell'utente prima di visualizzare / salvare in db.

La mia altra ipotesi è che vogliono avere regole personalizzate che potrebbero essere diverse da altre posizioni, quindi non è possibile riutilizzare facilmente la propria password complessa standard (che potrebbe andare persa), e devono trovare qualcosa di unico per la loro sito.

EDIT: A un'ulteriore riflessione, a seconda della lingua, posso pensare ad almeno tre caratteri ASCII speciali che dovrebbero essere proibiti / eliminati universalmente in quanto consentire loro di tentare solo il destino. In particolare: \r (null - ascii 0), poiché viene solitamente utilizzato per indicare la fine della stringa nei linguaggi in stile C (probabilmente gli utenti modificano la memoria dopo la fine della stringa). Anche ritorni a capo e avanzamento riga \n (ascii 13) e \r\n (ascii 10), dato che spesso dipendono dal sistema se le interruzioni di riga sono \n o ,./<>?;':"[]{}\|!@#$%^&*(-=_+ e che fa apparire l'inevitabile Posso solo accedere da Windows non dalla mia macchina mac / linux. In effetti, sembra abbastanza ragionevole consentire solo ascii stampabile (32-126) e vietare l'ASCII non stampabile 0-31 e 127.

Ma se per caratteri speciali intendete caratteri unicode non ASCII (come 2b 41 38 41 2d sembra ragionevole per la semplicità di implementazione da più sistemi operativi / tastiere / browser per non consentire caratteri speciali. Immaginate che la vostra password abbia un pi minuscolo in esso. Era che il pi greco (π) che è il codice 0x3c0 o il pi greco copto (ⲡ) che è il codice 0x2ca1 - solo uno funzionerà e questo tipo di problema di caratteri simili con diversi codepoint esiste in unicode. sui bit non sarà possibile equiparare i due π, quindi se provi ad accedere in posti diversi puoi inserire caratteri diversi.

Allo stesso modo, anche se questo problema è uno che il programmatore può controllare e tentare in gran parte di correggere, permettendo ai caratteri unicode di creare problemi di codifica. Questo è per i tuoi caratteri ascii di base, tutto è rappresentato in un numero di un byte. Tuttavia, esistono diversi schemi per la codifica di unicode. È UTF-7, UTF-8, UTF-16, UTF-32, Latin-1 (iso-8859-1), Latin-N encoding e (per alcune codifiche) qual è l'ordine dei byte (little o big endian) ? Il codepoint unicode per pi (0x3c0) sarebbe rappresentato come byte CF 80 in UTF-7, FF FE c0 03 in UTF-8, FF FE 00 00 c0 03 00 00 in UTF-16 e A1 in UTF-32. Non potresti rappresentare pi in Latin-1 (ha solo 95 caratteri stampabili extra), ma se hai avuto un ¡ĄĦЁ‘ก”Ḃ nella tua password e sei stato in codifiche diverse potresti doverlo rappresentare da uno dei seguenti caratteri %code% (che in alcuni latino-N può essere A1).

Sì, la pagina web può avere un set di caratteri definito, ma gli utenti possono sovrascrivere il charset in una pagina del browser o avere dati copiati e incollati da un'altra parte in una codifica diversa. Alla fine della giornata, potrebbe essere più semplice vietare quei personaggi.

Come generalizzazione, ecco i motivi più comuni per cui le istituzioni finanziarie limitano la lunghezza e la complessità dei set di caratteri.

(1) I servizi Web sono sistemi front-end per applicazioni di mainframe legacy, che spesso hanno una limitazione di otto caratteri composta solo da lettere minuscole alfa e numeri. Nessun "personaggio speciale". Stranamente questa è la limitazione più comune. +1 a Mark Burnett sopra.

(2) Non stanno tagliando le password, quindi non possono semplicemente memorizzare una stringa numerica a lunghezza fissa (cioè l'output hash - 32 byte di SHA256 (password)). In quanto tali, devono preoccuparsi di limitare la dimensione dell'input.

(3) Il vettore di minaccia di iniezione SQL è solo un problema di password se le password sono archiviate come testo in chiaro. Molte organizzazioni e altre persone stanno perdendo tempo a preoccuparsi di sfuggire ai caratteri della password, quando il problema viene immediatamente risolto memorizzando una password con hash (idealmente salted e allungato usando qualcosa come PBKDF2 ).

Oltre a favorire la semplice reimpostazione della password del supporto clienti OLTRE la sicurezza, non vi è alcun motivo accettabile di cui io sia a conoscenza per la trasmissione di una password utente in testo non crittografato dal dispositivo dell'utente. Tu non vuoi la responsabilità, quindi non accettarli mai. Ecco a cosa servono gli hash crittografici.

Ecco un ottimo post sul blog che riassume alcune delle migliori pratiche e include esempi di codice. link

In realtà ho chiesto a un grande webshop che (bol.com, non sono sicuro che siano internazionali).

Il loro consiglio è di usare una password complessa, cambiarla frequentemente, usare lettere e numeri, che dovrebbe essere lunga, e forse qualche altra cosa che ho dimenticato. Ad ogni modo, il solito consiglio che nessuno segue. Ma sembrano preoccuparsi della politica della password.

Tuttavia non consentono la maggior parte dei caratteri speciali e la lunghezza massima della password è di 12 caratteri. Su richiesta, mi hanno detto che altrimenti troppe persone avrebbero contattato il supporto.

Quando li ho spediti indietro per chiedere cosa ha dimenticato la password? funzione era per, non ho avuto risposta ...

Quindi per le banche, dove una semplice reimpostazione della password tramite e-mail è fuori questione, suppongo che i costi di supporto siano davvero la ragione (come suggerito da altri qui). Per qualsiasi altro sito web come questo bol.com, sarei molto diffidente se abbiano cancellato le loro password. Dovresti utilizzare una password più unica lì, se il database perde la tua password sarà nota.

Limitare il set di caratteri agli alfanumerici limita la probabilità che uno script o un exploit superino la fase di convalida dell'input.

L'utente può sempre migliorare la propria sicurezza utilizzando password più lunghe, ma l'applicazione deve disporre di una whitelist specifica per aiutare a prevenire gli attacchi.

Posso provare a dare la mia visione del problema sopra come progettista dell'interfaccia utente e non come programmatore: il punto chiave qui è che il requisito di accesso è in parte un problema di progettazione dell'interfaccia utente e non un problema di programmazione.

C'è un libro eccellente "Apress - User Interface Design for Programmers" che mostra un problema analogo relativo alle dimensioni delle finestre che pubblicherò di seguito:

Here's a common programmer thought pattern: there are only three numbers: 0, 1, and n. If n is allowed, all n's are equally likely. This thought pattern comes from the old coding convention (probably smart) that you shouldn't have any numeric constants in your code except for 0 and 1.

Ora il modo di pensare sopra è corretto in un problema di programmazione, ma poiché riguarda le interfacce utente e specialmente Windows non è

But it's not true. As it turns out, it's not equally likely. There are many good reasons why you might want a window exactly at the top of the screen (it maximizes screen real estate), but there really aren't any reasons to leave two pixels between the top of the screen and the top of the window. So, in reality, 0 is much more likely than 2.

Ora che stiamo arrivando al nostro problema, teoricamente tutti i personaggi dovrebbero essere ugualmente probabili e ugualmente consentiti da un punto di vista formale e di programmazione, tuttavia eccoci anche in un'istanza di problema dell'interfaccia UI e dobbiamo esserne consapevoli e dare il corretto peso ad esso.

Quindi parafrasò una risposta dal thread sopra il quale a mio parere è corretto:

Let's say that we allowed anyone to create passwords which contain the € char. Hurray, we are able to use special characters in our passwords. But wait - how on earth can we type that password if we want to get access to our bank from the mobile-phone? It's easier to type € from our keyboard than from the mobile phone.

Questo è il punto principale dal punto di vista dell'usabilità e non dovremmo biasimarlo all'utente se si accorge qualche anno dopo con uno smartphone quando anni prima non esistevano nemmeno, che usava un personaggio che avrebbe dovuto evitare.

È nostro obbligo pensare a questo tipo di problemi e consentire all'utente di evitarlo!

Un po 'tardi per il party - Ho letto di recente che la ragione di ciò è che per molte banche, il valore della maggiore sicurezza di consentire a quei personaggi è superato dal costo di implementazione e dal costo di supporto dei clienti che non possono ricorda le loro password.

Non sto dicendo che sia una buona ragione, ma è così che ho interpretato ciò che ho letto.

link