Punire gli utenti per password non sicure [chiuso]

Sto pensando di limitare i diritti degli utenti che scelgono password non sicure (l'insicurezza di una password è determinata dalla lunghezza, quanti tipi di caratteri (lettere maiuscole / minuscole, numeri, simboli, ecc.) E se può essere situato in una tabella arcobaleno) per limitare la quantità di danni che il loro account può fare se compromesso.

Non ho ancora un'applicazione per questa idea, ma dico che sto scrivendo un forum o qualcosa del genere: gli utenti che utilizzano 1234 come password potrebbero dover compilare un captcha prima di pubblicare o essere soggetti a rigorose misure anti-spam come come timeout o filtri bayesiani che rifiutano il loro contenuto. Se questo forum è molto gerarchico, consentendo la "promozione" per i moderatori o qualsiasi altra cosa, ciò impedirebbe loro di ottenere privilegi o dire loro che hanno privilegi, ma non permettere loro di esercitarli senza passare a un più sicuro parola d'ordine.

Ovviamente questa non potrebbe essere l'unica misura di sicurezza, ma potrebbe andare bene accanto ad altre buone pratiche di sicurezza.

Cosa pensi? Si tratta solo di esagerare, rubare attenzione a pratiche di sicurezza più importanti o è un buon modo per limitare il rischio e incoraggiare gli utenti a utilizzare password più sicure (e si spera convincere le persone che si stanno utilizzando buone pratiche di sicurezza)?

YAGNI , KISS , DRY , la regola dei 10 secondi e il fatto che "[u] non si preoccupi per te" dovrebbe probabilmente restringerlo a una soluzione: non farlo.

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

O forzare una password sicura al cambio di registrazione o utilizzare un OpenId (Jeff Atwood's 2c: http://www.codinghorror.com/blog/2010/11/your-internet-drivers-license.html ). Quindi concentrati su funzionalità più interessanti.

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

Perché in primo luogo consentire le password che ritieni dannose? Fermare il problema alla fonte ti farà risparmiare un sacco di tempo di progettazione cercando di capire quali classi di password associano a quali ruoli. Poiché un amministratore, per definizione, avrebbe tutti i diritti, avresti già bisogno di funzionalità per assicurarti che non inserisca una password che lo limiti.

La mia risposta arriva proprio a KISS .

Come utente, questo probabilmente mi convincerebbe a non usare il tuo sito. Voglio dire, sul serio, la mia banca mi dice che un codice di 6 cifre è perfettamente sicuro per l'online banking, ma quando voglio scrivere un commento su un blog meno conosciuto, 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 a memoria la sequenza unicode. E cambiarlo regolarmente.

Non fraintendetemi, la sicurezza è importante. Ma se non dovresti infastidire i tuoi utenti a meno che tu non abbia una ragione molto forte per credere che qualcuno proverà a decifrare le loro password per ottenere l'accesso al tuo sito. Se il tuo sito fornisce l'accesso VPN alla rete dell'FBI, vai avanti, infastidito. Ma se è un forum di utenti in cui chiunque abbia un indirizzo e-mail può iscriversi, qual è il punto, davvero?

Soluzione migliore: faccine.

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

1. Non puoi costringere tutti a prendere decisioni sagge.
2. Alla gente piace essere libera 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 probabilmente frustrante e confonderli ... soprattutto per la maggior parte delle persone che non leggono le spiegazioni scritte accuratamente nelle finestre di dialogo e chiamano semplicemente l'Helpdesk per dire "Non opera."
2. Durante la creazione di password, gli utenti non devono vedere un elenco di tutte le possibilità di caratteri speciali e tali che possono utilizzare. Meglio mostrare loro un piccolo pop-up che suggerisce che aggiungono un po 'di complessità solo se la loro voce non soddisfa i requisiti.
3. Le persone sono fortemente influenzate dagli spunti sociali - anche i più piccoli amano facce felici che dimostrano che approviamo il loro comportamento o facce accigliate se non lo facciamo. Alcuni dei siti Web meglio progettati mostreranno una barra di avanzamento colorata che passa dal rosso per Non abbastanza buono :( al verde per Buon lavoro! :) mentre l'utente digita la password (proposta) e la conferma. Questa interfaccia utente dà loro una certa pressione sociale per soddisfare gli standard - per far diventare verde la barra o cambiare il cipiglio in un sorriso - mentre scoprono da soli come creare password più sicure con l'aiuto del feedback immediato del cambi di colore.

Non accatastare, ma ho pensato a un altro motivo per archiviarlo in "Bad Idea" che non ho ancora visto menzionato: l'assistenza clienti.

Se questo è un prodotto che avrà alle spalle rappresentanti del servizio clienti, non gli piacerà molto. Una delle ipotesi alla base del supporto è che comprendono e possono prevedere l'esperienza dell'utente - se stanno aiutando un utente normale, allora Pagina 1 dovrebbe avere collegamenti a Pagine 2, 3 e 4, dove possono fare X, Y, Z , eccetera.

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 ... merda, sta negando l'accesso a una delle punizioni per una password sbagliata, o sto pensando a Pagina 5? Consentitemi di cercarlo, solo un momento ... ok, dice che per una password che non mescola lettere maiuscole e minuscole, l'accesso alle pagine pari è consentito ma limitato alla sola lettura ... ok, signore, la tua password, è composta da tutte le lettere maiuscole o minuscole? Astuccio. Quando si digita semplicemente la lettera, è in minuscolo; quando usi maiusc, è allora che è in maiuscolo. Hai mescolato i casi nella tua password? La password che hai usato per accedere al sistema. Quello che hai appena usato. Va bene, vai su Modifica, quindi seleziona Preferenze, quindi Sicurezza. Seleziona "Password salvate" ... no, signore, non riesco a vedere le tue password da qui ....

Si. Non farlo

Limitare le password o informare gli utenti sui 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ù forte se sta per finire su una nota adesiva sotto la tastiera o registrata sul portatile (non riesco a inventare quella roba; l'ho visto accadere).

e se può essere posizionato in una tabella arcobaleno

Immagino che intendi dizionario e non tavolo arcobaleno. L'attacco del dizionario funziona solo testando tutte le parole del dizionario se corrispondono alla password. Questo attacco può essere risolto con 5 tentativi e il blocco per x minuti ...

Una tabella arcobaleno verrà utilizzata solo se si hash la password e l'attaccante conosce l'hash. Quindi potrebbe essere in grado di trovare l'hash nel tavolo arcobaleno se fosse solo "12345" o qualcosa di simile.

Solo per completare il viaggio di andata e ritorno: per rendere inutile una tavola arcobaleno dovresti salare le password. E usa un salt inequivocabile per ogni password e non solo per tutti. Se lo fai, l'attaccante deve creare una tabella arcobaleno con il sale unico per ogni account a cui desidera accedere. Intelligente fatto al tuo fianco, puoi ravvivare l'hash con la concatenazione di algoritmi di hash multipli in modo che una generazione possa richiedere mezzo secondo. Se hai fatto questo, accedere a un account sul tuo sito Web deve valere giorni, probabilmente mese di generazione di hash per trovare una corrispondenza con questo account ... Non riesco a pensare a un utente malintenzionato che cercherà di ottenere tutte le password quando lo farà impiega così tanto tempo.

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