Quali caratteri renderei non validi per una password?

Question

Una situazione ipotetica: hai implementato un sistema di gestione password e non impone alcuna limitazione su quali caratteri possono essere utilizzati. Si desidera impostare alcune regole che costituiscono un ragionevole compromesso tra due elementi:

1. Consentire all'utente la massima libertà possibile.
2. Consentire la possibilità di modificare la modalità di gestione delle password in futuro: non si desidera escludere implementazioni ragionevoli in quanto le password esistenti degli utenti non sarebbero più valide.

Quali regole vorresti imporre? Ci sono altri fattori che potrebbero influenzare la tua scelta?

Answer 1

Il meglio non ha restrizioni di sorta, a meno che non si possa davvero giustificarli.

Se si è una banca, un provider di posta elettronica o se l'utente può ordinare qualcosa senza fornire una carta di credito, è quindi logico che gli utenti utilizzino una password complessa. Altrimenti, lo stai rendendo difficile senza motivo.

Per quanto riguarda ciò che dovresti memorizzare, direi che 1024 caratteri di unicode con caratteri di controllo proibiti riguardano tutto ciò che è giustificato. Se l'utente non può digitarlo, dovrebbe aver scelto una password diversa. Tutto quello che stai memorizzando è un hash, quindi puoi sempre ridurlo a qualsiasi dimensione desideri.

Answer 2

Conserverei tutto ciò che è possibile fare con un tasto (e facoltativamente lo spostamento) sulla tastiera, eccetto la scheda. Che tipo di schemi richiederebbe un'opzione più restrittiva?

Answer 3

Non imporre restrizioni di alcun tipo, mai. E mi sembra che tu stia pianificando di memorizzare la password, non l'hash. Non farlo neanche io. Piuttosto, memorizzare salt e hash una combinazione di password e detto sale.

