Conoscere 'a' crittografato con 'b' e 'b' crittografato con 'a' una possibile minaccia?

Ciò che descrivi è molto simile all'idea alla base di Kerberos, ma non risolve realmente i problemi risolti da Kerberos.

Conoscere sia AES (A, B) che AES (B, A) aiuterebbe sicuramente un utente malintenzionato consentendo loro di testare in modo autorevole una decrittazione valida; se non conoscessero nessuno dei due, ma trovarono alcuni candidati per A, B con m1 = AES (A, B), potevano testare che AES (B, A) = m2 dove m2 è l'altro messaggio intercettato. Tuttavia, questa è davvero l'ultima delle tue preoccupazioni.

Le chiavi AES devono essere una lunghezza particolare. Non hai menzionato come funziona la derivazione della chiave, quindi non ne parlerò.

In realtà, il modello corretto per fare questo tipo di cose è derivare una chiave dalla password dell'utente sul nodo client. Il server conosce una chiave che può essere utilizzata per crittografare i dati in modo che il client possa decrittografarli e, su richiesta, crea un token di autenticazione che invia al richiedente in modo crittografato. Il token è inutile per chiunque non conosca la chiave (privata) dell'utente, quindi è sicuro inviarlo a chiunque. L'utente quindi la decrittografa e viene autenticata.

L'utente non ha bisogno di inviare immediatamente questo token; il server può assumere che chiunque possa presentarlo è autenticato come utente per il quale è stato rilasciato.

Ora risolverò altri problemi aggiungendo al modello: la cosa inviata dal server al client non è un token, ma un'altra chiave. L'utente, a condizione di poter decodificare la chiave, può utilizzare tale chiave per firmare le richieste. In questo modo, niente di sensibile deve attraversare la rete in chiaro e non c'è nemmeno bisogno di stabilire un canale affidabile.

Kerberos fa un ulteriore passo avanti consentendo a questa chiave di essere utilizzata per emettere ancora più chiavi, e ha alcuni altri concetti, che consentono a un utente di accedere in un posto per autenticarsi a un altro. Ci sono anche alcuni aspetti che impediscono gli attacchi di riproduzione e altre cose. Tuttavia, per quanto la tua soluzione si discosti da questo modello, è subottimale.

Il punto saliente qui è che non si desidera la password in chiaro ovunque, men che meno sul server, e in realtà non è necessario inviarlo attraverso la rete o verificarlo. Ma, invece di ridisegnare il tuo sistema in modo che corrisponda, basta utilizzare uno dei numerosi metodi di autenticazione challenge-response già implementati e verificati e disponibili.

Gli attacchi contro il tuo schema sono possibili, ma ciò che attacca in particolare dipende dal fatto che il tuo token (il grande numero a cui fai riferimento) sia trattato correttamente come un nonce, quanto è grande, come si ricavano le chiavi da password (e nonces) , come tratti la password sul server, come viene generato il nonce e altre cose. La linea di attacco principale che sceglierei è quella di prevedere il nonce e usarlo per decodificare la password, convalidando il traffico nell'altra direzione.

Sfortunatamente lo stai facendo scorrendo il tuo schema di crittografia.

What may I do to improve this solution?

Non tirare il tuo schema personale. Attenersi alla soluzione collaudata per l'autenticazione. Utilizza TLS / SSL per crittografare il traffico dal client al tuo server. Utilizza un algoritmo di hash di password strong come PBKDF2, bcrypt o scrypt per hash la password per l'archiviazione sul server.

C'è un punto debole nel tuo algoritmo perché è basato su l'ipotesi che il server abbia tutti i client cleartext password.

C'è un secondo punto di debolezza nell'algoritmo nella fase iniziale. Quando un client non ha ancora una password, il server non può inviare un intero casuale criptato con la password del client. Ciò implica che questa password iniziale sia una già esistente e già conosciuta , nota sia dal server che dal client in arrivo.

Per questi 2 motivi (almeno), è stata una buona idea aver esposto il tuo schema di ...

e non averlo usato ☺.

Qui, per questo scenario puoi utilizzare la crittografia asimmetrica come RSA .

Ora, secondo il tuo problema, se utilizzi lo stesso numero intero per la crittografia e la decrittografia, per quanto qualsiasi intercettatore venga a sapere, sarà un problema di sicurezza.

Quindi puoi migliorare usando il modo seguente.

1. I client inviano i suoi dati di accesso - testo semplice
2. Sever crea una coppia di chiavi pubbliche private e invia 1 chiave al protocollo di scambio chiavi del client, e crittograferà il messaggio con la chiave che non è condivisa da lui e lo invierà al client.
3. Quando il client riceve un messaggio crittografato, verrà decrittografato dalla chiave che lo invia già dal server.
4. Nello stesso modo il client crittografa il messaggio generando una nuova coppia o utilizzando la coppia esistente (nuova coppia consigliata) e inviandola al server.

Il problema è che questo scenario è Man-In-Middle Attack quindi dovresti avere implementazioni di sicurezza adeguate per tali cose per risolvere Man-In-Middle Attack puoi leggere questo articolo.

Ma per risolvere il tuo problema principale dovresti usare Crittografia asimmetrica