Questo metodo di autenticazione impedirebbe a MiTM di ottenere la password?

0

Supponendo che SSL / TLS non possa essere usato in questo contesto, questo metodo è abbastanza sicuro per autenticare qualcuno senza che qualcuno ascolti sia in grado di recuperare la password dalle informazioni trasmesse.

  1. Il client invia una richiesta di accesso.
  2. Il server risponde con un identificativo univoco per l'accesso
  3. L'utente inserisce la password
  4. Il client esegue l'hashing della password e crittografa l'identificativo con la password hash ( encryption(value: identifier, key: hash(password)) )
  5. Il client invia l'identificatore crittografato + lo username
  6. Il server riceve il messaggio crittografato ottiene la password di decodifica dal database utilizzando il nome utente fornito dal client e controlla se è in grado di recuperare l'identificatore utilizzando la password.
  7. Se l'identificatore è stato recuperato correttamente, l'autenticazione del server ha esito positivo.
posta user36976 05.08.2014 - 10:12
fonte

3 risposte

2

La risposta è no.

The server replies with a unique identifier for the login

Questo passo in sé contiene un difetto. Un MITM può semplicemente intercettare questa risposta, modificare l'identificativo univoco e osservare come il client invia l'identificatore crittografato + il nome utente. Se l'autore dell'attacco ha tabelle arcobaleno pre-calcolate per qualsiasi identificatore univoco viene iniettato, quindi ottenere la password è banale.

    
risposta data 05.08.2014 - 15:44
fonte
1

Questo è appena più sicuro della trasmissione della password in chiaro.

Ovviamente l'algoritmo di crittografia dovrebbe essere resistente contro gli attacchi di testo in chiaro noti, ma questo non è un problema (AES è).

Ma anche se un MitM non sarebbe in grado di calcolare direttamente la password dal testo cifrato che ha intercettato, potrebbe facilmente eseguire un attacco di dizionario offline e provare solo un sacco di hash delle password fino a quando non decifra correttamente l'identificatore. Il solito metodo di salare le password per rendere inefficaci gli attacchi del dizionario non funziona qui, poiché sia il server che il client (e quindi l'utente) dovrebbero conoscere il sale.

    
risposta data 05.08.2014 - 10:42
fonte
0

Se controlli l'applicazione il client ha perché non incorpora una chiave pubblica nel client e la usa per crittografare i dettagli di accesso? Sarebbe difficile sostituire la chiave ecc. Ma sarebbe semplice e robusta, specialmente se si dispone di un canale di distribuzione sicuro per l'installazione del software originale per impedire la modifica della chiave.

Se davvero dovessi trovare un modo, credo che funzionerebbe:

  1. Il client invia il nome utente al server
  2. Il server calcola HMAC (usersHashedPasswordFromDB, randomToken)
  3. Invia i risultati al client insieme al modulo di accesso
  4. Client calcola HMAC (slowHash (password), randomToken)
  5. Client checks (2) = (4)
  6. Il client sa che randomToken è venuto da qualcuno che conosceva l'hash della propria password - il server
  7. Client calcola quickHash (slowHash (password) + randomToken) (slowHash memorizzato nella cache da precedente)
  8. Il client invia hash al server
  9. Il server calcola quickHash (usersHashedPasswordFromDB + randomToken) e si confronta con hash fornito

Dove quickHash () è un'implementazione hash di sicurezza rapida e slowHash () è una funzione adatta con sale e funzione di lavoro che è la stessa su client e server - possibilmente usando dominio e username come il sale, per esempio.

Saresti comunque vulnerabile a un attacco di dizionario poiché l'unico segreto è la password dell'utente - ma questo può essere mitigato dal blocco o dal back-off lato server sui tentativi falliti (anche se questo comporta un rischio di negazione del servizio).

Felice di input e commenti / correzioni.

    
risposta data 05.08.2014 - 16:36
fonte

Leggi altre domande sui tag