Le password comuni sono particolarmente a rischio?

Alcuni specialisti di UX dicono che non è una buona idea rifiutare una password. Uno degli argomenti è quello che tu fornisci: "ma se li metti al bando, gli utenti useranno altre password deboli", o aggiungeranno caratteri casuali come 1234 - > 12340, che è stupido, privo di senso e quindi costringerà l'utente a passare attraverso il processo "lost my password" perché non riesce a ricordare quali caratteri ha aggiunto.

Hai due opzioni. Mi piacciono entrambi (spiego perché in ciascuno):

1. Lascia che l'utente inserisca la password che desidera. Questo va contro la tua domanda, ma come ho detto, se costringi il tuo utente a inserire un'altra password rispetto a una delle 25 peggiori password conosciute, ciò si tradurrà in 1: Una brutta esperienza utente, 2: Una password probabilmente persa e l'intera " perso la mia password "flusso di lavoro. Ora, ciò che puoi fare è indicare al tuo utente che questa password è debole , o anche aggiungere ulteriori dettagli dicendo che è una delle peggiori password conosciute (con un link a loro), che non dovrebbero utilizzarlo, ecc. Se specifichi questo, inclini i tuoi utenti a modificare la loro password in una più complessa perché ora loro conoscere il rischio . Per quello che userà 1234, facciamolo perché forse c'è una semplice ragione: spesso metto una password stupida in qualche sito che richiede il mio login / passaggio solo per vedere cosa mi offre questo sito.

2. Aggiungi alcune regole, come "Almeno un numero e un carattere speciale, deve essere lungo almeno 8", ecc. Ciò andrà contro la peggiore password. D'altra parte, se l'utente ha una password abbastanza complessa che non corrisponde a una delle tue regole, si verificherà una UX errata.

Infine, devi scegliere tra una buona esperienza eXperience o una sicurezza migliorata. Ora dipende molto dal tipo di progetto che stai costruendo: se si tratta di un sito Web di base per caricare foto di cuccioli, forse non è necessario impostare un sistema di sicurezza complesso. Ma se sei il prossimo paypal, dovresti.

Riguardo alla tua domanda sulla forza bruta, dipende da come si imposta la memorizzazione della password. Se aggiungi sale e pepe, è possibile eseguire la forza bruta sul database. Se aggiungi un captcha nella pagina di accesso o aumenti il tempo tra tentativi ed errori, la forza bruta non sarà possibile.

È possibile che l'attaccante usi prima la password peggiore, ma non sono sicuro che sarebbe abbastanza efficiente. Anche se sceglie il primo 3 (riguardo le tue regole su captcha e 1-3 ipotesi), questo ridurrà notevolmente la probabilità di hacking in un account.

