[Java]Simulare autenticazione

[Jak696]

Ciao :D

avrei bisogno di ottenere qualcosa di simile ad un'autenticazione (con tanto di sessionID) per un programma Java client-server, l'avevo pensata con crittografia asimmetrica (chiave pubblica-privata):

-il server genera una coppia di chiavi (che rimarrà inviariata per tutto l'uptime)
-il client che vuole autenticarsi genera una coppia di chiave e invia quella pubblica al server
-il server invia la sua chiave pubblica al client
-il client cifra i dati di login (user e pw) con la chiave pubblica del server e glieli invia
-il server decifra con la sua chiave privata, verifica la correttezza sul DB, se OK invia il sessionID cifrato con la chiave pubblica del client
-il server decifra il session ID, lo cifra nuovamente con la chiave pubblica del server e ad ogni richiesta lo invia (verrà verificato ogni volta dal server)

sono impreparato in materia e in internet ho trovato poco niente al riguardo... è efficace come meccanismo?
il mio dubbio è principalmente sul fatto che il client reinvia sempre lo stesso sessionID, d'accordo che è cifrato ma la stringa è la stessa, se un malintenzionato volesse accedere alle risorse spacciandosi per utente potrebbe intercettare i pacchetti di richiesta (o fingersi server), quindi il sessionID e appenderlo a delle sue richieste personalizzate

o forse sto sognando? :confused:

[Jak696]

riflettendoci, il meccanismo di login sarebbe soggetto allo stesso problema

genererò una coppia di chiavi per ogni login, che in seguito allo stesso verrà distrutta, ma fare la stessa cosa per ogni richiesta è decisamente troppo oneroso (rallenterebbe enormemente tutto...)

potrei trasmettere il sessionid in chiaro e fare una verifica incrociata con l'indirizzo ip, se entrambi corrispondono poi garantire l'accesso alle risorse (lo svantaggio sarebbe che se uno si disconnette da internet per cambiare ip una volta riconnesso dovrebbe rifare il login, ma mi sembra accettabile)

ma il sessionid in php/jsp/asp come si comporta?

[Jak696]

up

[wisher]

Prova a guardare qui:
http://it.wikipedia.org/wiki/Nonce

[Jak696]

Prova a guardare qui:
http://it.wikipedia.org/wiki/Nonce
ho dato un'occhiata, quello più che altro però per il meccanismo di login, inoltre non è molto chiaro ci ho capito poco... grazie comunque
sembra un argomento quasi taboo su internet l'autenticazione, si trova poco o niente :muro:

[morskott]

a quest'ora data la stanchezza non garantisco, ma prova questo algoritmo inventato sul momentoC -> S: auth
S -> C: Nonce
C -> S: A=C_K_PRV_C(C_K_PBL_S(Nonce,USN,PSW,t_c_0)), memorizza t_c_0
S: D_K_PRV_S(D_K_PBL_C(A)), verifica Nonce, verifica USN e PSW e memorizza t_c_0, genera SessionUID=SUID
S -> C: C_K_PBL_C(SUID,t_s_0)
C: memorizza SUID e t_s_0

per ogni messaggio scambiato da C a S al momento i

C -> S: B=C_K_PBL_S(messaggio,SUID,t_c_o+i)
S: D_K_PRV_S(B), verifica SUID e che la copia memorizzata di t_c_0 con aggiunto i sia uguale a quella ricevuta (evitare messaggi ripetuti)

per ogni messaggio scambiato da S a C al momento i

S -> C: F=C_K_PBL_C(messaggio,SUID,t_s_0+i)
C: D_K_PRV_C(F), verifica SUID e che la copia memorizzata di t_s_0 con aggiunto i sia uguale a quella ricevuta (sempre per i messaggi ripetuti)

con X_K_YYY_Z intendo X (C = cripta - D = decripta) con la chiave K YYY (PRV = privata - PBL = pubblica) di Z (C = client - S = server)dovrebbe, e sottolineo il condizionale, evitare attacchi sia di attacco nel mezzo che attacchi di reply, magari domani o poi lo rivedrò e vedrò cosa c'è di sbagliato

[Jak696]

a quest'ora data la stanchezza non garantisco, ma prova questo algoritmo inventato sul momentoC -> S: auth
S -> C: Nonce
C -> S: A=C_K_PRV_C(C_K_PBL_S(Nonce,USN,PSW,t_c_0)), memorizza t_c_0
S: D_K_PRV_S(D_K_PBL_C(A)), verifica Nonce, verifica USN e PSW e memorizza t_c_0, genera SessionUID=SUID
S -> C: C_K_PBL_C(SUID,t_s_0)
C: memorizza SUID e t_s_0

per ogni messaggio scambiato da C a S al momento i

C -> S: B=C_K_PBL_S(messaggio,SUID,t_c_o+i)
S: D_K_PRV_S(B), verifica SUID e che la copia memorizzata di t_c_0 con aggiunto i sia uguale a quella ricevuta (evitare messaggi ripetuti)

per ogni messaggio scambiato da S a C al momento i

S -> C: F=C_K_PBL_C(messaggio,SUID,t_s_0+i)
C: D_K_PRV_C(F), verifica SUID e che la copia memorizzata di t_s_0 con aggiunto i sia uguale a quella ricevuta (sempre per i messaggi ripetuti)

con X_K_YYY_Z intendo X (C = cripta - D = decripta) con la chiave K YYY (PRV = privata - PBL = pubblica) di Z (C = client - S = server)dovrebbe, e sottolineo il condizionale, evitare attacchi sia di attacco nel mezzo che attacchi di reply, magari domani o poi lo rivedrò e vedrò cosa c'è di sbagliato
ti ringrazio! sinceramente però ci ho capito poco...
A=C_K_PRV_C(C_K_PBL_S(Nonce,USN,PSW,t_c_0)) cos'è? :eek:

se ne hai voglia me lo spiegheresti in maniera più semplice?

[morskott]

ti ringrazio! sinceramente però ci ho capito poco...
A=C_K_PRV_C(C_K_PBL_S(Nonce,USN,PSW,t_c_0)) cos'è? :eek:

se ne hai voglia me lo spiegheresti in maniera più semplice?

In pratica cripti il nonce che ti ha dato il server, la tua username, la password e un timestamp (che serve per evitare attacchi di reply) con la chiave pubblica del server E firmi il messaggio con la chiave privata del client di modo che il server sa con sicurezza che sei stato tu a mandarlo (eviti che un terzo cerchi di autenticarsi con credenziali di un altro). La firma di un messaggio è codificando il msg con la chiave privata e la verifica decodificando con la chiave pubblica

[Jak696]

ok, mi stai dando ottimi spunti!

mi potresti spiegare anche in cosa effettivamente consinste il nonce (wikipedia è poco chiara)?

[morskott]

In pratica è un numero del tutto casuale che il server genera per evitare attacchi di reply, in pratica se non ci fosse un attaccante che sniffa la prima autenticazione e si tiene i dati di autenticazione forniti dal client senza il nonce può riutilizzarli successivamente per autenticarsi come il client da cui ha sniffato la comunicazione.

[Jak696]

In pratica è un numero del tutto casuale che il server genera per evitare attacchi di reply, in pratica se non ci fosse un attaccante che sniffa la prima autenticazione e si tiene i dati di autenticazione forniti dal client senza il nonce può riutilizzarli successivamente per autenticarsi come il client da cui ha sniffato la comunicazione.
capito... quindi il timestamp non è neccesario, giusto?

[morskott]

capito... quindi il timestamp non è neccesario, giusto?

non per la prima fase, è necessario per evitare che il messaggio i-esimo sia intercettato così com'è da un attaccante e rimandato dopo, il SUID è lo stesso, il messaggio può essere legale perchè già utilizzato ma con in piu il timestamp se so che mi hanno già mandato un messaggio con quel timestamp e lo ricevo di nuovo so per certo che o è un duplicato dalla rete o un attaccante che ci prova, senza dovrei solo che ritenere il messaggio valido ed eseguire quel che il messaggio dice.
L'attaccante rimanda il pacchetto così come l'ha ricevuto, quindi in questo caso le chiavi di cifratura non fanno differenza.

[Jak696]

non per la prima fase, è necessario per evitare che il messaggio i-esimo sia intercettato così com'è da un attaccante e rimandato dopo, il SUID è lo stesso, il messaggio può essere legale perchè già utilizzato ma con in piu il timestamp se so che mi hanno già mandato un messaggio con quel timestamp e lo ricevo di nuovo so per certo che o è un duplicato dalla rete o un attaccante che ci prova, senza dovrei solo che ritenere il messaggio valido ed eseguire quel che il messaggio dice.
L'attaccante rimanda il pacchetto così come l'ha ricevuto, quindi in questo caso le chiavi di cifratura non fanno differenza.
beh ma se un attaccante si trova in mezzo, intercetta e blocca la richiesta, la modifica lasciando invariato il timestamp, la richiesta risulta ancora valida al server (non avendo ricevuto l'originale), no?
scusa, forse mi sta sfuggendo qualcosa

[morskott]

Rileggendo l'algoritmo mi son accorto che può esser passibile di un attacco, pensa se quando il server manda al client che ha riconosciuto il SUID un attaccante intercetti il messaggio e lo sostituisce con magari un altro messaggio di una precedente legale sessione di quel client con quel server, e quindi gli passa al client il vecchio SUID con cui non ci può far niente, il client non se ne accorgerebbe proprio, piccola modifichetta usando 2 nonce, uno per il client, l'altro per il serverC -> S: auth
S -> C: Nonce_s
C -> S: A=C_K_PRV_C(C_K_PBL_S(Nonce_s,Nonce_c,USN,PSW,t_c_0)), memorizza t_c_0
S: D_K_PRV_S(D_K_PBL_C(A)), verifica Nonce_s, verifica USN e PSW e memorizza t_c_0, genera SessionUID=SUID
S -> C: C_K_PBL_C(Nonce_c,SUID,t_s_0)
C: verifica Nonce_c,memorizza SUID e t_s_0

per ogni messaggio scambiato da C a S al momento i

C -> S: B=C_K_PBL_S(messaggio,SUID,t_c_o+i)
S: D_K_PRV_S(B), verifica SUID e che la copia memorizzata di t_c_0 con aggiunto i sia uguale a quella ricevuta (evitare messaggi ripetuti)

per ogni messaggio scambiato da S a C al momento i

S -> C: F=C_K_PBL_C(messaggio,SUID,t_s_0+i)
C: D_K_PRV_C(F), verifica SUID e che la copia memorizzata di t_s_0 con aggiunto i sia uguale a quella ricevuta (sempre per i messaggi ripetuti)

con X_K_YYY_Z intendo X (C = cripta - D = decripta) con la chiave K YYY (PRV = privata - PBL = pubblica) di Z (C = client - S = server)

[morskott]

beh ma se un attaccante si trova in mezzo, intercetta e blocca la richiesta, la modifica lasciando invariato il timestamp, la richiesta risulta ancora valida al server (non avendo ricevuto l'originale), no?
scusa, forse mi sta sfuggendo qualcosa

dovrebbe poter craccare la chiave, quindi non è un'eventualità, se cracca la chiave non c'è difesa che tenga, ogni messaggio è cifrato e quindi ritenuto intelleggibile, al massimo un attaccante puo ritrasmetterlo così com'è senza manco sapere cosa c'è dentro.

[Jak696]

dovrebbe poter craccare la chiave, quindi non è un'eventualità, se cracca la chiave non c'è difesa che tenga, ogni messaggio è cifrato e quindi ritenuto intelleggibile, al massimo un attaccante puo ritrasmetterlo così com'è senza manco sapere cosa c'è dentro.
anche se solamente il timestamp è cifrato?
non può "staccare" il pezzo del timestamp e appenderlo a una richiesta personale?

[morskott]

anche se solamente il timestamp è cifrato?
non può "staccare" il pezzo del timestamp e appenderlo a una richiesta personale?

se cifri solo il timestamp ovviamente un attaccante lo intercetta, blocca la richiesta del client, si costruisce la propria alla quale ci allega il timestamp (valido) preso dal client e lo manda al server, che si vede arrivare una richiesta del tutto legale. Per questo bisogna cifrare tutto il messaggio, dal quale l'attaccante dovrebbe poter estrarre il timestamp, ma per farlo avrebbe bisogno della chiave. Tecnicamente ci sarebbe ancora un problema, se un attaccante intercetta un messaggio e lo blocca senza farlo ricevere al server tutte le richieste successive che il client manderà (che saranno legali) il server vedrà il timestamp sbagliato e le riterra non legali, scombinando l'algoritmo, per ovviare si dovrebbe usare un ack che il server manda al client per ogni messaggio ricevuto corretto contenente il timestamp della richiesta ricevuta. In quesot modo il client saprà esattamente quali messaggi son stati ricevuti e quali no.
Queste cose son un po intricate effettivamente.

[Jak696]

se cifri solo il timestamp ovviamente un attaccante lo intercetta, blocca la richiesta del client, si costruisce la propria alla quale ci allega il timestamp (valido) preso dal client e lo manda al server, che si vede arrivare una richiesta del tutto legale. Per questo bisogna cifrare tutto il messaggio, dal quale l'attaccante dovrebbe poter estrarre il timestamp, ma per farlo avrebbe bisogno della chiave. Tecnicamente ci sarebbe ancora un problema, se un attaccante intercetta un messaggio e lo blocca senza farlo ricevere al server tutte le richieste successive che il client manderà (che saranno legali) il server vedrà il timestamp sbagliato e le riterra non legali, scombinando l'algoritmo, per ovviare si dovrebbe usare un ack che il server manda al client per ogni messaggio ricevuto corretto contenente il timestamp della richiesta ricevuta. In quesot modo il client saprà esattamente quali messaggi son stati ricevuti e quali no.
Queste cose son un po intricate effettivamente.
intricate? abbastanza malate! :muro:

mah, ora una domanda è lecita... jsp/php/asp(.net) si fanno tutte queste pippe mentali o passano semplicemente il sessionid in chiaro?

[morskott]

intricate? abbastanza malate! :muro:

mah, ora una domanda è lecita... jsp/php/asp(.net) si fanno tutte queste pippe mentali o passano semplicemente il sessionid in chiaro?

Bhe, su http tutto in chiaro, su https invece ci si avvale di SSL a cui si delega la parte di cifratura/autenticazione/firma avendo ovviamente un proprio certificato (file rilasciato da un'"autorità" che contiene le tue chiavi private/pubbliche).

[Jak696]

Bhe, su http tutto in chiaro, su https invece ci si avvale di SSL a cui si delega la parte di cifratura/autenticazione/firma avendo ovviamente un proprio certificato (file rilasciato da un'"autorità" che contiene le tue chiavi private/pubbliche).
ho capito... quindi login a parte tutto in chiaro

e il meccanismo dei timestamp/nonce viene usato per le richieste o è solo semplicemente il sid?

[morskott]

Mo non conosco/ricordo nel dettaglio come lavora SSL, gli ingredienti son quelli (SID per la sessione, timestamp, chiavi pubbliche/private), scekerali un po ed ecco SSL :)
Se vuoi maggiori info vedi il sito (http://www.dis.uniroma1.it/~alberto/didattica/critto.html) del corso di crittografia, spiega tutte queste cose.