Crittografia asimmetrica come funzione di hashing

3

Posso sostituire l'hashing della password con la seguente strategia:

  • Genera una coppia di chiavi pubblica / privata, memorizza la chiave pubblica come "salt" e distruggi la chiave privata. Forse non potremmo nemmeno generare la chiave privata in primo luogo (basti sapere che esiste matematicamente).
  • Per memorizzare una password: crittografare la password utilizzando la chiave pubblica. Questo è praticamente irreversibile dato che nessuno ha la chiave privata.
  • Per autenticare: crittografare la potenziale password con la stessa chiave pubblica, quindi confrontarla con la password crittografata memorizzata. Ciò presuppone che l'algoritmo crittografico asimmetrico produca sempre lo stesso testo crittografato per un dato testo chiaro. (vale a dire che la crittografia è una funzione)

Ciò fornirebbe i seguenti vantaggi:

  1. La crittografia asimmetrica è solitamente più costosa dell'hash e dovrebbe quindi richiedere un minore allungamento per gli stessi vantaggi.
  2. Maggiore garanzia sulla password inserita: esiste una sola password che può essere accettata. Cioè, nessuna collisione può essere accettata (contrariamente alle funzioni di hashing) in quanto altrimenti la password decifrata non sarebbe unica.

Lo svantaggio principale che vedo è che la lunghezza della password memorizzata è correlata alla lunghezza effettiva della password, dando un indizio sulla forza della password. Questo può essere mitigato introducendo una password "lunga" sulla password, che assicurerà che la password corta abbia un aspetto breve come il sale. La password lunga rimane per lo più inalterata, ma va bene dato che sono lunghi ma potrebbero richiedere spazio nel database.

Ci sono altri svantaggi di questa tecnica?

Immagino che sia già stato studiato ma non ho trovato il nome di tale strategia.

    
posta Nonyme 28.09.2016 - 15:56
fonte

2 risposte

3

TL; DR

  1. Lo svantaggio che menzioni è meno rilevante di quanto pensi.

  2. 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?

  1. La crittografia asimmetrica è meno costosa rispetto a una routine Hash password lente come BCrypt.

  2. I requisiti di spazio su disco sono più elevati.

  3. "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)

    
risposta data 28.09.2016 - 19:00
fonte
1

Non riesco a capire perché pensi che sarebbe meglio che usare una delle funzioni di derivazione della chiave standard:

Il tuo primo argomento non ha senso: durante lo stretching, il tipo di lavoro che stai facendo è importante solo nel senso che vuoi che sia progettato per essere lento su tutti i tipi di hardware (che NON è sicuramente uno dei obiettivi di progettazione di una tipica funzione di crittografia).

Il tuo secondo argomento sarebbe valido solo se stai utilizzando password non salde con una funzione hash debole. Altrimenti, non sarebbe resistente alla pre-immagine.

    
risposta data 28.09.2016 - 16:21
fonte

Leggi altre domande sui tag