Mi chiedevo se fosse possibile conoscere la chiave se già conosci il valore originale e il risultato dell'hash.
Ad esempio, supponiamo:
'$value' = helloworld
'$hmac_key' = 0123456789
'$result' = 6adfb183a4a2c94a2f92dab5ade762a47889a5a1
Con solo $value e $result , è possibile recuperare $hmac_key ?
In semplice matematica di base, è abbastanza ovvio, ma con HmacSHA1, è anche possibile?
Non è possibile ottenere la chiave con queste informazioni. Altrimenti, avresti un problema di sicurezza piuttosto serio. Molti algoritmi di crittografia (e hashing) "full-strength" hanno il vantaggio che conoscere le coppie input-output non avvicini gli hacker alla scoperta della chiave. Questo è talvolta chiamato "key wear", in base al fatto che la tua chiave viene consumata con l'uso e diventa meno sicura.
Non è possibile recuperare la chiave ... supponendo che la chiave abbia sufficiente entropia.
Ecco cosa può fare l'attaccante. Se l'attaccante ha un'ipotesi sulla chiave, l'attaccante può controllare se la sua ipotesi è corretta. Ciò significa che se l'attaccante può restringere l'elenco delle possibilità per la chiave in una lista abbastanza breve, l'attaccante può semplicemente provare tutte le possibilità in quella lista e vedere quale è corretta, e l'attaccante alla fine scoprirà il valore corretto della chiave. Questa strategia di attacco è nota come ricerca forza bruta o ricerca chiavi completa. Si scopre che questo è essenzialmente l'unico attacco che un attaccante può fare; con SHA1-HMAC, un attaccante non può fare meglio di questa strategia di attacco.
Quindi, il tuo compito come difensore è di assicurarti che il numero di possibilità per la chiave sia abbastanza grande da impedire la ricerca di forza bruta. Idealmente, ci sarebbero almeno 2 128 possibilità per la chiave, tutte ugualmente probabili. Ad esempio, potresti generare la chiave leggendo 128 bit da /dev/urandom . Se è così che selezioni la chiave, non ci sarà modo per un utente malintenzionato di recuperare la chiave.
D'altra parte, se si fa un pessimo lavoro come difensore della scelta della chiave, allora potrebbe essere possibile per un utente malintenzionato recuperare la chiave. Ad esempio, supponiamo che tu decida che la tua chiave sarà un numero casuale a 4 cifre. Bene, quindi ci sono solo 10.000 possibilità per la chiave, quindi un utente malintenzionato può provarle tutte e identificare quale è corretta. Il processo di prova ed errore richiederà solo millisecondi, quindi se è così che hai scelto la tua chiave, le cose sarebbero del tutto insicuri e l'emittente sarebbe in grado di recuperare la chiave. Se si seleziona un numero casuale di 10 cifre come chiave, allora ci sono 10 valori 10 possibili della chiave, che non è ancora sufficiente: un utente malintenzionato potrebbe provare tutti questi valori possibili in poche ore. Quindi, non farlo. Oppure, se si utilizza il numero di telefono di qualcuno o SSN come chiave, sarà nuovamente possibile per un utente malintenzionato recuperare la chiave (semplicemente provando tutte le possibilità). Quindi, non farlo neanche.
In breve: scegli la tua chiave usando 128 bit di casualità con cripto-forza. Quindi, non sarà possibile per un utente malintenzionato recuperare la chiave.
In generale, si tenta di mantenere sicuro originale e il salt è memorizzato in un modo meno sicuro, in generale all'interno di alcune tabelle del database insieme al nome utente, o qualcosa di simile. Stai chiedendo il contrario di ciò che accade generalmente.
Quindi, supponendo che salt sia memorizzato da qualche parte, e nessuno abbia accesso ad esso, è "difficile da trovare" poiché l' originale sarebbe nel solito modo.
Quando le persone dicono di "usare un sale per evitare tabelle precalcolate", il sale ha due scopi: rendere la password "più grande", in modo che non sia in un pre coperto -computade range della tabella, e impedendo che due utenti con la stessa password finiscano con lo stesso hash.
Se hai un pezzo di esso secrect (il pezzo originale ) e un altro che potrebbe essere rivelato (il pezzo salt ), farai l'attaccante vai con la forza bruta, dato che il pezzo conosciuto ( salt ) verrà aggiunto ad ogni tentativo.
Cosa succede quando dividi il pezzo originale e tieni il salt molto segreto è che stai semplicemente invertendo i nomi: originale è quello conosciuto e il salt è quello segreto. Quindi, tutte le osservazioni sulla durezza di trovare originale quando sai che salt si applica ancora.
Un buon codice di autenticazione dei messaggi deve essere resistente a falsificazioni : immagina che il male Guy ha accesso a una scatola che calcola HMAC / SHA-1 rispetto agli input che sceglie e fornisce; internamente , la casella utilizza una chiave segreta. L'obiettivo dell'attaccante è quello di costruire una coppia (m, h) dove h è un MAC corretto per il messaggio m , senza usando m come input per la scatola. Se preferisci, l'utente malintenzionato invia N input alla casella e prova a terminare con N + 1 valori MAC validi. Il recupero delle chiavi sarebbe ancora peggiore (se l'utente malintenzionato recupera la chiave, allora può produrre tutte le coppie (m, h) che desidera).
Se l'output MAC ha lunghezza n bit, e l'attacker può riuscire inviando meno di 2 n-1 query alla casella e spendendo meno di 2 n-1 valore di invocazione MAC per CPU, quindi l'algoritmo MAC è dichiarato "rotto" (almeno in modo accademico). Attualmente, HMAC / SHA-1 NON è rotto (nemmeno accademicamente), e poiché il suo output è n = 160 bit e uno sforzo CPU di 2 159 è totalmente fuori dalla portata dell'umanità , possiamo dire che nessuno può produrre falsi su HMAC / SHA-1, né tanto meno recuperare la chiave, date coppie di input / output (anche se l'attaccante può scegliere il valori di input in queste coppie).
Quanto sopra presuppone che la chiave sia presa da un insieme di possibili chiavi di dimensione almeno 2 n . Se si utilizza una chiave con meno di n bit, l'utente malintenzionato può semplicemente provare sequenze casuali di bit n finché non viene trovata una corrispondenza. Questo è il attacco di ricerca esaustivo generico. Se la chiave ha una lunghezza di almeno 80 bit o giù di lì, questo non è fattibile con la tecnologia odierna (con una chiave a 128 bit, hai un margine di sicurezza molto consistente). Quindi, di nuovo, questo presuppone che l'insieme di possibili chiavi sia davvero così grande, ovvero che tu abbia usato un PRNG crittograficamente strong per generare la chiave: vedere la risposta di DW per i dettagli.