Sta costringendo gli utenti a utilizzare una password sicura efficace?

Le domande specifiche:

Questo metodo sarebbe più sicuro / efficace rispetto a consentire agli utenti di sceglierne uno proprio?

Sì. Ridurrete la riutilizzazione della password e rimuoverete immediatamente le password molto comuni.

Qualcuno ha esperienza con l'implementazione di uno schema simile? È stato efficace?

Ho visto molti schemi di password "alternativi" in passato. La maggior parte ha appena aggiunto problemi di supporto e complicazioni senza sostanzialmente migliorare la sicurezza.

La divisione del campo della password in più di un campo distinto è vantaggiosa o espone troppe informazioni?

Penso che tu abbia già sconfitto gli attacchi automatizzati di non conoscenza basandosi semplicemente sulla differenza. Questo lascia un attacco mirato. Tuttavia, se è disponibile la registrazione pubblica, l'aggressore può scoprire che sono necessarie 5 parole o altro. Quindi non penso che tu stia fornendo all'attaccante maggiori informazioni dividendolo in campi.

Ovviamente non fornire consigli su quali parole sono sbagliate, anche se l'autenticazione fallisce - ciò comprometterà la sicurezza!

Altri consigli

Ci sono molti altri buoni consigli in altre risposte sull'usabilità.

Se la sicurezza e l'usabilità sono importanti, forse guarda qualcosa di meglio delle password. SMS forse?

È possibile lamentarsi delle password per anni e ancora non affrontare i rischi in modo corretto. Trojan sul computer degli utenti, resettaggio dell'autenticazione tramite account di posta elettronica che vengono violati, phishing ... ci sono cose che nessun problema con schemi di password e controlli di fantasia si rivolgeranno a *.

Se i dati sono importanti, farei qualcosa di meglio di una password.

