Punire gli utenti per password non sicure [chiuso]

YAGNI , KISS , DEY , 10 secondi di regola e il fatto che " [u] sers non si preoccupa per te " dovrebbe probabilmente ridurlo a una soluzione: non farlo.

• È più un lavoro di sviluppo che richiederebbe un lotto di test per essere affidabile e sicuro.
• Probabilmente riduce la sicurezza del sito in qualsiasi modo tu lo guardi. La possibilità che alcuni bug comportino l'escalation dei privilegi con una password terribile è troppo grande.
• Aumenta la complessità per lo sviluppatore, tester, manutentore, DBA, sysadmin e utente.
• Più complessità, più difficile è evitare di ripeterti in qualche modo.
• Gli utenti non hanno la capacità di attenzione di leggere le tue informazioni e di seguirle. Sono abituati a modificare il modulo di registrazione finché non accetta l'input, non fino a quando non raggiungono un livello ideale.
• Agli utenti non interessa.

O forzare una password sicura al cambio di registrazione, o usare un OpenId (Jeff Atwood's 2c: link ). Quindi concentrati su funzionalità più interessanti.

Per prima cosa, gli utenti sono abituati a essere costretti a creare password sicure o ad usare OpenId, quindi è semplice per loro.

Perché consentire alle password di sentirsi male in primo luogo? Fermare il problema all'origine ti farà risparmiare un sacco di tempo per la progettazione cercando di capire quali classi di password vengono mappate a quali ruoli. Dal momento che un amministratore, per definizione, avrebbe i diritti completi, avresti già bisogno di funzionalità per assicurarti che non immetta una password che lo limiti.

La mia risposta si riduce a KISS .

Come utente, questo probabilmente mi convincerebbe a non usare il tuo sito. Voglio dire, seriamente, la mia banca mi dice che un codice a 6 cifre è perfettamente sicuro per l'online banking, ma quando voglio scrivere un commento su un blog meno noto, dovrei ricordare una password unica contenente almeno 8 in alto - e caratteri minuscoli, una cifra, un carattere speciale e un simbolo greco o cirillico che possono essere inseriti solo se si conosce la sequenza Unicode a memoria. E cambialo regolarmente.

Non fraintendermi, la sicurezza è importante. Ma se non dovresti infastidire i tuoi utenti a meno che tu non abbia davvero forti motivi per credere che qualcuno cercherà di decifrare le loro password per accedere al tuo sito. Se il tuo sito dovesse fornire l'accesso VPN alla rete dell'FBI, fallo, infastidisci. Ma se si tratta di un forum utente in cui chiunque può iscriversi a un indirizzo email, qual è il punto, davvero?

Soluzione migliore: faccine.

Sono serio! Leggere libri di economia comportamentale come "Spinta: migliorare le decisioni su salute, ricchezza e felicità" mi hanno convinto di alcune cose:

1. Non puoi convincere tutti a prendere decisioni sagge.
2. Alle persone piace essere libero di scegliere, ma a loro non piacciono molte opzioni.
3. Tuttavia puoi influenzare in modo significativo le loro scelte in meglio con semplici trucchi.

Vedo che questi principi si applicano alla tua situazione in questo modo:

1. Limitare gli utenti in base a password non sicure è molto probabile che li frusterà e li confonderà ... specialmente per la maggior parte delle persone che non leggono le spiegazioni attentamente scritte nelle finestre di dialogo e chiamano semplicemente l'Helpdesk per dire: " non funziona. "
2. Durante la creazione di password, gli utenti non hanno bisogno di vedere un elenco di tutte le possibilità di caratteri speciali e come possono usarli. Meglio mostrare loro un piccolo pop-up che suggerisce di aggiungere un po 'di complessità solo se la loro voce non soddisfa i requisiti.
3. Le persone sono strongmente influenzate da indizi sociali - anche piccoli come facce felici che mostrano che approviamo il loro comportamento, o facce accigliate se non lo facciamo. Alcuni dei migliori siti web mostreranno una barra di avanzamento colorata che cambia da rosso a Non abbastanza buono: ( a verde per Buon lavoro!:) mentre l'utente digita la loro (proposta) password e conferma. Questa interfaccia utente dà loro una certa pressione sociale per soddisfare gli standard - per fare in modo che il bar diventi verde, o cambiare il cipiglio in un sorriso - mentre scoprono da soli come creare password più sicure con l'aiuto del feedback immediato del cambiamenti di colore.

Non ammucchiarmi, ma ho pensato ad un altro motivo per archiviarlo sotto "Bad Idea" che non ho ancora visto menzionato - assistenza clienti.

Se si tratta di un prodotto che riceverà ripetizioni di assistenza clienti, a loro non piacerà molto. Una delle ipotesi sottostanti del supporto è che capiscono e possono prevedere l'esperienza dell'utente - se stanno assistendo un utente normale, allora Pagina 1 dovrebbe avere collegamenti a Pagine 2, 3 e 4, dove possono fare X, Y, Z , ecc.

Ora, stai dando loro un'altra variabile di cui devono tenere traccia. Se l'utente non vede il link a pagina 4, è perché ha fatto qualcosa di stupido? O è perché la loro password fa schifo e il tuo sistema li sta punendo negando loro l'accesso a Page 4? Aspetta ... stronzate, sta negando l'accesso a una delle punizioni per una password sbagliata, o sto pensando a Page 5? Consentitemi di dare un'occhiata, solo un momento ... okay, si dice che per una password che non mischia lettere maiuscole e minuscole, l'accesso alle pagine pari è permesso ma limitato alla sola lettura ... okay, signore, la tua password, è composta da lettere maiuscole o minuscole? Astuccio. Quando scrivi la lettera, è in minuscolo; quando usi shift, è quando è maiuscolo. Hai mescolato i casi con la tua password? La password che hai usato per accedere al sistema. Quello che hai appena usato. Ok, vai su Modifica, quindi seleziona Preferenze, quindi Sicurezza. Seleziona "Password salvate" ... no, signore, non posso vedere le tue password da qui ....

Sì. Non farlo.

Limitare le password o informare gli utenti dei rischi di password deboli. Immagino che se un utente non si preoccupa dei propri dati potresti voler limitare l'accesso ad altri. Forse gli utenti si sentono più sicuri se coloro che seguono pratiche di password imprudenti vengono eliminati. Qual è il punto di richiedere una password più strong se sta per finire su una nota appiccicosa sotto la tastiera o attaccata al laptop (non riesco a farcela, l'ho vista accadere.)

