Come neutralizzare in modo sicuro gli utenti dall'aggiunta di una singola cifra alla loro vecchia password al momento della creazione di una nuova? [duplicare]

Non puoi. I tuoi utenti stanno facendo questo perché il meccanismo di reset è diventato invadente per loro ottenere il lavoro svolto. Le persone sono abbastanza intelligenti da aggirare tutti i meccanismi che stai per escogitare. Quelli che non lo sono impareranno presto da quelli che sono. Informazioni come questa viaggiano velocemente.

Se in qualche modo dovessi capire come contrastare lo schema password1 password2 password3 che le persone usano comunemente, ti troverai quasi immediatamente ad affrontare un nuovo schema. 1password 2password 3password. Ora vedi un NUOVO pattern e semplicemente itera tutti i numeri. Quindi l'utente presenta uno schema ancora migliore. passwordA passwordB passwordC. Passerai settimane a inventare una contromisura, per poi essere sconfitto in 10 minuti da una persona intelligente che ha pensato a qualcosa che non hai.

Il punto è che la capacità degli utenti e il costo per superare le tue contromisure superano di gran lunga la tua capacità di sviluppare continuamente nuovi schemi per cercare di prevenirli.

La soluzione è semplicemente smettere di vedere i tuoi utenti come avversari che stai cercando di sconfiggere. Non lo sono. Gli utenti stanno semplicemente cercando di fare le cose, e tu hai sollevato una barriera per farlo. Se questo ti infastidisce così tanto, devi adeguare il tuo atteggiamento nei confronti degli utenti e lavorare con loro per trovare qualcosa che si adatta alle tue esigenze e non crea una relazione contraddittoria.

Abbastanza facile: hai una password futura di "password1". Prova "password" e "password0" per vedere se funzionano con il vecchio hash. Non è necessario vedere il testo in chiaro della vecchia password per farlo funzionare.

Tuttavia, questo non funzionerà per i motivi esposti da Steve Sether.

Questo è stato discusso in vari punti e la maggior parte delle discussioni sembra tornare al concetto di topologie password - i modelli che hanno molte password. C'è una buona presentazione OWASP su YouTube, che suggerisce che molte password che devono seguire le regole di complessità seguono simili modelli:

• Password1! - Se imponi almeno un carattere per ciascuna delle lettere maiuscole, lettere minuscole, cifre e caratteri speciali, molte persone sceglieranno una parola in maiuscolo, seguita da un numero, con il carattere speciale alla fine, che sarà spesso ? , ! o . - la topologia è UL+DS (usando una sorta di sintassi di stile regex)
• Password1 - se non imposti un carattere speciale, di solito non ne ottieni uno
• password1 - se non invii una lettera maiuscola, di solito non ne ottieni una, ma se lo fai, sarà all'inizio
• qwertyuiop : se non imponi nulla, ottieni cose facili da digitare

C'è anche qualche controversia sul valore di cambiare regolarmente le password, perché tendono a incoraggiare esattamente il comportamento che stai vedendo. Tuttavia, a volte sono richiesti a causa del ritmo relativamente lento delle scelte commerciali.

Ciò dà origine al suggerimento di applicare non solo una modifica della password, ma una modifica della topologia della password. Il processo di reimpostazione della password diventa:

1. L'utente inserisce la vecchia password (ad esempio Password1! ) e la nuova password ( MyS3cret$ ) in forma di ripristino
2. Il sistema calcola la topologia sia della vecchia password ( UL+DS ) sia della nuova password ( ULUDL+S )
3. Il sistema rifiuta la modifica della password se le topologie corrispondono o se la nuova password non corrisponde alle regole di complessità

È anche possibile rifiutare completamente alcune topologie comuni - forse non si desidera alcuna password del formato Password1! , nel qual caso si configura il sistema per rifiutare qualsiasi password che abbia la topologia UL+DS .

Non memorizzare mai la topologia di una password: se il tuo database dovesse essere compromesso, avresti dato agli aggressori un modo fantastico per minimizzare il loro sforzo di decifrare le password recuperate.

Ricorda che gli utenti troveranno ancora modi per rendere deboli le password: potrebbero iniziare alternando Password1! e !2Password , ma ciò suggerisce che la frequenza della modifica della password è troppo alta.

È semplice prevenire il problema specifico dell'aggiornamento di nuove password da parte degli utenti che sono troppo simili alle password precedentemente utilizzate (ad esempio, solo una singola cifra / carattere cambia).

Sulla stessa schermata di modifica della password, è sufficiente che l'utente inserisca la sua vecchia password e la nuova password richiesta. È comunque buona pratica richiedere agli utenti di inserire la password esistente nelle schermate di modifica della password (questo impedisce a qualcuno che ha temporaneamente lasciato l'account incustodito, con un utente malintenzionato cambiare la propria password e concedersi l'accesso in futuro bloccando l'utente reale ).

Accetta solo la nuova password se puoi verificare sul lato server che tutte le seguenti condizioni sono vere:

1. L'hash della vecchia password corrisponde all'hash memorizzato nel database.
2. La nuova password soddisfa i tuoi requisiti di forza (una passphrase lunga potenzialmente potenzialmente un solo tipo di carattere o con caratteri speciali, lettere maiuscole, numeri e almeno 8 caratteri),
3. Le vecchie e le nuove password (che hai appena ricevuto in testo semplice senza salvare nel tuo database in chiaro) hanno una discreta modifica distanza (ad esempio maggiore di 4). Se non ha abbastanza distanza, invia un feedback all'utente che la password è troppo simile a una password precedente e dovrebbe essere completamente diversa.
4. La nuova password non corrisponde a nessun hash scaduto precedentemente utilizzato. (Non consentire il riutilizzo della password di una password precedente).

