TL; DR
-
Lo svantaggio che menzioni è meno rilevante di quanto pensi.
-
Lo svantaggio più grande di Asymmetric Encryption è che è un po 'più economico di un hash Slow Password correttamente configurato.
Quindi, dovresti usare un hash di password lenta. (cioè BCrypt)
In teoria, l'utilizzo di una routine di crittografia asimmetrica (in cui la chiave privata viene definitivamente dimenticata) è una funzione hash ragionevolmente sicura, ma non è adatta ai dati di input a bassa entropia (cioè le password)
Asymmetric cryptography is usually more expensive than hashing and should therefore require less stretching for the same benefits.
Vedo che capisci l'importanza di una costosa routine di hash per prevenire Brute Force. Sebbene Crittografia asimmetrica sia più lento delle funzioni Hash generale (es. SHA-2), ciò che dovresti utilizzare è una funzione Hash lento (es. BCrypt) che è più costoso di una delle due opzioni di cui sopra.
Stronger guarantee on the entered password: there is one and only one password which can be accepted. That is, no collision can be
accepted (contrary to hashing functions) as else the decrypted
password would not be unique.
Le moderne funzioni di hash hanno uno spazio dei nomi abbastanza grande che è improbabile che si verifichi collisione nel corso della vita dell'applicazione. Cercare di trovare qualcosa di ancor più resistente alla collisione è inutile.
The main disadvantage I see is that the stored password length is
correlated to actual password length, giving a clue on password
strength. This can be mitigated by introducing a "lengthy" salt to the
password, which will ensure that short password only look as short as
the salt. Long password remain mostly unaffected but that is fine as
they are long but might take space in the database.
L'utente malintenzionato sarebbe in grado di vedere quanti blocchi lungo può contenere la password crittografata, ma non sarebbe in grado di dirlo in modo più specifico. La stragrande maggioranza delle password può essere memorizzata in un singolo blocco (assumendo una dimensione di chiave strong come RSA 1024 o RSA 2048), quindi questo indizio potrebbe essere di uso limitato per un utente malintenzionato.
Are there any other disadvantages to this technique?
-
La crittografia asimmetrica è meno costosa rispetto a una routine Hash password lente come BCrypt.
-
I requisiti di spazio su disco sono più elevati.
-
"Non eseguire il rollover."
Eccoti, dovresti utilizzare un hash di password lente come
- BCrypt, ma assicurati di eseguire un rapido hash SHA-2 sui dati di input, in modo che le password super-lunghe non vengano troncate da BCrypt
- PBKDF2 ma che è meno resistente alla GPU
- SCrypt è migliore di BCrypt se hai un fattore di lavoro abbastanza alto. Altrimenti è peggio contro le GPU.
- Il vincitore del Concorso di hashing password potrebbe essere persino migliore di quanto sopra, ma non ha ancora superato la prova del tempo, quindi non usarlo ancora. Si chiama Argon2 e ha impostazioni del fattore di lavoro separate per il tempo della CPU e il carico della memoria. (Bello!)
La maggior parte di queste opzioni genera Salt casuale per impostazione predefinita, ma verifica se questo è il caso!
È meglio includere un po 'di pepe (~ 72 bit di entropia) prima della password prima dell'hashing. Il Pepper può essere uguale per tutti gli utenti, ma deve essere memorizzato in un file al di fuori del database, in modo che il componente non possa essere trovato tramite SQL Injection.
Assicurati che il tuo fattore di lavoro richieda circa 100 ms (con protezione DoS appropriata) sull'hardware di destinazione (sapendo che gli hacker useranno hardware più veloce per la forza bruta)