Perché alcuni siti impediscono gli spazi nelle password?

Ci sono una quantità enorme di stupidità quando si tratta di password nei siti web.

• Alcuni hanno solo motivi tecnici (valido o no, questa è un'altra domanda, ma quasi tutti non lo sono):

Your password must be four characters length and have only digits.

(Limitando una password all'intervallo 0001 .. 9999, puoi semplicemente archiviarli come numeri, in chiaro, nel database)

• Altri sono spiegati da alcuni pensieri errati che renderanno le password più sicure :

Your password must start with a capital letter and end with a digit.

(In questo modo lo sviluppatore, o il gestore, ha ipotizzato che questo costringa effettivamente gli utenti a scegliere una password sicura, mentre la regola come "La password deve contenere almeno 6 caratteri e contenere almeno una lettera maiuscola, una lettera minuscola e una cifra "non riescono magicamente a farlo)

• Altro, infine, sono spiegati dal fatto che le password sono memorizzate plaintext , e ci sono alcune ambiguità su come vengono memorizzate, elaborate o recuperate, e ci sono non c'è tempo per testarli.

Your password contains an invalid character é.

o

Your password y$₯46¥*A'xD<7&฿=ᴙcN&sF5_Ở!d contains some invalid characters. Use characters from Latin alphabet and digits only.

o

Your password cannot contain whitespace characters.

In tutti e tre i casi, lo sviluppatore si è assicurato che password come questa verranno archiviate correttamente.

• Nel primo caso, cosa succede se é verrà trasformato in %C3%A9 quando inviato? O se il database memorizzasse é in modo errato?

• Nel secondo caso, cosa succede se PHP (perché PHP?) non può gestire unicode e fa qualcosa di terribile quando riceve una password come questa? Cosa succede se il carattere < causa problemi? Cosa succede se il carattere & viene interpretato come separatore in un URL (presupponendo che, per qualche motivo, la password venga inviata tramite GET anziché POST)? Cosa succede se ' viene interpretato dal database, perché, indovina cosa, non abbiamo idea di cosa sia SQL Injection e come evitarlo? O cosa succede se ' viene trasformato in \' ?

• Nel terzo caso, che succede se PHP (ancora?) taglia gli spazi bianchi in alcuni casi e non in altri? Cosa succede se gli amministratori (che hanno sorprendentemente l'accesso alle password degli utenti in testo semplice) vengono persi perché vedono solo uno spazio bianco, mentre l'utente ha impostato tre spazi bianchi consecutivi ?

In tutti e tre i casi, tali ambiguità sono facilmente risolvibili tramite test , in particolare i test di unità. Ma in una quantità enorme di progetti, non ci sono affatto test e non c'è tempo per testare (ma c'è ancora tempo per eseguire il debug in un secondo momento).

Ciò significa che lo sviluppatore cerca di pensare alle possibili conseguenze di consentire spazi , o caratteri unicode, o qualsiasi carattere al di fuori di ASCII 48..57 ∪ 65..90 ∪ 97 .. 122 (cifre, lettere minuscole, lettere maiuscole), il modo più semplice, quando il test non è possibile, è vietarli solo .

Secondo me, questa è l'unica ragione per vietare gli spazi. Yannis Rizos ha fornito un altro motivo correlato a UX. Pur essendo una ragione plausibile in teoria, nella pratica non funziona affatto: i siti Web creati da persone che si preoccupano veramente di UX non risolvono le stupide regole della password. Invece, siti web in cui gli spazi bianchi sono effettivamente proibiti sono in gran parte realizzati da persone che non hanno mai sentito parlare di UX . Questo è particolarmente vero dal momento che vietare qualsiasi carattere è davvero fastidioso dal punto di vista di UX, come qualsiasi restrizione relativa alla password, compresi gli utili, come il numero minimo di caratteri.

La risposta è Cronologia

Sembra che dimentichiamo che la base di tutto ciò deriva da un periodo in cui lo storage non era effettivamente gratuito (su disco o in memoria) quando la nostra capacità di gestire tutte queste cose era leggermente inferiore a quella attuale e ugualmente la capacità dei sistemi automatici di tentare di crackare lo stesso è stata anche un po 'meno.

Ci sono un sacco di sproloqui sulle password basate su ciò che sappiamo adesso e su cosa possiamo fare ora, ma il semplice fatto è che spesso ci occupiamo di una combinazione di sistemi legacy e sistemi legacy.

Dovrebbero esserci delle restrizioni nei nuovi sistemi ora ? Spero di no - molto meno motivo ora

IMHO, È assolutamente stupido qualsiasi sito / app che usi l'hashing e / o la salatura moderni per archiviare le password per non consentire spazi nelle password. Ma alcuni sistemi legacy (letti da qualche parte) passano ancora le password in testo in chiaro - quindi non permettere che gli spazi possano avere un senso. Inoltre, alcune app potrebbero "rimuovere" tutti gli input di stringa che ricevono. Quindi, una password che inizia o termina con uno spazio non sarà buona (ovviamente, è stato troppo inventato, ma puoi immaginare cosa non può accadere con quasi nessuno in arrivo con il suo sito). Non c'è nulla di "cattivo" nel consentire spazi nelle password - come si fa notare, i DB non impediranno gli hash o le versioni in testo semplice.

In realtà la maggior parte dei miei amici Windows non sanno che possono usare gli spazi nelle loro password - Quindi, forse, come da risposta di Tim Medora, i proprietari dei siti non vogliono correre rischi con Lamah (scusate questo) o forse alcuni di loro hanno idee sbagliate e / o ignorano i vantaggi che gli spazi possono offrire.

È fatto per lo stesso motivo per cui molti siti don ' t consentire trattini, apostrofi o lettere non ASCII nei nomi, anche se queste sono pratiche molto comuni anche solo negli Stati Uniti e richiede più lavoro per disabilitare questi caratteri piuttosto che consentirli semplicemente.

Anche per lo stesso motivo molti filtri di parole di molti siti non ti permetteranno di usare parole come "arrogante", "ritardante" o addirittura "accumulare" (anche se molte insulti razziali comuni sono perfettamente a posto).

È perché molti sviluppatori sono apparentemente del tutto privi del buon senso, o almeno hanno un'immaginazione molto limitata nel considerare possibili input e scenari dell'utente. Una piccola percentuale di esse può funzionare senza informazioni false (che escludere caratteri non alfanumerici è in qualche modo una pratica standard o che l'algoritmo di hashing o il metodo di archiviazione non possono gestire spazi o caratteri speciali). Altri potrebbero semplicemente essere pigri: sono preoccupati per problemi di charset, quindi limitano semplicemente gli input a uno spazio di caratteri minimo. E poi ci possono essere quelli che stanno esercitando zelanti convalide / servizi igienico-sanitari a causa della paranoia a causa della mancanza di comprensione delle minacce reali.