Nota che questo non impedisce a un utente determinato di fare

<password>1 - > <other password>1 - > <password>2 - > <other password>2 .

Se davvero volevi evitare questo tipo di schema, potresti farlo per alcuni schemi molto specifici. Ogni volta che viene salvata una password, è possibile eseguire alcune modifiche comuni della password corrente e salvarle nel database come hash scaduti precedentemente utilizzati. Ciò potrebbe impedire alcuni schemi comuni (ad es. La cifra finale), ma gli utenti troveranno dei modi per aggirarli (ad es. Incrementare un carattere nel mezzo della password).

Questo è un po 'complicato. È facile far rispettare la complessità perché la complessità è relativamente facile da descrivere, ma in molti casi una password complessa non è buona. Ad esempio se la tua politica costringe a un min. lunghezza di 10 caratteri, un carattere speciale, un numero e casi maiuscoli e minuscoli molte persone lo faranno:

David1989$

Qual è il primo Nome, l'anno di nascita e un carattere speciale selezionato a caso. Questo corrisponde alla politica, ma ogni hacker con una conoscenza di base sulla persona è in grado di rompere tale password in meno di un secondo utilizzando uno script che genera tali password da dati personali. In realtà qualche tempo fa ho scritto una sceneggiatura che raccoglieva tali informazioni dal sito web di un cliente e profili correlati di Facebook per generare tali password. Ha funzionato abbastanza bene.

Questo è il motivo per cui ho chiesto qualche tempo questa domanda fa. Dal momento che questa esperienza esprimo frequentemente le password di tutti gli utenti dal server AD ed eseguo attacchi di liste vocali su di esse con elenchi di parole e elenchi di parole pubblici che vengono raccolti da siti Web che sono tecnicamente correlati alla società. Utenti con password errate che devono reimpostare la propria password e sono costretti a utilizzare una password generata in modo casuale dopo la seconda volta che l'hash della password è interrotto.

Questo in realtà può essere fatto, almeno nella maggior parte dei casi (ovviamente, ciò non significa necessariamente che sia un'idea buona !):

Hai ragione che è effettivamente impossibile recuperare la password precedente dell'utente dall'hash della password memorizzata.

Ma non bisogno di: come parte del processo di modifica della password, è normale chiedere la vecchia password dell'utente e controllarla. Questo ti permette di confrontare le vecchie e le nuove password per similarità.

Ovviamente è facile controllare l'aggiunta / l'incremento di una singola cifra alla fine della password, ma ciò consente troppe semplici variazioni che sarebbero ugualmente ovvie per un utente malintenzionato. Molto meglio sarebbe calcolare la modifica della distanza tra le due password (ci sono noti algoritmi efficaci per farlo), e rifiuta se la distanza è bassa (ad esempio, < = 2) - questo garantirà che il solo cambio di alcuni caratteri (ovunque siano nella password) sarà sempre rifiutato.

Ovviamente, le persone troveranno ancora dei modi per riutilizzare le password con piccole modifiche, ma se un utente malintenzionato recupera una o due password storiche, sarà molto meno ovvio quale sia il modello e quindi quale password provare ora.

Una situazione in cui ciò non funziona è se l'utente ha dimenticato la propria password (lo scenario "reimpostazione della password"). Nel caso reale in cui la password è stata veramente dimenticata, questo non è un problema poiché la nuova password è improbabile che sia una semplice modifica di quella che l'utente non ricorda! Esiste tuttavia il rischio reale che gli utenti inizino a utilizzare "reimpostazione della password" come soluzione alternativa che consente loro di modificare la password in modo simile a ciò che è accaduto prima. (Se questa è una grande preoccupazione, la soluzione suggerita in altre domande - di generare tutte le password entro una determinata distanza di modifica della nuova password e di controllarle con l'hash della vecchia password - può essere usata, questo è sicuramente pratico per e modificare la distanza di uno, e possibilmente di due, ma oltre a ciò inizia a diventare una grande quantità di calcoli e probabilmente non fattibile.)

Una delle maggiori preoccupazioni per la sicurezza in questo è il fatto che stai memorizzando le password in chiaro se riesci a distinguere tra le differenze di un singolo carattere.

In primo luogo, dovresti cercare di archiviare queste password come un hash unidirezionale, semplicemente perché l'archiviazione delle password potrebbe potenzialmente essere vulnerabile agli attacchi. Successivamente, è possibile implementare un meccanismo per garantire che nessuna delle nuove password possa mai portare a uno di questi hash. Ciò significherebbe anche che non puoi dire se aggiungono un carattere o 100 caratteri dopo la loro password corrente, sfortunatamente. Dopotutto, come dicono i post precedenti, ci sono sempre modi per aggirare, e non è che stiano cercando di essere maliziosi, vogliono solo fare il loro lavoro.

Il modo migliore per implementare questo è educare i tuoi utenti tramite una sorta di piattaforma di comunicazione, sia vocalmente, o via e-mail o bacheche elettroniche, ecc. e anche indirizzarli verso potenziali problemi. Dopotutto, le persone hanno meno probabilità di trovare il modo di aggirarle se sanno che sono quelle che beneficiano maggiormente del sistema rispetto al fastidio causato da questo.