(A volte puoi stare meglio solo generando una password casuale per l'utente e chiedendo loro di memorizzarlo in modo sicuro in un cassetto bloccato. Dipende da quali minacce e attacchi sei preoccupato e come sarà il sistema utilizzato.)

* C'è molto da dire sull'offerta google basata su due fattori basata sul rischio, in cui l'autenticazione a due fattori viene attivata solo occasionalmente. Controlla i costi e offre un notevole miglioramento della sicurezza. Ma esternerei questo a meno che tu non abbia molto tempo a disposizione:)

Consenti tutte le password. Basta evidenziare le conseguenze.

Il tuo schema è strano e estraneo agli utenti e credo che molte persone preferirebbero smettere di usare il tuo servizio piuttosto che conformarsi. Invece di lasciare che scelgano la propria password, li costringi a ricordare quello che hai scelto per loro. Questo è inaccettabile per molte persone. Pensi di dare loro una scelta "riprova", ma la differenza nell'esperienza utente è circa uguale a quella di ATM rispetto al bandito con un braccio solo.

Ricorda che il più grande problema è il fattore umano. Quello che dovresti evitare, in primo luogo, sono le password scritte su una lavagna. Questi ragazzi hanno avuto un password molto sicura. E poi trasmesso in TV.

Se vuoi assicurarti che nessuno al tuo fianco sia in grado di romperlo, allora ciò di cui hai bisogno sono le procedure interne, non gli utenti di addestramento delle scimmie. Forse un sistema in cui l'accesso alle password salate è protetto dagli stessi limiti di ripetizione del pannello di accesso dell'utente. Inoltre, non è importante rendere impossibile l'accesso ai lavoratori. Gli impiegati nei negozi hanno accesso illimitato ai registratori di cassa. Ciò che impedisce il furto è la consapevolezza di conseguenze inevitabili. Usa la registrazione della sessione di amministrazione. Utilizzare le procedure "minimo 2 persone per accedere". Ecco come fanno le banche, perché le password degli utenti forti non possono proteggere tutto.

Dovresti leggere Diceware . Puoi ottenere 44 bit di entropia con quattro parole da una lista molto più piccola. Se l'elenco è composto da circa 2050 parole e si seleziona senza sostituzione, ciascuna parola sarà di circa 11 bit di entropia perché log ₂ (2048) = 11. Con 5000 parole è possibile ottenere 12 bit per parola. (log ₂ (4096) = 12)

Mi piace l'idea di un link "riprova" che l'utente può fare clic finché non viene presentato con una combinazione che pensa di poter ricordare.

Una cosa della tua domanda mi infastidisce. Se i dati sono crittografati con una particolare password dell'utente, allora solo quell'utente sarà in grado di decodificare i dati. Se i tuoi dati sono archiviati per utente, potrebbe essere OK. Si noti che se un utente dimentica la propria password, i dati vengono brindati se la password è la chiave crittografica. Alla luce di ciò, potresti voler considerare una disposizione di chiave asimmetrica.

Per l'accesso, non separare l'input in quattro campi. Ciò fornisce un'informazione dell'attaccante che l'attaccante non dovrebbe avere. Decidi solo se le parole devono essere separate da spazi o meno e dire ai tuoi utenti.

Il problema che vedo con questo approccio è semplicemente la sua natura non convenzionale, che ridurrà la probabilità che le persone lo usino.

Personalmente, dovrei avere una ragione molto convincente per usare il servizio per sopportare questo, al contrario della tradizionale immissione della password. In passato ho commentato che ritengo che gli sviluppatori di applicazioni abbiano alcuni responsabilità nel cercare di garantire che gli utenti usino password complesse. Però; in definitiva questa è la responsabilità dell'utente.

Considera inoltre che stai costringendo l'utente ad utilizzare un particolare metodo per garantire l'entropia della password. L'approccio XKCD va bene, ma non è l'unico e non c'è un'assoluta evidenza empirica che sia il migliore, né è certo che se è il migliore oggi rimarrà i migliori sei mesi a partire da ora.

Considerare l'uso di gestori di password, che possono generare password molto grandi e completamente casuali e inserirli automaticamente per l'utente. Probabilmente interromperesti queste applicazioni con questo approccio.

Inoltre, considera cose come l'articolo haystacks delle password grc.com, che afferma che questo:

D0g.....................

... è una password più strong di questa:

PrXyc.N(n4k77#L!eVdAfp9

... semplicemente perché c'è un carattere in più, nonostante l'entropia generale (casualità) sia piuttosto bassa, e ci vorrebbe un computer 95 volte più lungo per forzare la forza bruta a indovinare la password che è più facile da ricordare.

Il problema è che gli attacchi di forza bruta sono usati solo fino a una certa lunghezza di password (da 6 a 8 caratteri) a causa della riduttiva spesa computazionale man mano che le password si allungano. Ma anche le password brevi molto complesse sono molto vulnerabili alla forza bruta. Gli attacchi più recenti sono attacchi basati su pattern ibridi che utilizzano password compromesse come modelli all'interno di password più grandi. Le potenti GPU rendono questo approccio praticabile, e apparentemente è molto efficace. Basta riempire una password debole con . 's non sembra essere una buona soluzione.

Vedi anche questo articolo, Password regole di complessità più fastidiose, meno efficaci di quelle lunghe .

Quindi, almeno alcune ricerche recenti indicano che il fattore più rilevante per la sicurezza della password è la lunghezza della password, almeno in parte perché le password con molta complessità sono troppo per la maggior parte degli utenti, anche se sono brevi. L'approccio XKCD aiuta a garantire la lunghezza della password rendendo facile ricordare password molto lunghe, senza che tali password siano semplici motivi o frasi noti. Questo è (probabilmente) la sua forza ultima, solo la lunghezza delle password risultanti. Detto questo, sto iniziando a chiedermi quanto a lungo "corretto il punto di riferimento della batteria del cavallo" resisterà ai nuovi attacchi basati su pattern ibridi.

Poiché ci sono altri approcci per ottenere lo stesso risultato, forzare gli utenti in quello potrebbe rendere più difficile l'utilizzo del servizio senza un compenso adeguato in termini di sicurezza. Inoltre, se fra sei mesi esisterà qualche debolezza nell'approccio XKCD, ci si è collegati con forza e si deve fare uno sforzo notevole per cambiare il servizio.

Sembra un ottimo modo per impedire il riutilizzo della password, anche se, poiché potresti spingere gli utenti fuori dalla loro zona di comfort, potrebbe far sì che salvino la password in un file di testo in modo che possano ricordarla. È necessario sottolineare che l'utente deve ricordare la propria password o utilizzare un gestore di password per archiviarlo in modo sicuro (se questo è qualcosa di accettabile per te e il tuo sistema). Mi assicuro inoltre che la soluzione a più campi funzioni con gestori di password comuni, sebbene non riesca a vedere altri problemi con la suddivisione delle parole in questo modo.

Poiché la funzionalità di gestione delle password con diversi campi designati come password potrebbe essere difficile da implementare, darei anche agli utenti la possibilità di utilizzare le proprie password, tuttavia è necessario specificare che l'utente deve utilizzare solo sequenze casuali generate in modo sicuro, ad esempio come quelli usati nei generatori di password inclusi in Keepass o LastPass. Per evitare che un utente inserisca semplicemente la stessa password che utilizza sempre, è possibile imporre una restrizione sciocca solo nel caso in cui venga immesso dall'utente per assicurarsi che sia effettivamente unico. Per esempio. Minimo di 50 caratteri, utilizzando almeno 20 numeri e deve includere lettere maiuscole / minuscole e almeno un simbolo. Ciò renderà felici gli utenti esperti, evitando al contempo password deboli da parte degli altri (sebbene alcuni utenti possano riempire le proprie password deboli con il 45% di% di% e un% di% di sconto). Puoi provare a rilevare casi come questi e quindi rafforza il messaggio che questa opzione è utilizzabile solo con i generatori di password, tuttavia ci sarebbero minori profitti nel mettere tanto impegno in casi limite: la scelta migliore sarebbe provare e spiegare agli utenti non esperti che l'opzione di parole diverse generate sarebbe più vantaggioso.

I am designing a service that would, among other things, store sensitive information. To ensure that no one on our side of the is able to retrieve this information, it would be encrypted with a key derived from their password (PBKDF2). The password will be stored in a BCrypt hashed + salted format in the database. It is never stored in plain text.

Affinché una crittografia basata su password sia protetta contro gli attacchi offline (ad esempio le persone dalla tua parte o se l'accesso è stato acquisito da un utente malintenzionato in un altro modo), ha bisogno di un'entropia di 128 bit o più, il che significa che occorrerebbero dieci parole casuali per questo anziché quattro o cinque. Anche se, mentre si utilizza PBKDF2 per rafforzare la chiave, questo potrebbe fornire 16 bit di entropia aggiuntiva (a seconda delle iterazioni ), quindi sono necessarie solo nove parole. Il mio obiettivo è assicurarmi di fare i calcoli per garantire che la crittografia sia adeguata.

Ciò renderebbe ancora più difficile per il tuo utente medio ricordare la passphrase, e se usasse un gestore di password potresti anche optare per l'opzione 50 caratteri e lasciarli accedere in quel modo. Come altri hanno sottolineato, sembra che questo potrebbe potenzialmente generare molte richieste di supporto ed è molto impegnativo sviluppare solo una parte di un sistema di autenticazione e gestione delle sessioni sicuro.

Il tuo metodo è interessante, ma penso che non mi piaccia.

1. Permetti agli utenti di "ricoprire il volante" finché non trovano una password che gli piace. Se l'hai fatto con numeri a quattro cifre, temo che alcune persone possano girare ancora e ancora fino a quando non finiscono con 1234 o 0000. Ciò renderebbe felice l'aggressore.

2. Anche se ci sono molte combinazioni, un utente malintenzionato può limitarsi a provare le password solo della struttura prescritta (e in effetti possono usare il tuo stesso servizio per determinare quale elenco di parole usi).

The user would be presented with 4-5 different words from a large word list with more than 6 characters (no words with special characters included, just ASCII). The password input dialog would be formatted with 4-5 fields instead of the normal single field, to reenforce the passphrase paradigm. Upon registration the password can be regenerated at will, to give the user the ability to select a passphrase consisting of words that they can easily remember. The user can not enter their own words.

Questo sarà un problema.

Ciò significa che devi avere un elenco delle parole che vengono utilizzate nella frase password e che non vi è alcuna deviazione da tale elenco.

Se un hacker è in grado di ottenere l'elenco in qualche modo, sia che si tratti di tentativi di forza bruta o social hacking o qualsiasi altro modo, allora hanno l'elenco di parole ed è molto più facile per loro capire la password.

Se invece fai in modo che un utente possa inserire le proprie parole e consentire numeri e / o caratteri speciali, la frase della password sarà molto più sicura e continuerai a impedirgli di utilizzare la stessa password di { ovunque altrove } perché stai ancora forzando 4-5 parole per la frase della password.

Un paio di cose (alcune delle quali sono già state citate)

1. Assicurati che le parole non si ripetano più di una volta
2. Non consentire loro di ripetere una parola più di una volta ( pass , word , pass , word )
3. Non utilizzare la password come chiave per crittografare i dati
   • Questa è una pessima idea, specialmente se l'utente dimentica la propria password e ha bisogno di una reimpostazione della password.
4. Non utilizzare un password scheme
   • Questo lascia indizi di un hacker per eliminare parole e frasi, restringendo il campo.

Prima di provare a implementare qualsiasi politica per le password dovresti davvero vedere questa fantastica presentazione di Rick Redman ad AppSecUSA 2014 intitolata "I tuoi requisiti di complessità della password sono inutili":

link

Parla di cracking delle password usando i modelli simili che tutti gli umani usano per creare password.