SSL rispetto all'auto-implementazione di RSA?

Question

SSL rispetto all'auto-implementazione di RSA?

#1 da (2 voti)

0

Attualmente scrivo un'applicazione client che comunica con un server PHP.

L'applicazione stessa richiede credenziali utente valide e ottiene tutte le sue informazioni facendo richieste POST al server PHP. Il primo scenario è sicuro o dovrei usare SSL / TLS invece?

Primo scenario (già implementato):

L'applicazione client ha una chiave pubblica RSA hardcoded
L'applicazione genera una chiave AES casuale e una IV ad ogni avvio. (Non usa mai la stessa chiave e IV per crittografare il nome utente e la password)
L'applicazione client crittografa la chiave AES e IV con la chiave pubblica RSA in una stringa
Il server PHP decrittografa la stringa e memorizza la chiave AES e IV
L'applicazione client crittografa il nome utente e la password durante il tentativo di accesso
Il server PHP riceve i dati crittografati, decodifica i dati e utilizza password_verify per vedere se le credenziali di accesso corrispondono a quelle memorizzate
Dopo aver effettuato il login con successo, l'applicazione client necessita di alcuni dati utente e richiede un nonce dal server PHP utilizzando il nome utente e la password crittografati
Il server PHP crittografa il nonce e lo invia all'applicazione client
L'applicazione client decodifica il nonce e lo invia con la richiesta POST
Il server PHP dà un'occhiata al database e vede che il nonce è valido
Il server PHP invia i dati crittografati AES richiesti dall'utente
L'applicazione client decodifica ora i dati

Secondo scenario:

Implementazione dell'autenticazione ssl reciproca

tls aes rsa

posta wHaT 27.01.2015 - 12:59

fonte

1 risposta

Leggi altre domande sui tag tls aes rsa

Sono stato phishing? [chiuso] whitelist IP come metodo di autenticazione a due fattori per l'accesso al server sotto PCI DSS

score 2 · Accepted Answer

Se vuoi una certa sicurezza, devi pensare non solo a riservatezza (rendendo i dati illeggibili a intercettazioni passive) ma anche a integrità (rilevando in modo affidabile le alterazioni da attivo attaccanti). Gli attaccanti attivi non sono una nozione fantascientifica; il tipico attaccante attivo a buon mercato è un cattivo ragazzo che siede in un parco o in un ristorante e gestisce un falso punto di accesso "WiFi gratuito", in attesa che le vittime si connettano attraverso di lui.

L'integrità deve essere garantita all'interno di ogni singolo messaggio (quindi la "crittografia AES" non è sufficiente, è necessario anche un MAC ) e tra i messaggi successivi (l'utente malintenzionato potrebbe tentare di eliminare messaggi, duplicare messaggi, riordinare messaggi e mescolare le conversazioni tra vari server e client).

Tutto questo può essere fatto, ma richiede molta cura e impegno, e il risultato finale sarà, più o meno, SSL / TLS : quando il protocollo è stato sufficientemente espanso e corretto per tenere conto di tutti i possibili attacchi, mostrerà funzionalità interne simili a quelle di TLS, con complessità comparabile. Pertanto, c'è poco da aspettarsi semplicemente usando TLS.

Inoltre, il protocollo che è più semplice e veloce da progettare e implementare in modo sicuro (un compito piuttosto scoraggiante) è il protocollo che è già stato progettato e implementato in modo sicuro, così potrai risparmiare un sacco di tempo e mal di testa semplicemente usando TLS. Nel caso specifico in cui si ha un'applicazione dedicata, è possibile utilizzare un certificato autofirmato di base sul lato server e inserire una copia di tale certificato nel client, in modo che la convalida X.509 sia un semplice bit per bit confronto (quindi non è necessario acquistare e rinnovare un certificato da una CA commerciale). Questo certificato gestisce l'autenticazione del server; una volta impostato il tunnel, il client può semplicemente inviare il nome utente e la password al suo interno.