Questo processo è un modo sicuro per gli utenti di accedere? Se è così, c'è già un nome?

Se il tuo obiettivo è quello di fermare gli attacchi degli uomini nel mezzo, in teoria funziona in teoria, ma in pratica cade a pezzi abbastanza facilmente. Questo è solo ciò che vedo come ovvio. Sono sicuro che ci sono più cose che mi sono perse.

Stai facendo affidamento sulla segretezza della password per proteggere l'intera conversazione, il che significa che è effettivamente una chiave simmetrica. Le password definite dall'utente non sono fondamentalmente casuali, quindi la possibilità di indovinare la chiave è un vero problema. Potresti usare una chiave derivata basata sulla password e questo renderebbe la chiave un po 'più strong.

Devi memorizzare la password non protetta (non con hash), che di solito è una cosa brutta da fare, perché qualsiasi violazione di tale elenco significa che ogni utente è fregato. È possibile memorizzare la chiave derivata equivalente, ma se l'utente malintenzionato ottiene quel valore, può semplicemente ignorare la derivazione sul lato client.

Qui ci sono anche una serie di requisiti crittografici indefiniti, come accordo sugli algoritmi, utilizzo IV, ecc. Come si protegge il canale da un MITM che specifica un algoritmo debole, o usa un IV di { 0, 0, 0, 0, 0, 0, 0, 0 } , o ecc.

I passaggi 5-6 possono essere riprodotti da un utente malintenzionato un numero infinito di volte entro il periodo di validità del timestamp. Sia il client che il server devono essere sincronizzati in termini di tempo, altrimenti è molto facile per loro divergere e avrai bisogno di una finestra più ampia, altrimenti otterrai una serie infinita di richieste non valide. Questo è un problema abbastanza serio con i sistemi distribuiti. Hai bisogno di un modo per sapere da entrambe le parti che non hai mai visto quel particolare messaggio prima.

Cosa succede quando hai autenticato entrambe le parti? È così? Una cosa sola? E il resto delle comunicazioni tra i due? Le probabilità sono piuttosto buone, non stai solo autenticando. Un utente malintenzionato può semplicemente attendere il completamento dell'autenticazione prima di iniziare a trafficare con i dati per fare ciò che vuole fare.

Quello che stai cercando di fare è dimostrare l'autenticità di entrambe le parti e quindi creare un canale sicuro tra loro sulla base di tale autenticità. In quanto tale è necessario concordare una chiave per il canale. Questa è una scambio di chiavi di qualche tipo. Questa potrebbe essere una domanda utile da cercare anche a.