Accettare altre password simili quando si memorizza una password con hash salata

If someone were to get a hold of this database and try cracking the passwords, would allowing these additional combinations significantly reduce password strength?

Direi che non sarebbe in questa specifica situazione. Dubito strongmente che stiano memorizzando tre forme della password hash nel database, ma piuttosto eseguono tre diverse versioni della password fornita e la confrontano con la password con hash presente nel database.

C'è un post interessante qui che spiega come Facebook ha questa funzionalità di password. e mentre non va esattamente nello sfondo di ciò che sta accadendo, sembra che il consenso non sia un rischio significativo per la sicurezza.

La risposta a questa domanda dipende da due fattori:

1. il vettore di attacco
2. l'implementazione di consentire password diverse

I siti Web devono memorizzare le password non in testo normale o in qualsiasi altro modulo che consenta di ottenere la password dal valore salvato. Di conseguenza, in genere viene utilizzata una funzione hash irreversibile, in modo che vengano confrontati solo gli hash delle password.

Ora ci sono principalmente due metodi per consentire password simili:

1) (Il cattivo, non dovrebbe essere usato, solo per completezza) Si potrebbero memorizzare molti diversi hash della password dell'utente nel database. Esempio: l'utente inserisce 'abc123' come password e salvato sono gli hash di

abc123
Abc123
ABc123
abc!"§

e così via. Ora al login si hash la password data e si guarda se corrisponde a qualsiasi password dell'utente.

2) Viene salvato solo l'hash della password reale e al momento dell'accesso viene modificata la password specificata (se quella originale non corrisponde) e i sali risultanti vengono confrontati con quello nel database.

Ora per diversi vettori di attacco :

Se qualcuno ottiene il database descritto nel metodo 1, la sicurezza è un po 'più debole del normale, perché ci sono molti hash diversi per l'utente e le probabilità sono più alte di quello che si può trovare. Con il database del metodo 2, c'è solo un hash e l'ortografia esatta deve essere trovata.

In generale, hai più entropia nello spazio del tuo personaggio con il secondo metodo, perché fai la differenza tra lettere maiuscole e minuscole.

Per un utente malintenzionato che detiene il database (purché sia reso ragionevole) non vi è alcun deficit di sicurezza con questo approccio.

Ma nel caso di un attacco a forza bruta sul sito web c'è sempre una possibilità più alta per l'attaccante di accedere correttamente all'account degli utenti. Pertanto devono essere intraprese ulteriori azioni per prevenire questo tipo di attacco!

La semplice risposta non è davvero. Il modo più semplice per ottenere ciò sarebbe utilizzare un .ToLower () prima di salare e fare l'hashing, e lo stesso quando si verifica la password.

Tuttavia vale la pena dedicare un po 'di tempo a riflettere sul motivo per cui dovresti preoccuparti. Dopotutto non è il browser che fa la maiuscola, è l'utente. Non è diverso dall'usare @ invece di A o 3 invece di e.

In linea di principio dovresti accettare qualsiasi cosa l'utente inserisca come password senza fare scherzi.

Inoltre, la ricerca sembra indicare che la lunghezza della password e non la complessità è il modo migliore per andare Misurare l'effetto dei criteri di composizione della password .