Perché i servizi clienti affermano che l'utilizzo di simboli in una password non è sicuro?

Queste "misure di sicurezza" non sono per la tua sicurezza, ma per la loro.

Simboli come trattini, apostrofi, segni di percentuale, asterischi, barre, punti, ecc. sono utili agli attaccanti per eseguire attacchi di "iniezione", come SQL Injection, XPath Injection, iniezione di file path, ecc. Bloccando questi caratteri, il i proprietari dei siti sperano che ti impediscano di attaccare i loro server.

Probabilmente dovrebbero concentrarsi maggiormente sulla corretta gestione dei dati, come internamente usando l'SQL parametrizzato e l'escape di caratteri speciali, ma questa è una misura aggiuntiva che potrebbe servire come soluzione temporanea nel caso in cui avessero un errore di codifica nascosto nel loro sito. / p>

Non posso rispondere in modo definitivo "perché" l'hanno fatto. Forse avevano un auditor di sicurezza che diceva "usa un set di caratteri whitelist per l'input dell'utente e blocca tutti i simboli non alfanumerici". Forse il pacchetto web che hanno comprato è venuto con quella restrizione. Forse il loro vicepresidente della sicurezza ha detto "aggiungi alcune misure visibili che danno ai nostri clienti l'impressione che prendiamo sul serio la sicurezza". Chissà perché?

The question is why did they say that its insecure to allow symbols in passwords when symbols make it safer?

Molto probabilmente hai avuto a che fare con qualcuno nel servizio clienti che non ha idea del motivo per cui alcune regole sono state messe in atto ed è arrivata alla conclusione, sia usando questa scusa in passato sia ottenendo risultati o recuperandola in la loro testa, che questo renderà la persona con cui hanno a che fare senza fare domande e basta.

La tua spiegazione ha ragione riguardo alla complessità di una password che diventa molto più sicura aggiungendo simboli, lettere, maiuscole e minuscole e numeri.

Scriverò questo come un agente di servizio clienti non addestrato che sta solo cercando di semplificare il lavoro o che questa persona sa che la politica è viziata e vuole solo rendere questa conversazione il più breve possibile.

Poiché probabilmente utilizzano l'igienizzazione dell'input invece di query parametrizzate e l'igienizzazione dell'output .

Se avessero delle query parametrizzate, questo non sarebbe un problema. Se sapessero come disinfettare il loro output , questo non sarebbe un problema.

Più che probabile, il loro codice è vulnerabile a molte altre cose, come il traffico di contrabbando basato su Unicode . Per molti "sviluppatori sicuri", i servizi igienico-sanitari in input stanno semplicemente rimuovendo gli apostrofi dagli input, il che è un approccio incredibilmente terribile.

Questo non proteggerà il contrabbando basato su Unicode e interferirà con gli scopi legittimi degli apostrofi in un database, come i nomi delle persone. Immagina di provare a cercare il cognome di qualcuno in un database, ma non puoi perché c'è un apostrofo. È stupido.

La soluzione corretta è la seguente: convalida dell'input (null > length > format > white list) ** > ** query parametrizzate > igiene ambientale (per evitare XSS), che probabilmente non seguiranno. Non esiste alcun motivo legittimo per escludere i dati appropriati.

Concorda con la tua analisi sul fatto che consentire i simboli consente una maggiore sicurezza, ma generalmente non è così tanto. Soprattutto se paragonato a una password leggermente più lunga (supponendo che la password sia composta da simboli scelti a caso). Usando uno dei 95 caratteri ascii stampabili:

0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!"#$%&\'()*+,-./:;<=>?@[\]^_'{|} ~

