Sta usando l'algoritmo di hashing md5 come metodo per l'autorizzazione in una richiesta POST HTTP non sicura?

Questa idea solleva bandiere rosse nella mia testa per alcuni motivi:

1. MD5 viene interrotto in modo da consentire a un utente malintenzionato di calcolare un hash in collisione, in modo che md5(a + b) == md5(a + c) non debba conoscere b . In questo caso, a è il tuo ID utente e b è il tuo segreto. Come tale, MD5 è una cattiva scelta qui. Anche gli hash della famiglia SHA sono una cattiva scelta, perché si basano sulla stessa costruzione e hanno lo stesso problema. Aggiornamento: No, ho sbagliato. MD5 non è così rotto come pensavo. Indipendentemente da ciò, i seguenti punti sono veri ...
2. Se ti affidi a MD5 per la resistenza a forza bruta, avrai dei problemi. MD5 funziona troppo velocemente per questo tipo di cose. È necessario utilizzare un KDF lento come PBKDF2 o bcrypt. Anche così, questo sembra un uso strano per un hash o KDF.
3. Il sale sembra non servire a nulla qui. I sali sono usati per prevenire attacchi precomputazionali come le tabelle arcobaleno e i database hash. Se l'obiettivo è impedire attacchi di replay, il sale non ti aiuterà qui. Un utente malintenzionato sarà in grado di riprodurre i messaggi di autenticazione.
4. Un utente malintenzionato può modificare la richiesta in transito eseguendo un attacco man-in-the-middle. In tal modo è libero di modificare arbitrariamente questi messaggi.

L'unico modo per farlo correttamente è usare HTTPS (cioè TLS) per la connessione. Questo fornisce autenticità e riservatezza e impedisce attacchi di riproduzione.

L'ID utente o la passphrase scadono dopo un singolo utilizzo? In caso contrario, cosa impedirebbe a un utente malintenzionato di riutilizzare l'hash MD5 (o qualsiasi hash) di tali informazioni per effettuare una richiesta diversa? Perché nemmeno preoccuparsi di farlo? Risposta: No, non è sicuro.

In generale, direi di no.

Stai facendo affidamento su questa proprietà: un utente malintenzionato conosce Y e Hash(X+Y) ma non conosce X . Non deve essere in grado di determinare H(X+Z) per qualsiasi Z non uguale a Y .

Il problema è che MD5 non ha questa proprietà e non è stato progettato per resistere a questo tipo di attacco. In effetti, nessun hash Merkle-Damgård può resistere a questo tipo di attacco.

L'API di Flickr presupponeva che MD5 avesse questa proprietà decimata da un attacco di questo tipo .

Come lo descrivi, le cose vanno come segue: il tuo sito Web deve inoltrare una richiesta a un altro sito Web, e quest'ultimo accetterà solo se la richiesta viene fornita con un "blob di autenticazione" che è l'hash di un identificativo utente e la sua password. Questo blob (il risultato MD5) è quindi "la password" poiché mostra che è sufficiente per garantire l'accesso; questo è molto debole per quanto riguarda gli intercettatori, dal momento che spiare la linea sarebbe sufficiente per recuperare il blob, a quel punto l'attaccante potrebbe collegarlo alle richieste che vorrebbe inviare.

Se il protocollo non è come descritto sopra, ma lega l'hash ai dati richiesti (ad esempio l'hash non viene calcolato sull'ID utente e sulla passphrase da solo , ma anche sul percorso dei dati richiesti), quindi l'autenticazione è un po 'meno debole, ma ancora non buona; Mostrerebbe i due classici peccati:

1. L'intercettazione rivela un valore hash calcolato sulla passphrase e alcuni dati noti, consentendo un attacco dizionario offline : l'hacker "prova" solo alcune potenziali password finché non viene trovata una corrispondenza con l'hash osservato. Dato che una GPU da 150 $ può calcolare miliardi di istanze MD5 al secondo, anche le password di media potenza non resisteranno per molto tempo all'assalto.

2. L'intera comunicazione non è protetta, quindi gli intercettatori osserveranno i dati stessi (i dati per i quali è stata utilizzata l'autenticazione di accesso, quindi i dati sensibili ). Gli attaccanti attivi saranno in grado di manipolare le richieste e le risposte in modo arbitrario.

La riscossione si ottiene con l'uso di SSL , che risolve entrambi i problemi.