Perché alcuni siti impediscono gli spazi nelle password?

Sembra meno comune con i siti Web più recenti, ma molti siti Web su cui ho bisogno di un account (come per pagare le bollette, ecc.) Mi impediscono di creare una password con spazi all'interno. Questo rende solo le cose più difficili da ricordare , e sono a conoscenza di nessun database o restrizioni di programmazione sugli spazi nelle password, crittografate o (paradiso proibito) in caso contrario. Perché, quindi, la barra spaziatrice è così comunemente discriminata quando si tratta di registrarsi a un sito?

Esistono moltissime stupidità quando si tratta di password nei siti Web.

• Alcuni hanno motivi puramente tecnici (validi o meno, questa è un'altra domanda, ma quasi tutti non lo sono):

La password deve contenere quattro caratteri e contenere solo cifre.

(Limitando una password all'intervallo 0001 .. 9999, è possibile semplicemente memorizzarli come numero, testo normale, nel database)

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

La password deve iniziare con una lettera maiuscola e terminare con una cifra.

(In questo modo lo sviluppatore o il gestore hanno ipotizzato che ciò costringerà effettivamente gli utenti a scegliere una password sicura, mentre la regola come "La tua password deve contenere almeno 6 caratteri e contenere almeno una lettera maiuscola, una lettera minuscola e un digit "non riuscirà magicamente a farlo)

• Altri, infine, sono spiegati dal fatto che le password sono memorizzate in chiaro e che ci sono alcune ambiguità su come sono archiviate, elaborate o recuperate e non c'è tempo per testarle.

La tua password contiene un carattere non valido é.

o,

La tua password y$₯46¥*A'xD<7&฿=ᴙcN&sF5_Ở!dcontiene alcuni caratteri non validi. Usa solo caratteri dell'alfabeto latino e delle cifre.

o,

La tua password non può contenere caratteri di spazi bianchi.

In tutti e tre i casi, lo sviluppatore era solo sicuro che password come questa sarebbero state memorizzate correttamente.

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

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

• Nel terzo caso, cosa succede se PHP (di nuovo?) 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 chiaro) vengono persi perché vedono solo uno spazio bianco, mentre l'utente ha impostato tre spazi bianchi consecutivi ?

In tutti e tre i casi, queste ambiguità possono essere facilmente risolte attraverso i test , in particolare i test unitari. Ma in una grande quantità di progetti, non ci sono test e non c'è tempo per testare (ma c'è ancora molto tempo per eseguire il debug in seguito).

Ciò significa che se lo sviluppatore tenta di pensare alle possibili conseguenze del consentire spazi , caratteri unicode o qualsiasi altro 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, è semplicemente vietarli .

Secondo me, questa è l'unica ragione per vietare gli spazi. Yannis Rizos ha fornito un'altra ragione legata alla UX. Pur essendo una ragione plausibile in teoria, in pratica non funziona affatto: i siti Web realizzati da persone che si preoccupano effettivamente di UX non fissano regole stupide per le password. Invece, i siti Web in cui è effettivamente vietato lo spazio bianco sono in gran parte realizzati da persone che non hanno mai sentito parlare di UX . Ciò è particolarmente vero poiché vietare qualsiasi personaggio è davvero fastidioso dal punto di vista UX, come qualsiasi restrizione relativa alla password, compresi quelli utili, come il numero minimo di caratteri.

La risposta è storia

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

Ci sono molti dubbi sulle password basate su ciò che sappiamo ora e cosa possiamo fare ora, ma il semplice fatto è che spesso abbiamo a che fare con una combinazione di pensiero legacy e sistemi legacy.

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

IMHO, è assolutamente sciocco su qualsiasi sito / app che utilizza hash e / o sale moderni per archiviare le password per non consentire spazi nelle password. Tuttavia, alcuni sistemi legacy (leggi su questo da qualche parte) passano ancora intorno alle password in chiaro - quindi non lasciare spazio lì potrebbe avere 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, era troppo inventata, ma puoi immaginare cosa non può succedere con quasi chiunque si avvicini al suo sito). Non c'è nulla di "cattivo" nel consentire spazi nelle password - come sottolineato, i DB non consentiranno gli hash o le versioni in testo normale.

In realtà la maggior parte dei miei amici di Windows non sa che possono usare spazi nelle loro password - Quindi, forse, secondo la risposta di Tim Medora, i proprietari dei siti non vogliono rischiare con i lamah (scusatemi) 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 non consentono 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 impedire a questi caratteri che semplicemente consentire loro.

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

È perché a quanto pare molti sviluppatori mancano completamente di buon senso, o almeno hanno un'immaginazione molto limitata quando si considerano possibili input e scenari dell'utente. Una piccola percentuale di questi potrebbe lavorare su informazioni false (che escludere i caratteri non alfanumerici è in qualche modo una pratica standard o che l'algoritmo di hashing o il metodo di archiviazione non è in grado di gestire spazi o caratteri speciali). Altri possono semplicemente essere pigri: sono preoccupati per i problemi relativi ai set di caratteri, quindi limitano semplicemente gli input a uno spazio di caratteri minimo. E poi potrebbero esserci quelli che stanno esercitando convalide / servizi igienico-sanitari troppo zelanti a causa della paranoia a causa della mancanza di comprensione delle minacce reali.