Quello che ti manca qui è che la maggior parte degli attacchi con password, in cui la complessità è un problema (ad es. attacchi che non coinvolgono l'ingegneria sociale), si verificano offline . Ciò significa che l'autore dell'attacco ha già una propria copia del database delle password ed è in grado di eseguire analisi sul proprio sistema liberamente senza preoccuparsi del sistema di destinazione che le blocca. I CAPTCHA e le politiche di blocco degli account sono inefficaci contro questi attacchi.

Gli attacchi di dizionario sono molto più veloci degli attacchi a forza bruta. Quindi, sì, è realistico presumere che gli aggressori indirizzeranno le password "comuni" prima di ricorrere alla forza bruta. John The Ripper, forse uno dei più noti strumenti di cracking delle password offline, lo utilizza addirittura come azione predefinita. Quindi, se la tua password è "password" o "12345678", è molto probabile che si rompa in meno di un minuto. Una password generata a caso (o, almeno, non così comune) di uguale lunghezza potrebbe richiedere molto tempo.

Dipende dalle esigenze della tua applicazione e non è una taglia adatta a tutti. Se lo scenario di compromesso peggiore riguarda solo l'utente finale ed è un piccolo inconveniente per loro (e nessun inconveniente per te), un semplice avvertimento educativo (questa password è molto debole) e che consente loro di creare la password debole è probabilmente sufficiente.

Se la tua applicazione deve essere protetta come se fossi una banca, o sei un commerciante online che salva i dettagli della carta di credito del cliente ¹ (e gli addebiti sulla carta di credito sono equivalenti al furto + commissioni bancarie extra ), o l'account ha i privilegi di amministratore, o ..., dovresti fare del tuo meglio per impedire agli account di avere password deboli e certamente non consentire alcuna password popolare. Creerei un database ordinato di milioni + la maggior parte delle password popolari prese da qualche fonte online (compreso anche un dizionario inglese standard), e controlliamo le password contro questo oltre a controllare che superi alcuni altri criteri minimi; ad es., devono avere più di 16 caratteri O essere più di 8 caratteri con un numero superiore + inferiore +.

Le password molto deboli (top 1000) possono essere attaccate casualmente online da botnet (anche se si utilizzano captcha / ritardi dopo così tanti tentativi errati). Gli attacchi di dizionario sono molto veloci offline se il tuo database hash è stato compromesso in qualche modo.

¹ Nota: una soluzione migliore potrebbe essere quella di non salvare i dati della carta di credito o almeno di richiederne la ridistribuzione nei dettagli ogni volta che tentano di utilizzare un nuovo indirizzo IP.

Sono certo che gli attaccanti useranno password comuni prima di iniziare un tentativo di forza bruta. Anche se i dispositivi CAPTCHA (e altri detective / preventivi) sono installati, l'elenco delle password comuni è molto più piccolo delle parole in un dizionario.

Prenderò una posizione diversa e suggerisco che abbia senso non consentire password comuni nella maggior parte dei casi d'uso. La forza di una password è legata alla difficoltà per l'avversario di ottenere l'accesso non autorizzato. Le qualità che la comunità attualmente accetta come password strong si basano sulla difficoltà per un avversario di ottenere l'accesso tramite forzatura bruta, cracking o altri metodi (es. Frasi passate e dispositivi mnemonici aumentano la difficoltà per un passante da memorizzare). XKCD rappresenta questo abbastanza accuratamente in questo fumetto . L'uso di diversi casi, simboli ecc. Aumenta la casualità della password in modo che l'attacco impieghi più tempo per l'esecuzione corretta e aumenti anche la probabilità che vengano rilevati i tentativi.

Guardando più da vicino i metodi di attacco, la top 25 password, insieme a molte altre, sono comunemente popolate nei dizionari. Di solito gli aggressori si attaccano alle password comuni e spesso tentano di esaminare prima la short list. È simile alla pratica comune che molti fornitori spediscono dispositivi con password ben note (ad esempio cisco / cisco, admin / admin) e non impongono la modifica delle credenziali predefinite note. Dal punto di vista del payoff, in genere vale la pena provare prima le password comuni. L'unico motivo per cui un utente malintenzionato potrebbe non adottare questo approccio è quando l'attacco è mirato. In tal caso, l'attaccante può esercitare più cautela perché non vuole lanciare bandiere rosse.

Facendo un passo indietro, uso liberamente il termine "attaccante". L'attaccante può significare un bot (o script automatico), uno script kiddie (un o meno abile) o un individuo esperto. Molte argomentazioni sulla sicurezza confondono il terreno tra la protezione contro l'attaccante auto / non qualificato e abile. Sebbene le tecniche utilizzate per rilevare e prevenire gli aggressori auto / non qualificati in genere seguano il buonsenso, l'esperto malintenzionato sarà probabilmente a conoscenza delle tradizionali strategie di rilevamento / prevenzione e adatterà di conseguenza i propri tentativi. Supponiamo che mi riferisca all'autore automatico / non qualificato a meno che non si qualifichi il livello di abilità.

Seguendo il tentativo di utilizzare password comuni, è più difficile lanciare ulteriori metodi di attacco online come la forza bruta se ci sono sistemi di prevenzione o rilevamento appropriati (ad esempio, registri di accesso / registri di controllo, rilevamento forza bruta). In alternativa, i metodi di attacco off-line richiedono l'accesso a un file di password protetto - se un utente malintenzionato può accedere alle informazioni sulle credenziali (sia esso sottoposto a hash, crittografato o protetto in altro modo). I tester penna (whitehats) spesso seguono il flusso di lavoro dell'utilizzo di account noti per ottenere l'accesso iniziale a un sistema per ottenere un accesso più approfondito alle reti. Indipendentemente da ciò, se un utente malintenzionato ha accesso offline a un negozio di credenziali, ci sono problemi più grandi delle semplici password.

La pratica della sicurezza comporta davvero un compromesso con l'accessibilità. Il sistema meno accessibile è generalmente più sicuro di uno più accessibile. La persona UX / UI pubblicherà storie per rendere la vita molto più facile (sistema più accessibile). La persona di sicurezza dovrà inserire un sistema meno accessibile. Entrambi alla fine dovranno accontentarsi di una posizione accettabile dalla BU / sponsor. Combina il punto precedente con la tendenza per la maggior parte delle persone a dare la colpa (o forse la mancanza di volontà ad accettare la colpa) e il principio che la ruota più squallida viene oliata per prima. Se l'utente è libero di scegliere una password e un utente malintenzionato ottiene l'accesso non autorizzato e provoca il caos, la prima risposta "vittima" sarà "come è successo?" Le dita iniziano a puntare dappertutto e spesso finiscono nella persona responsabile della sicurezza con la domanda, "perché mi hai lasciato scegliere questa password?" Non sto affermando che questo è comune, ma il responsabile della sicurezza è in definitiva responsabile del perseguimento di politiche volte a proteggere gli utenti (e il marchio / datore di lavoro). Il mio punto qui è che a volte non è una buona pratica permettere agli utenti di fare la propria scelta sulle password.

Inoltre, l'accesso al valore dipende dal valore delle informazioni fornite e dall'identità dell'utente.

Is it realistic to assume attacks will focus on common passwords before brute force?

Nella mia esperienza è stato il caso. Anche se provare le password comuni è solo un diverso tipo di "forza bruta".

La vera domanda di base è questa: gli aggressori tenteranno un attacco esaustivo contro un singolo account, o tenteranno un attacco molto superficiale contro tutti i conti.

La risposta a ciò dipende da ciò che l'hacker desidera. Se vuole accedere a un account specifico (ad esempio una celebrità), allora continuerà a battere all'infinito su quel conto da solo; è l'unico di valore per lui. Ma se l'hacker vuole solo l'accesso a qualsiasi account, oa il maggior numero possibile , allora è molto più ragionevole per lui provare solo le password più comuni su TUTTO il conti.

Nella mia esperienza con l'esame del codice di attacco trovato "in the wild" e attualmente in uso, l'ordine della password è questo:

1. Prova prima le password più comuni. Di solito c'è un elenco di tra 10 e 500 password per provare
2. Prova le password del dizionario secondo. Questo spesso include variazioni come la sostituzione di "4" dove una "A" sarebbe o un "1" dove c'era la lettera "l", così come l'aggiunta di numeri alla fine.
3. Estrai lo spazio della password, iniziando da "a", "b", "c" ... "aa", "ab", "ac" ... ecc.

Il passaggio 3 viene in genere omesso e il passaggio 1 viene in genere tentato su un intervallo di nomi utente prima di passare al passaggio 2.

Naturalmente, ma non dovrebbe essere la domanda. La vera domanda è: cosa puoi fare a riguardo?

Non molto. Puoi costringere gli utenti a usare password più complesse che possono farle scriverle, allontanarle dal servizio o renderle pazze (ho una password molto complessa con un carattere speciale che alcuni validatori di password semplicemente non accettano).

La radice del problema è che le password fanno schifo, in modo semplice e semplice. Sono una soluzione semplice per un problema complesso ("Chi sei?") E, come Einstein già sapeva 80 anni fa, ci sono soluzioni che sono troppo semplici. Quello che gli utenti vogliono è che il loro PC li identifichi "in qualche modo" e che gestisca la loro identità per loro. Quindi se puoi, non usare affatto le password.

Preferisci soluzioni single-sign-on come OpenID , BrowserID o servizi simili. Ciò consente all'utente di ricordare una password eccellente anziché una schifosa per ogni sito o, peggio, la stessa password per ogni sito.

Un utente malintenzionato esegue le prime 5000 password comuni e la bruta forza la password. Quello che puoi fare è rendere la password lunga almeno 9 caratteri, con lettere maiuscole, minuscole e caratteri speciali.

Se stai sviluppando un sistema puoi filtrare i dati quando crei un account. Dovresti usare la lingua lato server e non quella lato client per quello.

Se sei un amministratore di sistema Microsoft, ciò che puoi fare è creare un criterio di gruppo e applicarlo alle restrizioni menzionate e puoi avere anche altre opzioni come la lunghezza della password, il criterio di blocco dell'account e molto altro.

controlla le espressioni regolari.