Accesso a un sito Web, possiamo utilizzare RSA per inviare la password dal client al server, ma che dire del contrario?

Question

Accesso a un sito Web, possiamo utilizzare RSA per inviare la password dal client al server, ma che dire del contrario?

#1 da (4 voti)
#2 da (1 voti)
#3 da (0 voti)

1

Sto creando un'app per Android banking:
Parte I
Pertanto, mentre l'utente sta effettuando l'accesso, dovrà fornire la propria email e password in un modulo all'interno dell'app. Ok, quindi possiamo crittografare la password utilizzando RSA e invieremo il messaggio crittografato (Let this message be called E) al server (nel mio caso un php), che decritterebbe i dati e confronterebbe la password con hash ... E il server saprebbe la password è corretta.

1) Un hacker non può monitorare i dati trasferiti tra il telefono dell'utente e un wifi in grado di conoscere E ? Quindi non sarebbe in grado di inviare E al server e fingere di essere l'utente che sta effettuando l'accesso?

Parte II
Ora il server risponde al client, dopo aver verificato la password, e gli invia alcuni dati privati, ad esempio il suo saldo (o le transazioni private).
caso a: Non crittografiamo i dati privati, l'hacker qui sarebbe ovviamente in grado di vedere i dati privati (che dovrebbero essere privati). caso b: crittografiamo i dati, utilizzando la crittografia a chiave pubblica segreta, in modo che la chiave privata si trovi all'interno dell'app.

2) Ma la chiave privata in questo caso (caso b) non sarebbe effettivamente "non privata" in quanto un hacker potrebbe decifrare il mio file apk e vedere la chiave privata? Qual è la soluzione?

3) Nel caso b, il metodo di crittografia (RSA) è sbagliato? C'è un metodo migliore?

java encryption android rsa

posta Bilal Fares 24.02.2017 - 21:56

fonte

3 risposte

Leggi altre domande sui tag java encryption android rsa

"Attività insolita" su più account Microsoft Pixel trasparente nel log degli errori di nginx ... È questo l'hacking?

score 4 · Answer 1

1) Quello che descrivi è conosciuto come un attacco di replay. Se si criptasse semplicemente un messaggio con RSA di testo (senza padding casuale o nonce incorporato nel messaggio) ciò sarebbe possibile. Tuttavia, quando le persone usano RSA per inviare dati, solitamente si riferiscono a SSL / TLS, dove RSA è il metodo utilizzato per scambiare una chiave simmetrica che viene poi utilizzata per il resto della comunicazione. Se utilizzi Chrome e vai alla sicurezza in una pagina utilizzando https, puoi vedere un messaggio come

La connessione a questo sito è crittografata e autenticata utilizzando un protocollo strong (TLS 1.2), uno scambio di chiavi strong (ECDHE_ECDSA con X25519) e un cifrario strong (AES_128_GCM).

che mostra che ECDHE (curva ellittica diffe-hellman) è stato usato al posto di RSA come crittografia a chiave pubblica e la chiave simmetrica era AES-128. In questo protocollo sono incluse misure per prevenire attacchi di replay. se non si utilizza SSL e si desidera semplicemente utilizzare RSA, è necessario aggiungere un nonce o padding

2 e 3) come accennato in precedenza, non dovresti aver bisogno di inserire una chiave privata nella tua app. È possibile utilizzare la chiave pubblica del server per comunicare e stabilire una chiave simmetrica. La crittografia di interi messaggi con RSA è considerata lenta e dovresti davvero usare una libreria esistente per fare SSL / TLS o altro. E evita di rotolare la tua cripto. Se RSA è sicuro è un'altra domanda. Certamente ha dimensioni abbastanza elevate della chiave (2048), ma altri metodi di scambio chiave hanno altri vantaggi (come diffe-hellman che nasconde la chiave da un osservatore esterno, anche se fatto in testo semplice)

score 1 · Answer 2

Is there a better method?

Sì. Utilizza TLS .

La crittografia da sola non ti farà mai desiderare. Anche se affronti i problemi di intercettazione e replay in qualche modo, sei ancora in una posizione in cui l'app non può essere certa che stia parlando con il server legittimo. Tutta la privacy nel mondo non importa se le tue comunicazioni private stanno andando a una festa sconosciuta. Questo problema è noto come "trust".

TLS ti darà la possibilità di autenticare il server (ad esempio, assicurati di non parlare con un hacker che ha impersonato il server). TLS utilizza una PKI che consente di autenticare la catena di autorità e garantire che il destinatario dei tuoi messaggi sia un'entità affidabile.

Ora, potresti provare a far crescere la tua PKI, ma il fatto è che probabilmente non hai la tua autorità di certificazione o un modo per distribuire i certificati alla tua app in modo sicuro. Solo PKI e CA pubbliche hanno questa capacità, quindi TLS è la tua unica opzione fattibile.

score 0 · Answer 3

Per prima cosa, concordo con John Wu. Utilizza prima TLS.
Quindi, sicurezza TLS con certificato client, memorizzato nel pacchetto di app mobili.
Terzo: suggerisco di non fare affidamento sulla password lato client. Quindi, è possibile generare una password sul lato server, prendere un hash e quindi - inviare questo hash che verrà crittografato dalla password del client con una cifratura strong. Quindi, memorizzato sul lato client, il risultato non può diventare un hash senza la password del client. Sarà decrittografato localmente per ottenere l'hash. Se si aggiunge un po 'di entropia e si modifica la firma dei dati basata sulla sessione, si può garantire che i dati trasmessi siano protetti in modo efficace.
Ma se vuoi essere sicuro della protezione dei dati, usa diverse reti per trasferire parti delle chiavi di sessione. Ad esempio, sms o codice di callback audio insieme alla trasmissione ip.