Tuttavia, è possibile richiedere agli utenti di disporre di una password sufficientemente valida imponendo restrizioni sulla lunghezza (ad esempio, non inferiore a 6 caratteri) e sui caratteri che comprendono la password (ad esempio, deve contenere caratteri alfabetici maiuscoli e minuscoli , una o due cifre e diversi caratteri non alfabetici come^o #).

Answer 4

Gli utenti devono digitare le password che contengono almeno un numero e un carattere non alfanumerico e contenere più di sei caratteri. Ad ogni modo, penso che qualunque sia la limitazione, nel caso in cui si cambi il modo in cui si convalidano le password, è necessario informare gli utenti in tempo utile per aggiornarle.

Answer 5

Qualsiasi carattere non di controllo deve essere corretto. Dovrei pensare che gli sviluppatori di sistemi di password super-duper in futuro consentirebbero caratteri ASCII "insoliti" come la punteggiatura e altri segni, ma i caratteri di controllo hanno l'abitudine di essere ingombranti per entrare in shell in modalità testo e persino in finestre di dialogo che prevedono Tab e Invio/Ritorno per essere liberi per i loro scopi.

Answer 6

Uno spazio vuoto (in base alla logica può essere tagliato accidentalmente, prima di essere hash)

Answer 7

Le regole vorrei suggerire far rispettare:

1. Lunghezza - non meno di 8 caratteri - ma non più di 20
2. Facilità di interruzione: il passaggio non deve contenere il nome, il cognome o il nome dell'utente, né (se possibile controllare) qualsiasi parola che appare nel dizionario inglese.
3. Contenuto: ci sono 4 tipi di caratteri sulla tastiera: maiuscole, minuscole, numeri e segni di punteggiatura. Una buona password dovrebbe includere rappresentanti di almeno 3 gruppi e non più di 2-3 caratteri dello stesso gruppo in una riga.

Answer 8

Nessun limite per la password. Se possono digitarlo dalla tastiera, indipendentemente dalla tastiera regionale che usano. Si consiglia di imporre una lunghezza minima, opzioni come almeno un numero e un carattere speciale, ma nessun limite massimo.

Per quanto riguarda la seconda domanda. Il modo in cui lo implementerei è attraverso la creazione di campi separati man mano che si migliora la forza della password. Ad esempio, al momento avresti due campi relativi alla password: salt, password_md5. Diciamo più tardi che vuoi usare sha256. Crea un nuovo campo chiamato password_sha256. Quando l'utente effettua il login, prima controlla password_sha256. Se quel campo è vuoto, controlla password_md5. Se ciò corrisponde ora hai la password di testo in chiaro che l'utente ha inserito. È quindi possibile generare la password sha256 (anch'io resettare il sale per una buona misura) e memorizzare il nuovo valore. Quindi cancellerei il valore in password_md5 in modo che nessuno potesse invertire per ottenere la password.

Personalmente, mi piacerebbe usare il miglior hash che la tua lingua può fare e usarlo. Le cose importanti sono l'applicazione di una buona politica di password minima - non importa quanto sia sicuro l'hash quando la password è "1234" - e per seminare l'hash con un carattere casuale per evitare attacchi di dizionario.

Answer 9

Nella nostra organizzazione, se l'utente sta fornendo la password, consentiamo loro di utilizzare tutto ciò che desiderano.

Quando gli utenti vengono registrati per la prima volta nel sistema, viene generata una password. Poiché questa password viene solitamente inviata a loro, evitiamo di usare determinati caratteri che potrebbero essere confusi, in particolare quando si utilizzano determinati tipi di carattere. Ad esempio, la lettera O e il numero 0 (zero) non vengono utilizzati. Lo stesso per L, I e 1 (uno), S e 5, Z e 2 e altri.

prima abbiamo fatto questo cambiamento abbiamo avuto un sacco di chiamate al nostro help desk perché i personaggi che confusione e non potevano login.

Answer 10

Personalmente, io uso la tastiera di impronte digitali di DigitalPersona (sì, Microsoft fa [o ha fatto] un dispositivo simile, sia integrato che separato dalla tastiera).

Ciò consente la generazione di password estremamente lunghe e complicate che non devono essere annotate (poiché la pressione del dito sul lettore fornisce la password alla finestra di dialogo di accesso [sistema/applicazione/sito Web]).

Questo, a mio parere, fornisce il meglio di entrambi i mondi: estremamente difficile da "indovinare" le password, senza doverle ricordare. Rende anche semplice la raccomandazione aggiuntiva sulla sicurezza di utilizzare password diverse su sistemi diversi.

Bene, questo è il mio valore di due centesimi.

Answer 11

Personalmente sono sempre stato entusiasta di non applicare troppe regole.

Questo è appena cambiato. Ho appena scoperto che il mio sito Web è vulnerabile agli attacchi XSS. La soluzione è sanificare ogni parte di input che proviene dall'utente, inclusa la password.

Per 10 anni non abbiamo avuto limiti sulla password. Ora stiamo implementando un limite ai caratteri che possono essere utilizzati, e questo è semplicemente per impedire agli hacker di accedere a Javascript o SQL.Quindi abbiamo costruito il seguente elenco:

I caratteri validi per una password sono: a-z A-Z 0-9. - _ $ *() # @! %/(vuoto)

Ciò consente molta flessibilità ma evita i caratteri che potrebbero essere utilizzati nella codifica di un hack XSS, come; <> \ {} [] + =? &,: ' "`

HTH

Answer 12

alcune regole da seguire:

1. Personaggi evitare il controllo Non è così prevalente oggi, ma i caratteri di controllo hanno tutti un significato speciale e alcuni caratteri di controllo intercetta hardware a. Esegui funzioni speciali Alcuni causano problemi di dati Esempio Il controllo 0 (zero) genera un valore nullo
2. Stai per imporre restrizioni di sicurezza? Si tratta di una domanda dell'interfaccia utente oltre che di un problema di sicurezza. bisogno di sicurezza ny degli esempi precedentemente indicati non sono aggiornati. Le tabelle hash per le combinazioni di password sono pubblicate per un massimo di 15 caratteri e le password di 16 caratteri possono essere forzate brute con minuti se la password è debole o segue il tipico comportamento umano. Inizia con una maiuscola, termina con un numero o un carattere speciale.
3. Eviterei i caratteri jolly comuni, virgolette, due punti, punto e virgola, ecc. Che sono comunemente usati nei linguaggi OS o DB.
4. L'autenticazione a più fattori è un buon modo per andare. Non dipendere solo dalla password o non accettare affatto le password.