it-swarm.dev

Perché non consentire caratteri speciali in una password?

Il colpevole in questo caso è una banca particolare (e particolarmente grande) che non consente caratteri speciali (di alcun tipo) nelle loro password: solo [a-Z 1-9]. C'è qualche motivo valido per farlo? Sembra controproducente bloccare la forza della password in questo modo, specialmente per un sistema che protegge informazioni così preziose.

L'unica cosa che sono stato in grado di escogitare è un debole tentativo di contrastare le iniezioni di SQL, ma ciò presupporrebbe che le password non vengano sottoposte a hash (cosa che spero non sia vera).

68
Gary

Una spiegazione che non ho visto qui è che molti istituti finanziari sono strettamente integrati con i sistemi più vecchi e sono vincolati ai limiti di tali sistemi.

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

(la lezione qui è che se si deve essere compatibili con un vecchio sistema, consentire una futura eliminazione di tali limitazioni).

65
Mark Burnett

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

E le vacanze? Siamo nel Regno Unito, che accede solo alla tastiera del Regno Unito. Invece di possiamo facilmente digitare £. La parola easily è molto importante qui. Per alcuni utenti medi, scrivere che i caratteri per la "nuova" tastiera potrebbe essere un problema. Come proverà a risolverlo? Probabilmente chiamerà il supporto bancario per chiedere loro di cambiare la sua password o chiedere why the € character dissapeared from his keyboard.

13
p____h

Questo può essere (debolmente) giustificato come misura di difesa in profondità - se si verifica 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 impedire che sia sfruttabile. Inoltre semplifica in qualche modo l'implementazione, poiché se si occupano solo di 7 bit ASCII, la gestione delle stringhe di caratteri Unicode e multibyte è irrilevante e le implementazioni più semplici hanno di solito meno probabilità di contenere bug.

Tuttavia, valutare questa riduzione del rischio rispetto all'aumento del rischio dovuto alla minore qualità delle password non è semplice - mi aspetto che all'aumentare del numero di utenti di un sistema, aumenti anche il numero di password che potrebbero essere compromesse, facendo un investimento nel sollevare tale restrizioni più utili. Detto questo, la maggior parte delle password degli utenti sarà terribile anche se il campo è completamente libero.

12
D Coetzee

