Difetti di autenticazione reciproca possibili

2

Sto prendendo questo esempio di autenticazione reciproca da Wikipedia:

Server sends a unique challenge value sc to the client
Client generates unique challenge value cc
Client computes cr = hash(cc + sc + secret)
Client sends cr and cc to the server
Server calculates the expected value of cr and ensures the client responded correctly
Server computes sr = hash(sc + cc + secret)
Server sends sr
Client calculates the expected value of sr and ensures the server responded correctly
where

sc is the server generated challenge
cc is the client generated challenge
cr is the client response
sr is the server response

Sto cercando di vedere se c'è un possibile problema di sicurezza qui. Supponendo che stiamo usando una strong funzione di hash e una chiave simmetrica AES, pensi che esista un difetto di sicurezza qui?

    
posta Pedro Kali 21.03.2017 - 01:36
fonte

1 risposta

0

Penso che il server dovrebbe prima autenticarsi. Il problema ora è che il client può essere ingannato per autenticarsi a una terza parte che a sua volta si autentica attivamente sul server, che si completerà alla fine del server, anche se fallisce al client. L'uomo nel mezzo potrebbe quindi continuare con le azioni, anche se il client ha fallito e disconnesso da molto tempo.

Il modo migliore qui è avere il mittente per inviare sc, e hash (sc, hash (segreto)) al client al primo passaggio. Al secondo passaggio, prima che il client generi cc, controllerà che l'hash corrisponda al valore previsto.

Con il doppio hashing del segreto, ottieni ulteriore sicurezza.

Altrimenti, la comunicazione si spegne come descritto. Quindi sarà molto sicuro, poiché il client rifiuterà di avviare l'autenticazione se l'hash generato dal server non corrisponde.

    
risposta data 21.03.2017 - 02:11
fonte

Leggi altre domande sui tag