Quanto è sicura la tecnica di scambio di chiavi Anti-MITMA Diffie-Hellman di Samy Kamkar?

Da un rapido sguardo, questo è ragionevolmente sicuro contro un attaccante della rete. Tuttavia, richiede al server di memorizzare la password come testo in chiaro, che è scoraggiata. L'archiviazione sicura della password è stata discussa a lungo su questo sito.

Un protocollo un po 'simile è SRP che raggiunge gli stessi obiettivi di Samy Kamkar senza memorizzare una password in chiaro sul server. Come vantaggio collaterale, è in realtà leggermente più veloce in quanto è necessario un numero di round-trip per accedere.

Come punto più generale, il protocollo SRP è stato oggetto di analisi dettagliate e si ritiene che sia sicuro. Il protocollo di Samy non ha (per quanto posso dire) essere sottoposto allo stesso rigore, quindi potrebbero esserci problemi sottili. Dovresti utilizzare SRP per non eseguire rotolo la tua crittografia .

Aggiornamento - Un'altra considerazione è che il protocollo di Samy rivela un hash della password a un utente malintenzionato attivo del MITM, che potrebbe quindi forzare la forza. Questa è una brutta debolezza, a cui SRP non è vulnerabile.

Non è esattamente una risposta diretta, ma la sezione dei commenti è troppo limitata, quindi ...

Potrei essere cieco (una notte insonne può farlo per te) ma quel documento descrive una situazione in cui non vuoi né hai bisogno di uno scambio di chiavi Diffie-Hellman. In realtà, non aggiunge nulla alla sicurezza dell'intera faccenda.

Se entrambe le parti hanno già un segreto condiviso ( password in questo caso) e quel segreto non è noto all'avversario malvagio (Mallory in questo caso), allora perché dovresti affrontare tutti quei problemi in primo luogo ? Dopotutto, DHKE è usato per condividere un segreto su un canale non sicuro, se hai già fatto ciò non hai alcuna utilità per DHKE *. Puoi semplicemente ricavare una chiave simmetrica da quel segreto ed essere abbastanza fiducioso che nessuno può MITM te a meno che non ottenga una sospensione di detto password . Nello pseudo-codice, un esempio diretto:

a:
    password = 54321
    kdfParams = [salt, iterations, other] // depends on the KDF, some or all may be random
    secretKey = KDF(password, kdfParams)
    data = ENCRYPT(secretKey, "Hello, Bob!")
    a->b (data, kdfParams)

m:
    b->m<-a (data, kdfParams)
    // Doesn't know the password and have no use for the publically transmitted kdfParams
    // Can derive the secretKey only through brute-force,
    // so choose your KDF and password carefully

b:
    b<-a (data, kdfParams)
    password = 54321
    secretKey = KDF(password, kdfParams)
    data = DECRYPT(secretKey, data) // << "Hello, Bob!"

Funziona anche nella direzione opposta.

Naturalmente, se Mallory in qualche modo scopre il password , l'intero inferno si scatena, ma il documento di riferimento non aiuta nemmeno quello. Se sei preoccupato della segretezza in avanti e indietro, puoi usare secretKey in HMAC la parte pubblica del DHKE per contrastare qualsiasi attacco MITM e avere una nuova sessionKey per la crittografia ogni volta.

Per concludere, il "metodo" spiegato non è affatto una spiegazione e l'autore non capisce a cosa serve DHKE, o ho bisogno di dormire un po '.

* in questo particolare esempio, CodesInChaos solleva un punto valido sull'utilità generale di DHKE.