La mia ipotesi è che la politica esiste per tutti i campi immessi dall'utente e la stessa politica di immissione dell'utente (senza caratteri speciali) è stata applicata ai campi incluse le password per semplicità. O ad un certo punto alcune banche non avevano le password di hashing e avevano un attacco SQLi attraverso il loro campo password, e fu deciso che le password non potevano avere caratteri speciali (e il motivo della politica fu dimenticato una volta che fu introdotto l'hashing).

C'è sicuramente un vantaggio in termini di sicurezza di non consentire caratteri speciali in altri campi immessi dall'utente che non sono sottoposti a hash e che 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 utilizzando sempre i parametri associati in SQL e disinfettando sempre l'input dell'utente prima di visualizzare/salvare su db.

L'altra mia ipotesi è che vogliono avere regole personalizzate che potrebbero essere diverse da quelle di altri luoghi, quindi non è possibile riutilizzare facilmente la password complessa standard (che potrebbe perdersi) e devono trovare qualcosa di unico per il loro sito.


EDIT: A pensarci ancora, a seconda della lingua posso pensare ad almeno tre caratteri speciali ASCII che dovrebbero essere proibiti/spogliati universalmente perché permettano loro solo di tentare il destino. In particolare: \0 (null - ascii 0), poiché viene solitamente utilizzato per indicare la fine della stringa nei linguaggi di tipo C (probabilmente gli utenti possono modificare la memoria dopo la fine della stringa). Anche ritorni a capo e avanzamenti riga \r (ascii 13) e \n (ascii 10), poiché spesso dipendono dal sistema se le interruzioni di riga sono \r\n o \n e questo porta all'inevitabile che posso accedere solo da Windows, non dalla mia macchina mac/linux. In effetti, sembra abbastanza ragionevole consentire solo ascii stampabile (32-126) e vietare il non stampabile ASCII 0-31 e 127.

Ma se per caratteri speciali intendi unicode not ASCII caratteri (come ,./<>?;':"[]{}\|[email protected]#$%^&*(-=_+ sembra ragionevole per la semplicità di implementazione da più sistemi operativi/tastiere/browser non consentire caratteri speciali. Immagina che la tua password contenga una lettera minuscola. Era che il greco pi (π) che è il punto di codice 0x3c0 o il copto minuscolo pi (ⲡ) che è il punto di codice 0x2ca1 - funzionerà solo uno e questo tipo di problema di caratteri simili con punti di codice diversi esisterà in Unicode. Il tuo hash che opera su bit non sarà in grado di equiparare i due π, quindi se provi ad accedere in posti diversi potresti inserire caratteri diversi.

Allo stesso modo, sebbene questo problema sia un problema il programmatore può controllare e tentare in gran parte di correggere, consentendo 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 dell'unicode. È UTF-7, UTF-8, UTF-16, UTF-32, Latin-1 (iso-8859-1), codifica Latin-N e (per alcune codifiche) qual è l'ordine dei byte (little o big endian) ? Il punto di codice unicode per pi (0x3c0) sarebbe rappresentato come byte 2b 41 38 41 2d in UTF-7, CF 80 in UTF-8, FF FE c0 03 in UTF-16 e FF FE 00 00 c0 03 00 00 in UTF-32. Non saresti in grado di rappresentare pi in Latin-1 (ha solo 95 caratteri extra stampabili), ma se avessi un A1 nella tua password e in diverse codifiche potresti dover rappresentarla con uno dei seguenti caratteri ¡ĄĦЁ‘ก”Ḃ (che in alcuni latini-N maggio ad A1).

Sì, la pagina Web può avere un set di caratteri definito, ma gli utenti possono sovrascrivere il set di caratteri su una pagina nel proprio browser o possono aver copiato e incollato dati altrove in una codifica diversa. Alla fine della giornata, potrebbe essere più semplice vietare quei personaggi.

9
dr jimbob

Come generalizzazione, ecco i motivi più comuni per cui gli istituti finanziari limitano la lunghezza e la complessità del set di caratteri.

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

(2) Non eseguono l'hashing delle password, quindi non possono semplicemente memorizzare una stringa numerica di lunghezza fissa (ovvero l'output hash - 32 byte di SHA256 (password)). Pertanto, devono preoccuparsi di limitare le dimensioni dell'input.

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

Oltre a favorire la semplice reimpostazione della password dell'assistenza clienti SOPRA la sicurezza, NON vi è alcun motivo accettabile di cui sia a conoscenza per la trasmissione di una password utente in chiaro dal dispositivo dell'utente. 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. http://crackstation.net/hashing-security.htm

4
OnTheShelf

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

Il loro consiglio è di usare una password sicura, cambiarla frequentemente, usare lettere e numeri, che dovrebbe essere lunga e forse alcune altre cose che ho dimenticato. Ad ogni modo, segue il solito consiglio che nessuno. Ma sembrano preoccuparsi della politica delle 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 l'assistenza.

Quando li ho rispediti indietro per chiedere che cosa "Hai dimenticato la password?" caratteristica era per, non ho avuto risposta ...

Quindi per le banche, dove una semplice reimpostazione della password via e-mail è fuori discussione, credo che i costi di supporto siano davvero la ragione (come suggerito da altri qui). Per qualsiasi altro sito web come questo bol.com, mi dispiacerebbe molto se hanno le loro password. Dovresti usare una password più unica lì, se il database perde la tua password sarà conosciuta.

2
Luc

Limitare il set di caratteri ad alfanumerici limita la probabilità che uno script o exploit superi 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 prevenire gli attacchi.

1
Rory Alsop

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

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

Ecco un modello di pensiero programmatore comune: ci sono solo tre numeri: 0, 1 e n. Se n è consentito, tutte le n sono ugualmente probabili. Questo modello di pensiero deriva dalla vecchia convenzione di codifica (probabilmente intelligente) secondo cui non si dovrebbero avere costanti numeriche nel codice ad eccezione di 0 e 1.

Ora il pensiero sopra è corretto in un problema di sola programmazione, ma per quanto riguarda le interfacce utente e soprattutto Windows non lo è

Ma non è vero. A quanto pare, non è altrettanto probabile. Ci sono molti buoni motivi per cui potresti volere una finestra esattamente nella parte superiore dello schermo (massimizza la proprietà dello schermo), ma in realtà non ci sono motivi per lasciare due pixel tra la parte superiore dello schermo e la parte superiore della finestra . Quindi, in realtà, 0 è molto più probabile di 2.

Ora arrivando al nostro problema, teoricamente tutti i personaggi dovrebbero essere ugualmente probabili e ugualmente permessi dal punto di vista della programmazione e formale, tuttavia qui ci troviamo anche in un'istanza del problema dell'interfaccia utente e dobbiamo esserne consapevoli e dargli il giusto peso .

Quindi parafraserò una risposta dal thread sopra che secondo me è corretta:

Diciamo che abbiamo permesso a chiunque di creare password che contengono € char. Evviva, siamo in grado di usare caratteri speciali nelle nostre password. Ma aspetta: come mai possiamo digitare quella password se vogliamo ottenere l'accesso alla nostra banca dal telefono cellulare? È più facile digitare € dalla nostra tastiera che dal telefono cellulare.

Questo è il punto principale da un punto di vista dell'usabilità e non dovremmo dare la colpa all'utente se si rende conto qualche anno dopo con uno smartphone quando anni prima che non esistessero, che ha usato un personaggio che avrebbe dovuto evitare.

È nostro dovere pensare a questo tipo di problemi e lasciare che l'utente lo eviti!

0
dendini

Un po 'in ritardo per la festa: di recente ho letto che la ragione di ciò è che per molte banche, il valore della maggiore sicurezza di consentire quei personaggi è compensato dai costi di implementazione e dai costi di supporto della gestione con clienti che non ricordano le loro password .

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

http://www.theglobeandmail.com/technology/digital-culture/why-canadas-banks-have-weaker-passwords-than-Twitter-or-google/article18325257/

0
Steve Campbell