Come rendere più forti le password deboli?

L'unico modo per rendere le password più forti è disabilitare le password deboli. Il motivo per cui una password è debole è che un utente malintenzionato può indovinarlo, non a causa del modo in cui lo memorizzi.

Ho trovato link una grande risorsa per gli studi accademici sulle password. Potresti essere interessato a Progettare criteri password per la forza e l'usabilità , che esplora l'efficacia delle politiche sulla creazione di password difficili da indovinare, e quanto sono facili da ricordare.

Se ti iscrivo al servizio e utilizzi la password "password", tutto il tuo processo sta svolgendo un notevole lavoro di hash, salt, rehash, resalt e assalto alla stessa password. Quindi lo memorizzi nel tuo database.

Tutti i dati che si desidera "aggiungere" devono essere memorizzati da qualche parte e, se sono memorizzati, possono essere recuperati.

Non vedo alcun beneficio per la tua proposta rispetto all'esecuzione dei processi standard di hashing e salatura.

Perché alla fine, la mia password è ancora "password" ...

Should this process make passwords more secure / stronger?

No

L'unico modo per rendere più forti le password è aumentare la lunghezza. la complessità aiuta un po ', ma l'entropia delle password aumenta significativamente di più quando si imposta la password più a lungo di quando si richiede "più caratteri" per essere utenti. per esempio: l'aumento di 5 caratteri in più nell'alfabeto aumenta la comlpexity della password con Alphabet + 5 ^ n caratteri. mentre aumentando il numero di caratteri aumenta la complessità con Alphabet ^ n + 5 caratteri. l'ultimo è esponetialmente superiore al primo.

Il problema fondamentale è che il cliente deve solo conoscere la propria password e la sua password può essere debole.

Ciò che proponi non modifica in realtà il fatto che usi PBKDF2 per memorizzare le password o la password di base del cliente.

Penso che il tuo problema potrebbe riguardare la modellazione delle minacce: quali rischi stai attualmente proteggendo (il database delle password viene esposto) e quali rischi aggiuntivi stai cercando ora di evitare?

Non penso che ci sia un strong disaccordo sulle password degli utenti che sono problematiche nel mondo reale, e nel mondo reale ci sono alcuni sistemi abbastanza largamente adottati, che tendono a ricadere nel concetto generale di 2FA.

In questo autunno cose come i token hardware, i generatori di codice TOTP / HOTP (ad esempio Google Authenticator), i codici SMS (che sono TOTP, AFAIK) e x509 (cioè i certificati SSL).

Penso che la soluzione nel tuo caso sia quella di imporre (più strong) i requisiti della password, o di esaminare una seconda password, utilizzando i certificati client, o l'utilizzo di altri mezzi per implementare 2FA in qualche modo.

O entrambi.

Il processo che hai descritto non rende la password "più strong", stai semplicemente rendendo il processo di hashing più complesso in un modo che non rende difficile un aggressore. Dovresti presumere che un utente malintenzionato che ha avuto accesso agli hash delle password abbia anche accesso a tutti gli altri dati nel tuo database, inclusi entrambi i sali (KMS e PBKDF), in questo scenario lo schema di hashing non fornisce alcuna sicurezza aggiuntiva

Le norme sulle password sono l'unico modo per garantire un livello minimo di sicurezza della password. Dato che il fattore più importante per la sicurezza della password è la lunghezza della password, potresti richiedere una lunghezza minima e consiglia di utilizzare solo numeri e / o caratteri speciali se non vuoi limitare così tanto i tuoi utenti

Inoltre, potresti voler fornire qualche tipo di autenticazione a due fattori come Google Authenticator o un token fisico. Ciò non renderà le password più forti ma fornirà un ulteriore livello di sicurezza

A meno che la tua stringa casuale aggiuntiva non sia memorizzata in un HSM , fornirà un piccolo vantaggio aggiuntivo.

Invece, la migliore difesa contro le password facilmente incrinate è una combinazione di tre cose:

1. Hashing delle password con un hash molto lento come bcrypt o scrypt , con fattori di lavoro ad alto costo (un numero elevato di round, ecc.). Questo rallenta attacchi offline ad alta velocità (dizionari, maschere, regole, forza bruta, ecc.)

2. Disabilitazione di password ben note con una lista nera. Ciò riduce ulteriormente l'utilità degli attacchi con dizionario diretto.

3. Supportare gli utenti nella scelta di password lunghe di A) che richiedono una certa lunghezza minima; B) incoraggiare l'uso di passphrase generate casualmente (per password che devono essere ricordate) o stringhe generate casualmente (per password che possono essere memorizzate in un gestore di password); e C) fornire un'interfaccia utente che supporti password lunghe (consentendo l'inserimento di password nel campo password, ecc.)

I metodi tradizionali di miglioramento della sicurezza delle password come le regole di composizione sono deprecati. Richiedere password più lunghe è più efficace dei requisiti di complessità / composizione, come notato nella bozza del NIST 800 -63b. Le piattaforme di cracking devono utilizzare le regole che imitano la psicologia di come le persone creano password memorabili che soddisfano tali requisiti, riducendo l'utilità delle regole di composizione.

Invece, incoraggiare passphrase generate casualmente. Possono essere memorabili, ma resistenti agli attacchi di forza bruta. Presentare chiaramente questa alternativa agli utenti (come in questa politica di Stanford ) può consentire loro di scegliere buone password.

Non possiamo dettare completamente la selezione della password, ma possiamo controllare l'implementazione lato server. Gli hash lenti e le liste nere sono essenziali per questo.