un unico login https per siti differenti

[nik600]

Ditemi un po cosa ne pensate:

Autentificatore HTTPS per virtual hosts su HTTP

Questo documento descrive un sistema per effettuare login sicuri (https) su virtualhosts completamente differenti e con database differenti.
I vantaggi stanno nel non dover creare un servizio https per ogni virtual host che deve avere un login sicuro.

Funzionamento del sistema
1.Quando viene richiesto un login, il virtual host HTTP rimanda l'utente al sito HTTPS, inviando come parametro GET anche l'url del sito su cui si vuole identificare (oppure un identificativo univoco del sito)
2.Il sito HTTPS creerà un form di login
3.il sito HTTPS verificherà la validità del login su un database (sarà necessario che il sito HTTPS possa accedere ad un database contenente le informazioni sui database legati ai vari virtual hosts da autentificare)
4.se il login non va a buon fine non succede nulla (ERRORE)
5.se il login va a buon fine il sito HTTPS manda un messaggio al virtual host (anche tramite semplice richiesta GET) con il quale conferma la validità dell'utente.
Come si può notare il punto 5 è quello che contiene la vulnerabilità di questo processo, infatti un utente malintenzionato potrebbe tentare di indovinare tale protocollo inviando lui stesso delle richieste GET “fasulle”.

Protezione del sistema
La soluzione che propongo è quella di condividere dare un certificato al virtual host http, il virtual host avrà la chiave pubblica, il sito HTTPS la chiave privata.
Il messaggio di validità del login sarà una cosa del tipo:

....?sessid=432423&id_user=432423&digest=324234523 534
dove digest è la stringa sessid+id_user firmata con la chiave privata.
Il virtual host non dovrà fare altro che decriptare la stringa digest con la chiave pubblica, a questo punto sarà sicuro che quel messaggio proviene dal sito HTTPS.

[bubu77]

Originariamente inviato da nik600
I vantaggi stanno nel non dover creare un servizio https per ogni virtual host che deve avere un login sicuro.

Lo svantaggio e che se hai una falla nel sistema ci sono molti siti vulnerabili.
Poi se è offline il sistema madre sono tutti offline.
Poi in questo modo il resto dei dati che transitano sono in chiaro se sono sniffati i pacchetti (molto semplice in lan) possono simulare in toto la connessione e loggarsi.

Ciao

[nik600]

Originariamente inviato da bubu77
Lo svantaggio e che se hai una falla nel sistema ci sono molti siti vulnerabili.
Poi se è offline il sistema madre sono tutti offline.
Poi in questo modo il resto dei dati che transitano sono in chiaro se sono sniffati i pacchetti (molto semplice in lan) possono simulare in toto la connessione e loggarsi.

Ciao

dunque, sui primi due punti ti posso anche dare ragione.

Sull'ultimo sinceramente non molto, nel senso:
Tutto parte dal presupposto che per qualche arcano motivo i vari virtual hosts non siano sotto https (vuoi per motivi di performance, vuoi per motivi tecnici, vuoi per problemi di certificati... , ecc ecc)
La soluzione quindi è quella di proporre https SOLO per la parte più sensibile , e cioè quella del login.
E' vero che il resto dei dati transiteranno su http, ma questa era una cosa che si poteva fare anche prima!

Infine, simulare la connessione e loggarsi non è possibile, perchè i vari virtual hosts verificano che i dati siano stati firmati con la chiave privata del server, di conseguenza chi tenta di bucare il sistema deve riuscire prima a bucare la chiave RSA a 1024 o 2048 bit.

[bubu77]

Originariamente inviato da nik600
Infine, simulare la connessione e loggarsi non è possibile, perchè i vari virtual hosts verificano che i dati siano stati firmati con la chiave privata del server, di conseguenza chi tenta di bucare il sistema deve riuscire prima a bucare la chiave RSA a 1024 o 2048 bit.

Immagino che dopo il login usi le sessioni per verificare se un utente è online, quindi mi basta sniffare il tuo session_id per essere dentro.

Ad ogni richiesta il session id viene inviato in chiaro tramite cookie quindi non è un grosso problema sniffarlo.
Ciao

[luca200]

Originariamente inviato da bubu77
Ad ogni richiesta il session id viene inviato in chiaro tramite cookie quindi non è un grosso problema sniffarlo.

E' vero, ma una cosa è "rubare" una singola sessione, altra cosa è intercettare i dati di login.
Con questi ultimi fai quello che vuoi, fino a quando non vengono cambiati. La sessione invece ha una validità limitata nel tempo, per cui l'attacco deve essere più rapido ed efficiente.

In sostanza a me non sembra una cattiva idea; è chiaro che non risolve qualsiasi problema di sicurezza, però è un miglioramento rispetto alla soluzione "tutto in chiaro", che è la più diffusa per applicazioni non vitali.

[nik600]

Originariamente inviato da luca200

In sostanza a me non sembra una cattiva idea; è chiaro che non risolve qualsiasi problema di sicurezza, però è un miglioramento rispetto alla soluzione "tutto in chiaro", che è la più diffusa per applicazioni non vitali.

è questo che volevo dire

Ovviamente è preferibile tutto sotto https!
Questa soluzione ti permette di avere solo il login su https, e il resto in chiaro.

Parte dal presupposto che la soluzione iniziale sia "tutto in chiaro"

Per quanto riguarda lo sniffing in LAN
la nota è giusta, ma precisando che dovrebbe esserci un hub in mezzo alla rete e non uno switch

Nel caso in cui vi sia uno switch si riesce a sniffare solo utilizzando tecniche tipo arp-spoofing, ma in tal caso se uno arriva a tanto allora vuol dire che è meglio mettere tutto sotto https... ;-)

Il discorso sulla sicurezza è sempre relativo al tipo di dati che si vuole proteggere... poi se si vuole essere pignoli non è mai abbastanza :-D