Quanto è sicuro l'utilizzo di CRAM-MD5 per l'autenticazione e-mail, quando non si utilizza una connessione SSL?

CRAM-MD5 richiede che il server conosca la password effettiva, non solo un'immagine della password tramite una funzione hash. Quindi, se il server deve supportare HMAC-MD5, deve memorizzare la password in testo semplice. (Il server può crittografare la password, ma dal momento che deve anche conoscere la chiave di crittografia, che non aiuta.)

CRAM-MD5 è stato progettato per evitare che la password passi in chiaro. Dà una certa quantità di protezione contro un attaccante passivo. Se l'utente malintenzionato può intercettare la comunicazione ma non inserire messaggi, tutto ciò che ottiene è una sfida C e il valore HMAC-MD5 (P, C) in cui P è la password. Non esiste un metodo migliore per trovare la password da queste informazioni con la forza bruta. La forza bruta è tuttavia un problema con le password: almeno una funzione lenta dovrebbe essere usato, e l'esposizione dell'hash dovrebbe essere comunque evitata e dovrebbe essere trattata come un compromesso.

Invece di una password memorabile scelta dall'uomo, la "password" (più precisamente un segreto condiviso) memorizzata sul server potrebbe essere un lento hash della password umana, come annotato da Adnan . Ciò escluderebbe gli attacchi di forza bruta dall'hash MD5, quindi fornirebbe una migliore protezione contro gli attaccanti passivi. (Tuttavia, chiunque lo faccia usa strumenti non standard, ed è presumibilmente abbastanza serio sulla sicurezza per usare SSL.) CRAM-MD5 autentica solo la fase di autenticazione e non il resto della sessione. Quindi un attaccante attivo che è in grado di impersonare il client può consentire l'autenticazione, quindi tagliare il client (o inviarlo ai dati modificati) e inviare i propri comandi nella sessione. Nello specifico, l'utente malintenzionato deve essere in grado di ricevere pacchetti TCP destinati al client. In alternativa, l'utente malintenzionato deve essere in grado di ricevere pacchetti TCP destinati al server o inviare risposte DNS false che inducano il client a parlare con l'utente malintenzionato anziché con il server; tale aggressore agisce come un relè tra il client e il server durante la fase di autenticazione, quindi può continuare a parlare con il server. Nessuno di questi attacchi comporta una compromissione della password, a proposito, diversa dalla forza bruta come sopra.

L'utilizzo di CRAM-MD5 su SSL risolverebbe questo problema di autenticazione. SSL fornisce una sessione sicura (ovvero i partecipanti non possono cambiare durante la sessione) e autentica il server sul client (presumendo che l'utente non accetti ciecamente un certificato non valido). CRAM-MD5 porta la terza parte del problema di autenticazione: autenticare il client con il server.

CRAM-MD5 su SSL va bene se la password è una stringa abbastanza lunga generata a caso, abbastanza a lungo da resistere alla forza bruta. Se la password è generata a caso, non c'è ragione di non memorizzarla in chiaro sul server, è solo una chiave. CRAM-MD5 è cattivo se la password è quella che un umano può ricordare, perché la maggior parte delle password umane può essere violata dalla forza bruta e sono preziose oltre quel server in quanto vengono spesso riutilizzate.

Se si utilizza SSL, l'uso di CRAM-MD5 è piuttosto scarso rispetto al fatto che il client invia la password tramite la connessione SSL. C'è un piccolo vantaggio nel fatto che se il client invia inavvertitamente la password a un imitatore del server, la password stessa non viene compromessa immediatamente (solo se incrinata - si noti che un imitatore del server può inviare una sfida costante e quindi creare una tabella (arcobaleno o altro) dei valori HMAC-MD5 su password plausibili). Dove la password è una stringa casuale, questo può essere un vantaggio (l'attaccante non può utilizzare il valore inviato dal client per impersonarlo, a meno che il server non invii la stessa sfida dell'attaccante, cosa che non dovrebbe accadere). Laddove la password è umana, non vi è alcun vantaggio (dato che la password può essere violata in ogni caso) e dover memorizzare la password in chiaro è un chiaro svantaggio.

