Connessione TCP Client Server - invio di una password

Question

Connessione TCP Client Server - invio di una password

#1 da (2 voti)

0

Sono nuovo di Cybersecurity e sto scrivendo un server TCP con Java Socket API. Esiste una classe client e server. La classe del server è quella che verrebbe eseguita su un server, che ascolta su una porta specificata e accetta connessioni socket. Se la parte client del programma tenta di connettersi, deve inviare la password corretta crittografata al server. Il server ha un elenco di password corrette, hash con SHA-256.

Ho configurato un sistema di chiavi pubblico-privato RSA, in cui il server mantiene il privato e invia la chiave pubblica al client. Il client esegue l'hashing della password non elaborata con SHA-256, quindi utilizza la chiave pubblica per crittografarlo prima di inviarlo attraverso il socket.

Ciò di cui sono preoccupato (e sono sicuro che ci sono altri problemi) è che un utente malintenzionato userà la chiave pubblica per provare un sacco di password con il server. Se si generano le chiavi simmetriche AES utilizzando una stringa speciale con hardcoded sul lato client e server, sarebbe opportuno cifrare la chiave pubblica stessa con la chiave simmetrica prima di inviarla via cavo e usare quelle chiavi per una comunicazione aggiuntiva?

Non mi interessa nulla oltre alla password che viene inviata dal client al server subito dopo che il socket è stato accettato.

server client aes rsa

posta wilson421 26.10.2017 - 00:06

fonte

1 risposta

Leggi altre domande sui tag server client aes rsa

Genera X509 ERR_CERT_COMMON_NAME_INVALID È possibile acquistare più dispositivi MFA hardware con la stessa chiave?

score 2 · Accepted Answer

Sebbene non ci sia una buona ragione per non usare TLS per salvaguardare questo, il tuo approccio sembra ok ed ecco perché:

La complessità computazionale dell'hash 256 e la crittografia con algoritmi (asimmetrici o ibridi) è piuttosto alta; non c'è (attualmente) alcun modo fattibile per la forza bruta che se le password sono ragionevolmente forti.

Inoltre, se sei preoccupato per la forza bruta, puoi bannare un IP per x ore se la password è sbagliata y volte di fila - come fa fail2ban - e / o aggiungere altro tempo tra gli accessi come fa GNU / Linux .

Detto questo: esiste un modo perfettamente valido per autenticare gli utenti in modo sicuro e questo è TLS.

Per affrontare il tentativo di crittografare la chiave pubblica con la crittografia simmetrica: non c'è alcun guadagno in questo. Se si usano coppie di chiavi ragionevolmente forti, dovrebbe essere computazionalmente non fattibile generare la chiave privata dalla chiave pubblica - i sistemi crittografici asimmetrici sono progettati in modo tale che le chiavi pubbliche debbano essere pubbliche (da cui il nome!).

L'aggiunta di un livello di AES non nuoce in alcun modo, ma introduce ulteriori problemi: il client può essere annullato per ottenere la chiave e rendere inutile il tentativo, e può essere sottoposto a debug per recuperare la chiave simmetrica e / o pubblica dalla memoria. Inoltre, aggiungi più complessità al tuo software, aumentando la probabilità di errori ed errori senza un vantaggio.