Usando Username / Password per generare la chiave "pubblica" per la Crittografia

L'utilizzo di una chiave pubblica è un'opzione sempre . La crittografia a chiave pubblica è stata progettata per fare esattamente ciò che stai cercando di fare; scambiare informazioni sensibili su una rete non sicura (Internet) senza che gli osservatori casuali possano annusarlo.

Ottieni il tuo server firmato con un certificato. Se non hai bisogno di fiducia globale (ad esempio, se puoi "introdurre" manualmente ciascun client sul server all'interno di una rete fidata per la prima volta, prima di tentare di connettersi a uno non attendibile), puoi generare un "autofirmato" "certificato gratuito, ma se vuoi una verifica indipendente che sei chi dici di essere, passa attraverso una CA globale che firmerà il tuo certificato, fornendo conferma verificabile di terze parti dell'identità del tuo server (ad un prezzo ovviamente, in genere molto ragionevole).

Una volta ottenuto questo certificato, forza semplicemente tutto il traffico che si collega al tuo server per farlo tramite HTTPS. Il client richiederà il certificato (chiunque può, è un'informazione pubblica), verifica che il certificato corrisponda a quello che si aspetta da te (o che la catena di fiducia sia valida fino a una "radice attendibile"), quindi usa chiave pubblica nel certificato per crittografare un messaggio contenente informazioni sull'algoritmo simmetrico che vogliono usare. Se si accetta, si inizializza lo schema di crittografia e si invia il riconoscimento indietro crittografato con la chiave; in caso contrario, si invia un rifiuto di testo normale e si riprova.

Questo è l '"handshake SSL" ed è stato usato per molto tempo con pochissimi attacchi riusciti contro di esso (di solito sfruttando una vulnerabilità nell'algoritmo di hashing per generare certificati falsi per i siti di phishing; basta usare un SHA- 2 algoritmo e starai bene). Una volta stabilito il canale di crittografia simmetrica, non importa quanto Wild Wild West sia la rete, i dati inviati tra client e server verranno crittografati in modo che nessun altro possa leggerlo. Quindi, possono inviarti le credenziali dell'utente per accedere e stabilire la "sessione dell'applicazione" sulla sessione di rete protetta.

Non consiglierei il tuo schema. Sembra inefficiente (dovendo creare le chiavi da ogni combinazione di nome utente / password, solo per trovare l'origine) e non sicuro, con il server che genera le chiavi private che vengono inviate ai client. È anche vulnerabile agli attacchi di riproduzione, dal momento che non stai proteggendo il canale sottostante, anche se senza vedere il resto dei dettagli, non è chiaro che cosa ottiene un aggressore.

Perché non utilizzare solo SSL ? È pensato per proteggere le informazioni sensibili su reti non sicure, è universalmente supportato ed è probabile che sia più sicuro di qualsiasi cosa tu implementi.

Se è necessario memorizzare questi dati crittografati dopo il trasferimento, utilizzare uno schema di chiave pubblica tradizionale è certamente un'opzione. Non c'è il rischio che qualcuno curiosini una chiave pubblica, dato che sono destinati a essere pubblici. Finché ogni chiave pubblica di ciascuna parte è firmata, da ognuno di loro , o da alcuni terze parti affidabili di fiducia , quindi non c'è il rischio di un attacco man-in-the-middle.

tldr: usa SSL. Se è necessario memorizzare i dati dopo il trasferimento, utilizzare PGP.

Perché non stai utilizzando SSL? No, davvero.

Genera un certificato autofirmato che tieni riservato. Quindi utilizzare il certificato per il proprio server o (ancora meglio) utilizzarlo per firmare un certificato specifico del server. Spedisci il certificato autofirmato (ma non la chiave privata, ovviamente) con il software che intendi utilizzare.

Quindi, quando avvii la connessione SSL al server, utilizza il certificato spedito come unica CA attendibile, ovvero non accettare connessioni firmate da qualsiasi altra CA .

A questo punto, sarai sicuro di comunicare direttamente con il tuo server fidato su un canale protetto. Nessun man-in-the-middle è possibile perché ci si fida solo delle connessioni protette con la chiave del server.

Ora, autentica il client usando qualsiasi meccanismo tu voglia. Dato che sei sicuro che intercettazioni, manomissioni o riproduzioni non siano possibili attraverso la connessione protetta, non devi fare nulla di speciale.