and whether it can be located in a rainbow table

Immagino tu intenda un dizionario e non un tavolo arcobaleno. L'attacco dizionario funziona semplicemente testando tutte le parole del dizionario se corrispondono alla password. Questo attacco può essere risolto con 5 tentativi e bloccando per x minuti ...

Una tabella arcobaleno verrà utilizzata solo se si hash la password e l'hacker conosce l'hash. Di quanto potrebbe essere in grado di trovare l'hash nella tabella arcobaleno se fosse solo "12345" o qualcosa di simile.

Solo per completare il viaggio di andata e ritorno: per rendere inutile un tavolo arcobaleno è necessario salare le password. E usa un unqiue salt per ogni password e non solo uno per tutti. Se lo fai, l'attaccante deve creare una tabella arcobaleno con il sale unico per ogni account a cui desidera accedere. Fatto intelligente al tuo fianco, puoi aumentare l'hash con l'algoritmo di hash multiplo di concatenazione in modo che una generazione possa impiegare mezzo secondo. Se hai fatto questo, l'accesso a un account sul tuo sito web deve valere giorni, probabilmente un mese di generazione di hash per trovare una corrispondenza con questo account ... Non riesco a pensare a un utente malintenzionato che proverà a ottenere tutte le password quando lo farà prendi così tanto.

Per il momento dell'hashing: pensa a 500 ms di tempo di attesa per un meccanismo di accesso. Penso che sia accettabile ... (un promemoria: quasi un secondo prende una stretta di mano per SSL)