Sto pianificando di sviluppare un sito web che richieda agli utenti di registrare un nome utente e una password. Quando permetto all'utente di scegliere una password, quali caratteri devo consentire agli utenti di avere la password? c'è qualcosa che non dovrei a causa di problemi di sicurezza con il protocollo http o il linguaggio di implementazione?
Non ho ancora deciso per un linguaggio di implementazione, ma userò Linux.
Da una prospettiva di sicurezza / implementazione, non dovrebbe essere necessario disabilitare caratteri diversi da '\ 0' (che è comunque difficile da scrivere). Maggiore è il numero di caratteri, minore è lo spazio di fase totale delle password possibili e, quindi, più rapido sarà il passaggio delle password a forza bruta. Ovviamente, la maggior parte delle parole d'ordine utilizza effettivamente parole di dizionario piuttosto che ricerche sistematiche del dominio di input ...
Da una prospettiva di usabilità , tuttavia, alcuni caratteri non vengono digitati allo stesso modo su macchine diverse. Ad esempio, ho due computer diversi qui dove shift-3 produce # su uno e £ sull'altro. Quando digito una password, entrambi appaiono come "*", quindi non so se ho capito bene o no. Alcune persone pensano che potrebbe confondere le persone abbastanza da iniziare a disabilitare questi personaggi. Non penso che valga la pena farlo. La maggior parte delle persone reali accede a servizi reali da uno o forse due computer e non tende a inserire molti caratteri estesi nelle loro password.
Ci possono essere problemi con caratteri non ASCII. Una password è una sequenza di glifi, ma l'elaborazione della password (hashing) richiede una sequenza di bit , quindi deve esserci un modo deterministico per trasformare i glifi in bit. Questa è l'intera oscura palude di code page . Anche se ti limiti a Unicode , ci sono problemi a venire:
Un singolo carattere può avere diverse scomposizioni come punti di codice. Ad esempio, il carattere "é" (che è molto frequente in francese) può essere codificato come un singolo punto di codice U + 00E9 o come sequenza U + 0065 U + 0301; entrambe le sequenze sono pensate per essere equivalenti. L'acquisizione dell'uno o dell'altro dipende dalle convenzioni utilizzate dal dispositivo di input.
Una stringa Unicode è una sequenza di punti di codice (che sono numeri interi nell'intervallo da 0 a 1114110). Esistono diverse codifiche standard per convertire una tale sequenza in byte; i più comuni saranno UTF-8, UTF-16 (big-endian), UTF-16 (little-endian), UTF-32 (big-endian) e UTF-32 (little-endian). Ognuno di questi può iniziare o meno con una BOM .
Quindi una singola "é" può essere codificata in modo significativo in byte con almeno venti varianti distinte, e questo è quando si passa a "mainstream Unicode". Codifica Latin-1 o Microsoft controparte , è anche molto diffuso, quindi fai quel 21. Quale codifica un determinato software userà può dipendere da molti fattori, incluso il locale . È fastidioso quando l'utente non può più accedere al suo computer perché ha cambiato la configurazione da "Canadese-Inglese" a "Canadese-Francese".
Sperimentalmente , la maggior parte dei problemi di questo tipo viene evitata limitando le password all'intervallo di ASCII stampabile caratteri (quelli con codici che vanno da 32 a 126 - personalmente eviterei lo spazio, quindi rendi 33 a 126) e applicando la codifica mono-byte (nessuna distinta base, un carattere diventa uno byte). Poiché le password devono essere digitate su varie tastiere senza feedback visivo, l'elenco di caratteri dovrebbe essere ancora più limitato per l'usabilità ottimale (combatto quotidianamente con layout canadese in cui ciò che è scritto sulla tastiera non corrisponde necessariamente a quello che la macchina pensa di essere, specialmente quando passa attraverso uno o due Connessioni RDP ; i caratteri" < "," > "e" \ "si spostano molto spesso). Con solo lettere (maiuscole e minuscole) e cifre, andrà bene.
Potresti dire che l'utente è responsabile; è libero di usare qualsiasi personaggio desideri, purché si occupi del problema di digitarli. Ma questo non è assolutamente sostenibile: quando gli utenti hanno problemi, chiamano il tuo helpdesk e devi assumere parte dei loro errori.
Se hai generazione di password casuali, è una buona idea evitare personaggi che possono essere confusi per gli altri. Ad esempio (ignorando i simboli):
l, o
I, O
1, 0
Oltre a consentire tutti i personaggi, prendi in considerazione una lunghezza massima molto generosa sul campo della password per supportare le persone che adottano l'approccio passphrase alle password.
La frase "la mia password è tutto in lettere minuscole" è in realtà una passphrase valida e ragionevole a causa della sua lunghezza.
Non dovresti disabilitare alcun personaggio. potresti desideri impedire che le password siano più corte di 6 caratteri. E poi dovresti usare bcrypt per cancellare la password.
Penso che a meno che non sia disponibile una "tastiera virtuale" o uno strumento simile, che produrrebbe caratteri in modo uniforme, abbiamo solo caratteri alfanumerici. La posizione di tutto il resto può differire su diverse tastiere. Se un utente deve accedere al servizio da un'altra posizione, ciò potrebbe comportare un blocco efficiente fuori servizio.
Suggerirei di usare la tastiera virtuale come un modo per inviare esattamente le stesse rappresentazioni di caratteri (è già stato detto su Unicode sopra) allo stesso modo, indipendentemente dal sistema / tastiera / qualsiasi cosa venga usata. Pertanto non sarà necessario escludere caratteri che potrebbero essere digitati su qualsiasi parola chiave.
Ci sono un paio di caratteri che potrebbero causare problemi:
*,? e%: poiché sono spesso usati come caratteri jolly, possono confondere il linguaggio di programmazione sottostante.
Tab, Return, NewLine, Tab Vertical, Escape: tali caratteri speciali possono sollecitare comportamenti strani dal tuo linguaggio di programmazione O dal browser utilizzato dal cliente. (Se il cliente utilizza diversi browser diversi è del tutto possibile che uno consenta che questi vengano inseriti e un altro browser non. Blocca effettivamente il cliente dal proprio account su quel browser.)
\ è spesso trattato come un personaggio di fuga che dà al personaggio che segue un significato speciale.
Per esempio. "\ n" è newline in molti casi. "\ t" è tab.
Se il tuo linguaggio di programmazione (o il browser dei clienti) fa questo, sei tornato alla possibilità di ricevere i caratteri che ho menzionato sopra.
Quindi è probabilmente meglio scartare \ tutto insieme per sicurezza.
Se si abilitano i caratteri alfanumerici maiuscoli e minuscoli e si imposta la lunghezza minima della password su otto caratteri, si dovrebbe essere OK. Permettere ad altri personaggi solleva problemi con diverse tastiere.
Leggi altre domande sui tag passwords web-application password-policy