Implicazioni sulla sicurezza di memorizzare l'hash della password lungo una chiave AES crittografata

Per essere sicuro di averlo capito - stai salvando:

• la password con hash: in teoria la password non può essere ripristinata, poiché l'hash è a senso unico.

• the salt - solo la metà dell'equazione per la chiave di crittografia, dato che hai bisogno anche della password in chiaro , giusto?

• il tasto AES crittografato

Quindi ... il tasto AES è il vero guadagno, presumibilmente, perché viene utilizzato per la comunicazione o l'archiviazione crittografata.

Quando vuoi che il server usi la chiave, suppongo che il processo sia questo:

• utente dà al sistema la sua password
Il sistema
• verifica la password, l'hashing e va bene.
Il sistema
• accetta la password (non l'hash!) e sale e calcola la chiave di crittografia
Il sistema
• prende la chiave di crittografia e decodifica la chiave AES

Quindi il sistema gestisce la chiave AES in modo appropriato, fa tutto ciò che deve fare e cancella qualsiasi copia della chiave AES dalla memoria in modo che non sia in giro ovunque.

Come è, non vedo un punto debole in questo, ma hai ridotto tutto alla forza della password. Se un utente malintenzionato dovrebbe ottenere il tuo archivio dati, l'unica cosa di cui ha bisogno ma che non ha è la password. Se un utente ha una password facile da indovinare, l'utente malintenzionato riceverà la chiave AES dell'utente.

Penso che se analizzassi questo sistema, non mi preoccuperei troppo di questo - invece, inizierei a indagare su come le password degli utenti vengono comunicate e su come viene gestita la chiave AES dopo che è stata decodificata - quelle sono deboli punti e potrebbe essere più facile da hackerare di un archivio dati di back-end di hash, sali e chiavi crittografate.

Se un utente malintenzionato vuole rompere il sistema, cercherà di indovinare la password. Ciò significa provare le potenziali password fino a quando una "corrispondenza" (che è ciò che viene chiamato un attacco del dizionario ). Corrisponde a cosa? Ci sono due modi in cui un utente malintenzionato può vedere se la password è corretta:

1. verificando l'hash memorizzato;
2. applicando la derivazione della password PKCS # 5 (PBKDF1 o PBKDF2, PKCS # 5 descrive entrambi), quindi decodificando la chiave AES, quindi utilizzando la chiave ottenuta per provare a decrittografare ciò che è crittografato con che chiave, e vedere se il risultato ha un senso.

L'attaccante utilizzerà il modo più semplice per lui. Le funzioni PBKDF * includono alcune funzionalità che rendono più difficili gli attacchi di dizionario, ovvero il sale e un numero configurabile di iterazioni interne. Le iterazioni rendono costoso ogni prova per password. Il sale impedisce all'aggressore di ottimizzare le cose con una grande tabella di hash precalcolati (ad esempio una "tabella arcobaleno"). PBKDF2 è considerato abbastanza buono (sebbene bcrypt sia discutibilmente meglio ). Se l'hash di verifica della password non include le stesse funzionalità, allora hash è un punto debole che verrà utilizzato da un utente malintenzionato.

In parole più brevi, la tua sicurezza sarà quella del più debole dell'hash della verifica della password e la derivazione della chiave PKCS # 5.

Uno schema migliore sarebbe il seguente:

• Dalla password utente, si ottiene una chiave K utilizzando una funzione di derivazione della chiave appropriata, ad es. PBKDF2 o bcrypt. Questo usa un S .
• Cifra il tuo "tasto AES" simmetricamente con K , producendo qualche valore B .
• Memorizzi h (K) , S e B per ogni utente (dove h è sicuro funzione di hash - Suggerisco SHA-256).

Per verificare una password, rieseguire la funzione di derivazione della chiave, utilizzando il salt memorizzato S , e cancellare il risultato per vedere se corrisponde alla h (K) memorizzata . Se si desidera decrittografare B , si utilizza semplicemente il K ricostruito. In questo modo, sei sicuro che la derivazione della chiave utilizzata per la crittografia e l'hash di verifica della password sono ugualmente resistenti agli attacchi del dizionario.

Non penso che tu voglia memorizzare l'hash accanto al tasto AES. Se qualcuno dovesse ottenere l'accesso alla chiave AES, all'hash e al sale crittografati crudi, potrebbe facilmente forzare la password dall'hash solo. Dato il potere di calcolo di oggi bruto che impone tutte le password alfanumeriche di sole 6 lettere impiega 2 secondi utilizzando la GPU di scaffale. Algoritmi come MD5, SHA1 e persino SHA256 possono essere facilmente forzati a forza bruta con una piccola quantità di potenza computazionale di oggi.

link

link

link

link

Quindi diciamo che non hai archiviato la password come un hash accanto ad essa. L'utente malintenzionato potrebbe ancora forzare la chiave crittografata AES, ma se il calcolo utilizzato per calcolare la crittografia è significativamente più alto dell'astinaggio, potrebbe non essere fattibile da tale forza. Gli algoritmi di hash come MD5 e SHA1 sono progettati per la velocità. Quindi, in realtà, l'algoritmo è più elevato nella complessità computazionale di quanto bene questo schema offra protezione.

Tuttavia, entrambi gli algoritmi probabilmente andranno in password < 8 caratteri di lunghezza. Una password 7, mista, tutti i simboli impiegano solo 7 ore su una GPU per determinati algoritmi. Non è tanto lungo aspettare se queste informazioni sono abbastanza importanti.

La salatura in BTW non aiuta perché è archiviata in chiaro, quindi devi presumere che il tuo aggressore possa saperlo. L'unica cosa che salatura è prevenire gli attacchi da tavolo arcobaleno che sono in qualche modo inutili ora che possiamo solo forzarli brutalmente.