(un po 'di più se si contano caratteri come tabulazione o interruzione di riga come stampabili) una password di 8 caratteri ha possibilità 95 ^ 8 ~ 6,6 x 10 ^ 15, mentre con sole lettere (maiuscole e minuscole) e numeri una password di 8 caratteri ha 62 ^ 8 ~ 2,2 x 10 ^ 14 che è circa 30 volte più debole.

Tuttavia, una password di 9 caratteri con solo numeri + lettere minuscole + maiuscole è due volte più strong di una password di 8 caratteri che consente caratteri speciali. Quindi, a meno che non ci siano limiti rigidi sulla lunghezza di una password (e in realtà non ci sia mai bisogno di almeno una password di poche centinaia di caratteri), è facile passare a password leggermente più lunghe anche con un set di caratteri limitato.

I maggiori potenziali problemi di sicurezza sono se credono che consentire caratteri speciali nelle password possa causare problemi nella loro applicazione o database. Esiste un motivo legittimo per escludere caratteri ASCII non stampabili (ad esempio, caratteri di controllo ASCII NUL ( \b ), backspace ( ' ), ecc.) Che potrebbero causare problemi, ma le applicazioni ben progettate dovrebbero essere in grado di gestire caratteri speciali regolari come - o A3 senza essere vulnerabili agli attacchi di iniezione. Un'applicazione dovrebbe essere in grado di gestire questi tipi di caratteri come appaiono ad esempio nei nomi con citazioni o trattini in essi (ad es. Conan O'Brien, Daniel Day-Lewis). Inoltre, poiché le password non dovrebbero essere salvate nel database o restituite all'utente e immediatamente sottoposte a hash, non dovrebbe importare caratteri speciali ASCII stampabili.

Ci sono dei problemi di usabilità con caratteri speciali non ASCII come unicode, e per problemi di usabilità può essere una buona idea proibire questi caratteri o normalizzarli in un modo standard. In genere le funzioni di hash prevedono una stringa di byte e le password con caratteri speciali oltre ASCII possono essere codificate in diversi modi a livello di byte (ad esempio UTF-8, UTF-7, UTF-16, ISO-8859-1). Inoltre, oltre a codifiche diverse (che puoi mantenere coerenti a livello di applicazione), devi anche preoccuparti di lettere dall'aspetto identico con valori diversi in unicode. Ad esempio il seguente carattere Å è unicode 00C5 , ma questo carattere identico è Å < a href="http://www.fileformat.info/info/unicode/char/212b/index.htm"> unicode 212B mentre questo Å è in realtà di due caratteri - un ASCII A con un carattere di combinazione di unicode 030a aggiungendo un cerchio sopra l'A.

EDIT : Ho appena notato che hai elencato £ come uno dei tuoi simboli comuni. Sfortunatamente non è un simbolo ASCII standard. In ISO-Latin-1, è il byte C2 A3 . In UTF-8 sono i due byte +AKM- . In UTF-7 sono i caratteri ASCII 00 A3 . In UTF-16 è ' . Queste diverse codifiche significano che la tua funzione di hash potrebbe rompersi su questo personaggio se non viene gestito correttamente. Certo, l'applicazione dovrebbe essere in grado di gestire correttamente la codifica, ma potrebbe non riuscire su alcuni sottoinsiemi di dispositivi. Inoltre, il personaggio potrebbe non essere disponibile su tastiere straniere.

Potrebbero esserci anche problemi di usabilità con caratteri come " o ‘’“” che in alcune applicazioni / piattaforme possono essere convertiti in virgolette intelligenti %code% (anche se questo non dovrebbe mai essere fatto in un contesto di password).

Infine, c'è un ulteriore razionale per avere regole di password univoche: rendere più difficile per gli utenti avere una password memorizzata che viene riutilizzata ovunque, che è una pratica di sicurezza orribile. Se la password "normale" dell'utente non soddisfa le regole univoche di un sito, quando la sua normale password viene compromessa su qualche altro sito casuale (che dice memorizza la password in chiaro), il suo account non viene compromesso nel sito con l'unico regole.

Un po 'lungo recuperato ma ...

Dì, la madre di John riceve un IPad per Natale, quindi decide di collegarsi alla sua banca usando (anziché il suo laptop), ma non riesce a capire come "digitare" il simbolo su IPad. Quindi chiede a qualcuno di mostrarle come digitare la sua password ... ..

Ora pensa ai problemi di supporto con i clienti che hanno password che non sanno come "digitare" sui loro telefoni o tablet. Molte chiamate di assistenza che richiedono il ripristino delle password sono un problema di sicurezza e un problema di costi.

Alcuni simboli potrebbero non essere disponibili su tutti i layout di tastiera con cui interagisci. Ciò impedirebbe l'accesso. Questo sarebbe un problema per la disponibilità, non per la sicurezza.

Ma questo potrebbe diventare un piccolo problema di sicurezza se il simbolo in questione fosse disponibile su un layout di tastiera non familiare con cui si sta lavorando, ma non in una posizione familiare. In tal caso, potrebbe essere necessario trovare il tasto giusto prima di inserirlo nel campo della password. E (in particolare in assenza di keycaps corrispondenti) potresti in teoria scrivere dei simboli in qualche editor fino a quando appare il simbolo che cerchi. Quando ti fermi qui, le persone che guardano il tuo editor (mentre digiti o in seguito perché hai dimenticato di chiuderlo) conosceranno almeno uno dei simboli contenuti nella tua password.

Devo concordare con la risposta di Eddie Studer : anche se c'è un'implicazione di sicurezza inverosimile, è probabile è che la persona che ti ha detto di questo non aveva idea della vera ragione dietro quella politica. Potrebbe tuttavia essere stato il problema di disponibilità che ho menzionato in precedenza, che gli utenti non sono in grado di accedere ad es. dagli internet cafè in paesi stranieri. Giusto per fornire un'alternativa ai problemi di iniezione espressi dalla maggior parte delle altre risposte, anche se queste sono ancora una ragione molto probabile.

La maggior parte delle persone non può digitare i simboli senza rallentare e premere più tasti contemporaneamente, quindi c'è una piccola diminuzione della sicurezza se stai cercando di digitare dove potresti essere osservato da un essere umano.

Il tuo argomento è:
1. una password generata a caso con i simboli è più strong di una password generata casualmente della stessa lunghezza con solo lettere e numeri
2. quindi consentire ai simboli nelle password di renderli più forti.

Questo è valido se e solo se le persone generano password in modo casuale.
Confrontiamo però una password creata con il seguente algoritmo:
1. creare una password di lunghezza massima - 1 con numeri e lettere
2. attaccare un simbolo alla fine

Supponendo che il numero di simboli sia inferiore al numero di lettere e numeri, questo produrrà una password più debole di una password casuale di sole lettere e numeri, oltre a fornire un falso senso di sicurezza ('L'ho impostato a password $ , non la password!). Argomenti simili possono essere fatti per generare password sostituendo lettere con simboli ecc.

Quindi si potrebbe decidere che non consentirebbero i simboli, nella speranza che le persone scelgano di usare una password casuale / più lunga invece di pa$$word . Ovviamente, questo "fa male" agli utenti che vogliono usare password casuali con lettere + numeri + simboli. Ma ti aspetteresti che quegli utenti siano sufficientemente istruiti per aggiungere semplicemente qualche altro carattere, risultando in una password di forza equivalente (supponendo che tu non stia limitando la lunghezza).

Tutto sommato, solo perché includere i simboli nelle alcune password aumenta la loro forza, non ne consegue che consentire alle persone di usare i simboli aumenterà la forza della password media.

In alternativa alla loro sicurezza, immagina di dover ricordare la password contenente lettere maiuscole e minuscole, cifre e caratteri speciali, la maggior parte delle persone che vanno a prenderli scriverà quella password su un pezzo di carta, possibilmente insieme al loro login, che sarebbe considerato ad alto rischio di sicurezza
E se usi una password più semplice che puoi ricordare, ci sono molte più possibilità che si perda da te Ovviamente in questo modo bloccano la tua capacità di usare password complicate con password manager, una soluzione più sicura del pezzo di carta, ma comunque la considererei meno sicura del semplice ricordare la tua password o frase di accesso
Ma dire se hanno qualche ragione ragionevole o solo il loro sistema o la gestione è imperfetto è impossibile senza essere insider

Ipotesi XML / Json:

Può essere che la password sia inviata a un webservice (si spera tramite un canale sicuro) e hanno scoperto che caratteri speciali hanno dato origine a XML o Json non validi. Invece di sfuggire alle entità hanno limitato tutti i simboli.

Un problema di sicurezza è che se si è in grado di utilizzare i caratteri di escape " in XML e \" in Json e XML / Json è creato dalla concatenazione di stringhe senza CDATA o l'escaping possono terminare con una citazione nel campo anche se hai controllato la stringa per le virgolette singole e doppie.

Ovviamente la soluzione è evitare la concatenazione delle stringhe per creare query con parametri esterni.

P.S: la password potrebbe anche andare su LDAP aprendo la possibilità di Iniezioni LDAP

Evito i simboli nelle password perché potrebbero essere difficili da digitare, specialmente sui layout di tastiera o sui dispositivi con cui non ho familiarità.

Inoltre, cosa più importante, non mi fido spesso di tutti gli sviluppatori di software. Una volta ho usato password contenenti spazi. Alcuni servizi in seguito hanno cambiato i loro metodi di autenticazione in modo da eliminare gli spazi vuoti dalle password. Questo mi ha reso impossibile accedere.

La mia paura è che cose simili possano accadere anche con altri simboli, specialmente se consideriamo simboli non ASCII. A proposito, il fatto che il servizio clienti stia scoraggiando l'uso di simboli speciali è una strong indicazione del fatto che non dovrebbero essere considerati attendibili e potrebbero fare cose strane (ora o in futuro).

Dopotutto, se pensi ai numeri, l'uso dei simboli non è molto diverso dall'aggiunta di alcuni caratteri alla tua password alfanumerica:

• 100 simboli (tutti i caratteri stampabili ASCII), lunghezza 8: 100 ⁸ combinazioni;
• 62 simboli (lettere e cifre ASCII), lunghezza 9: 62 ⁹ , superiori a 100 ⁸ .

Usare più simboli aiuta, ma aumentare la lunghezza è molto meglio (k ^x cresce più velocemente di x ^k ).

Come @dr jimbob ha detto che stai usando il carattere non stampabile £ nella tua password !@£$%^&*() . Se rimuovi il carattere non stampabile £ dalla tua password, verrà accettato qualunque sia il servizio. Questo perché la crittografia della password è stata sviluppata in c o in Java a livello di core per mantenere l'elevato livello di sicurezza.

È difficile far capire alle persone non tecnologiche i personaggi non stampabili. Quindi il responsabile dell'assistenza clienti ti ha chiesto di utilizzare il carattere alfanumerico semplice e non i caratteri speciali.

Prova la nuova password con !@$%^&*() cambia la password dopo aver eseguito il test poiché è stata pubblicata online.

Semplicemente parlando i caratteri accettati sono tra ASCII da 32 a 126

Questa particolare sequenza è semplicemente tenendo premuto SHIFT e digitando 1234567890. Quindi presumo che stiano disabilitando questa particolare sequenza perché è semplice per un hacker e molte persone lo fanno. Ad esempio, ho visto persone usare QWERASDFZXCV per una password che non è sicura perché stai tenendo premuto shift e spostando il lato sinistro della tastiera.

Ma i caratteri limitati sono piuttosto comuni sia per la password che per il nome utente.

Nel computing sicuro hai qualcosa chiamato superficie di attacco, vulnerabilità e exploit. Separato è l'affidabilità.

Sì, più carattere è più casuale ma hai anche una superficie di attacco più grande.

È possibile creare password sufficientemente casuali con un set di caratteri limitato. 36 ^ 8 = 2,821,109,907,456 è sufficientemente casuale per la maggior parte delle esigenze di sicurezza. Altrimenti, basta alzarlo a 10 o 12 caratteri. Puoi solo sperare che usino caratteri casuali. La vulnerabilità è costituita da password che puoi indovinare FistNameLastNaveYYMMDD dove YYMMDD è la data di nascita.

Alcuni caratteri Unicode sembrano uguali. È possibile creare un segno diacritico come carattere separato. Questi caratteri non sono gli stessi: greco Ο, latino O e cirillico О.

A seconda del set di caratteri (tabella codici) sul tuo computer potresti effettivamente ottenere diversi mapping. L'idea è un insieme sicuro di caratteri deterministici attraverso i set di caratteri.

Devi prendere in considerazione la codifica HTML, la compressione sulla rete, la salatura, ... E i caratteri di controllo?

Devi tracciare la linea in un punto e il fatto è che non hai bisogno di un set di caratteri grandi per creare password sufficientemente casuali.

Questo non riguarda i programmatori che sono pigri o carenti. Si tratta di fornire un codice affidabile solido. Con un set di caratteri controllato puoi testare meglio tutte le possibilità. Se accade qualcosa di strano nella trasmissione, c'è un test più piccolo per capire cosa lo rompe.