Ci sono tre punti deboli rilevanti in questo caso:

• Archiviazione impropria delle password: se il database del tuo provider è compromesso, la tua password è direttamente esposta. Sebbene alcune implementazioni di CRAM-MD5 non memorizzino password in chiaro, la password con hash non è ancora valida. Finora, non esiste alcuna implementazione nota che salvi la password (il sale deve essere noto anche al client).

• I dati effettivi viaggiano in testo semplice: non utilizzando SSL, le tue e-mail sono totalmente esposte a MiTM .

• Attacco offline: una volta che l'attaccante acquisisce le informazioni utilizzate per l'autenticazione (la sfida inviata dal server, la risposta inviata dal client), è in grado di forzare la password offline.

• Attacco con testo in chiaro: poiché l'autore dell'attacco è in grado di impersonare il server, è anche in grado di inviare i valori della sfida che desidera e di osservare la risposta del cliente. Ciò rende più facile conoscere la password.

Attenzione, nessuno di questi attacchi è correlato alle vulnerabilità in MD5 stesso.

In conclusione: CRAM-MD5 non è sicuro a questo scopo. Il tuo provider non ha scuse per archiviare le password in chiaro, il problema qui è solo la loro riluttanza a implementare una soluzione migliore.

Non fornisce alcuna protezione contro MITM poiché un utente malintenzionato potrebbe inoltrare la richiesta al cliente. Richiedere l'archiviazione di password in chiaro non è buona e lo scambio può avere un attacco di dizionario eseguito contro di esso.

Sei giustificato a essere preoccupato per questo schema e personalmente suggerirei di utilizzare un altro provider di posta elettronica.

In primo luogo, non è necessario utilizzare il testo in chiaro:

Osservando l'implementazione HMAC-MD5 in psuedocode :

puoi almeno memorizzare una versione modificata della password:

    if (length(key) > blocksize) then
        key = hash(key) // keys longer than blocksize are shortened
    end if
    if (length(key) < blocksize) then
        key = key ∥ [0x00 * (blocksize - length(key))] // keys shorter than blocksize are zero-padded ('∥' is concatenation) 
    end if

    o_key_pad = [0x5c * blocksize] ⊕ key // Where blocksize is that of the underlying hash function
    i_key_pad = [0x36 * blocksize] ⊕ key // Where ⊕ is exclusive or (XOR)

Memorizza le due chiavi XOR, c'è una maggiore sicurezza nel fatto che se il tuo sistema è compromesso, gli account di un utente che utilizzano la stessa password non saranno compromessi. Apparentemente Dovecot fa questo.

MD5 di per sé è abbastanza facile da usare la forza bruta. Un utente malintenzionato MITM potrebbe forzare la password come se già conoscesse la sfida.

Al giorno d'oggi, la soluzione a quasi tutti questi problemi è semplicemente usare SSL.

Prima di tutto, il bit in chiaro è una cazzata - la maggior parte delle soluzioni POP / SMTP * nix può essere adattata per non averne bisogno. Con questo fuori mano ...

... CRAM-MD5 ha vulnerabilità scioccanti - provenienti dal suo legame MD5. Tuttavia, è ancora meglio del testo in chiaro. In ordine di apparizione e "OMGWTFBBQ-ness":

1. Un server che utilizza CRAM-MD5 può essere falsificato / MitM-ed in quanto il client non verifica mai l'autenticità del server
2. Le password sono offline non funzionanti (il che dovrebbe essere ovvio)
3. Vengono applicate tutte le vulnerabilità MD5

CRAM-MD5 è effettivamente MD5( (key XOR padding) concat MD5(key XOR morepadding) concat value) accoppiato con le risposte alle sfide. La chiave è la password dell'utente: il valore è la sfida. Quindi, se la sfida è sconosciuta, sarebbe perfetta. Purtroppo, non lo è, poiché viene trasmesso in testo semplice.

In sostanza, evita se puoi. Al giorno d'oggi le GPU possono calcolare un numero spaventoso di hash MD5. Tuttavia, una soluzione semplice è solo per SSL il lotto. Al giorno d'oggi un certificato vale noccioline.