vulnerabilità SHA1

Dovresti leggere questo articolo . HMAC è l'opzione preferita in ogni caso. Il modo in cui usi l'hash con chiave espone a tutti i punti deboli dell'algoritmo di hash. HMAC, tuttavia, è ancora sicuro perché la sua sicurezza si basa su ipotesi meno forti sull'algoritmo di hash.

Si noti che il modo opposto di calcolare l'hash hash (KEY || MESSAGE) (al contrario di HASH (MESSAGE || KEY) come si intende farlo) è considerato completamente insicuro come si può leggere qui e qui .

SHA-1 non è generalmente rotto per ogni tipo di caso d'uso. Tuttavia, si ritiene che offra una protezione insufficiente contro gli attacchi di collisione che lo rende inadatto come un algoritmo di firma, ad esempio nei certificati. È ancora sufficientemente sicuro per l'utilizzo in HMAC sebbene sia simile (ma non uguale) al tuo caso d'uso.

Quindi penso che l'SHA-1 nel tuo approccio possa attualmente essere rotto solo con la forza bruta. Dato che SHA-1 è un hash progettato per essere veloce, puoi indurire i tuoi parametri aggiuntivi utilizzando un segreto più lungo o utilizzando un algoritmo progettato per essere più lento. Entrambi gli approcci rendono la forza bruta più difficile poiché è necessario più tempo dall'attaccante per provare tutti i possibili segreti.

Inoltre dovresti usare un vero HMAC come kaidentity indica in la sua risposta perché è meglio usa qualcosa di provato invece per inventare il tuo, specialmente se è coinvolta la crittografia.

Conoscere i parametri e non conoscerne la chiave o conoscerli non fa molta differenza nel caso di chiavi grandi poiché qualsiasi bit aggiuntivo nella chiave genererà uno SHA completamente diverso. Un piccolo vantaggio potrebbe essere per l'attaccante se conoscesse la lunghezza della tua chiave addizionale segreta, ma se quella chiave è abbastanza grande non hai alcun problema. Se la chiave è abbastanza grande, la forza bruta sarebbe un tentativo inutile.

I ricercatori ora hanno ha eseguito con successo un attacco di collisione contro SHA1 , che è il modo in cui MD5 è morto

Cryptographers refer to the attack disclosed Thursday as an "identical-prefix" collision, meaning it allows the attacker to create two distinct messages that have the same hash value. This variety is less powerful than the "chosen-prefix" MD5 collision carried out by Flame. In the latter case, attackers can target one or more existing files, such as the digital certificate that a company uses to authenticate its update mechanism. Despite the collision against SHA1 being less powerful, cryptography experts said any real-world identical-prefix attack represented a game-over event for a hashing function.

C'è un sito web dedicato all'attacco

It is now practically possible to craft two colliding PDF files and obtain a SHA-1 digital signature on the first PDF file which can also be abused as a valid signature on the second PDF file.

In altre parole, smetti di usare SHA1

A seconda dell'implementazione, una cosa che ti viene in mente è che potresti essere vulnerabile a un attacco di estensione della lunghezza in cui un l'attaccante "inizia" dal tuo hash. Non sono sicuro che questo si applica a te, ma:

1. I tuoi parametri sono foo=1&bar=2
2. Sono inviati come foo=1&bar=2&sha(foo, bar, SECRET)
3. Un utente malintenzionato che desidera iniettare o sostituire un parametro potrebbe inizializzare l'hashing SHA da foo=1&bar=2&sha(foo, bar, SECRET) e aggiungere il suo parametro

Non sono entrato nei dettagli tecnici perché non sono sicuro che sia valido per te; inoltre ci sono alcuni requisiti (principalmente, conoscendo la lunghezza della richiesta originale) ma penso che siano soddisfatti da quello che ho capito della tua descrizione.

Inoltre, il tuo schema è vulnerabile agli attacchi di riproduzione: cosa succede se un utente malintenzionato intercetta la transazione e la ripete continuamente? Dal momento che è su HTTP, sarebbe banale.