Domanda sul foglio SessionLock

Question

Domanda sul foglio SessionLock

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

4

Qualche tempo fa c'era un grande fuzz su Firesheep: ascoltando il traffico wifi si può rubare la tua sessione di login, il che è molto brutto perché ora qualcuno può ad es. invia e-mail per tuo conto. Alcuni hanno affermato che l'utilizzo di SSL per l'intero sito era l'unica soluzione. Ma non pensavo che fosse vero: se riesci a mantenere la password o l'equivalente memorizzata sul lato client, e non lo invii mai al server, ma piuttosto autentichi ogni richiesta che fai con questa password, nessuno può impersonare te (a meno che loro conoscono la tua password). Ad esempio quando fai una richiesta HTTP req , invece fai la richiesta r + "?hmac=HMAC(password, req)" per provare che conosci la password.

Poi ho trovato un documento su un protocollo chiamato SessionLock , che è mirato a risolvere lo stesso problema. È un po 'diverso da quello che ho descritto sopra, e ho alcune domande a riguardo.

Innanzitutto, perché stabiliscono un segreto condiviso su SSL o utilizzando il protocollo Diffie-Hellman, quando esiste già un segreto condiviso disponibile (la password o una versione hash della password)?

In secondo luogo, riguardo alla versione che usa Diffie-Hellman si dice:

If the browser loses its secret, it can re-perform a Diffie-Hellman key exchange with the server, using a number of XMLHttpRequest calls.

Qualcuno può spiegare come funziona? Presumibilmente il lato client non ha salvato la password, e ha anche perso il segreto condiviso. Quindi, per quanto posso vedere, il lato client non sa nulla, eppure è in grado di ristabilire un segreto condiviso che può essere usato per fare cose autenticate. Un attaccante non sarebbe in grado di fare esattamente la stessa cosa? Cosa mi manca?

authentication cryptography key-management tls

posta Jules Jacobs 18.04.2011 - 16:53

fonte

2 risposte

2

Diffie-Hellman è sufficiente per stabilire un segreto condiviso dal nulla se non sei preoccupato per gli attacchi attivi e, secondo il giornale, non pretendono di difendersi da questi. Quindi sei corretto, l'attaccante può fare lo stesso, ma solo con un attacco attivo, non semplicemente ascoltando di nascosto.

In ogni caso, il protocollo è vulnerabile agli attacchi attivi, a parte questo, mi sembra (ad esempio, il motore del client viene pubblicato usando JavaScript, che non è autenticato, quindi è possibile introdurre il proprio codice e sovvertire l'intera cosa ).

Per quanto riguarda l'altra parte della tua domanda, perché accetti un nuovo segreto quando ne hai già uno, è generalmente consigliabile evitare di usare una password direttamente come chiave, se puoi, poiché è probabile che sia vulnerabile al dizionario e attacchi di forza bruta. Tuttavia, in questo caso, probabilmente l'hanno fatto in questo modo perché un attaccante attivo può rubare il segreto (anche se mi sembra che possano ancora a causa del problema JS che ho menzionato sopra).

risposta data 25.04.2011 - 09:41

fonte

Leggi altre domande sui tag authentication cryptography key-management tls

I siti web possono tracciare le schede che apri mentre sei loggato nel loro sito web? Che cosa significano dati di testo cifrato identici nella modalità cifratura dei blocchi di concatenazione (CBC)?

score 3 · Accepted Answer

Tecnicamente, è possibile utilizzare la password come segreto condiviso in SessionLock, ma il sito Web deve memorizzare la password in chiaro. Quindi, come suggerisci, potresti utilizzare l'hash della password, ma l'hash della password diventa improvvisamente quasi altrettanto valido della password stessa, poiché è sufficiente configurare una sessione protetta con il server. Questa è una buona ragione per non usare l'hash della password.

Ma soprattutto, il mio obiettivo di progettazione, in SessionLock, era quello di non impigliare il metodo di autenticazione con la sicurezza della sessione. Che dire prima di aver effettuato l'accesso? Non voglio ancora che qualcuno rubi la mia sessione. E che dire dei sistemi che usano l'autenticazione HTTP o qualche altra astrazione di memorizzazione e verifica delle password che generalmente rende difficile per il codice della tua web app ottenere i dati della password, anche il suo hash? Oppure un sito Web più grande in cui l'accesso avviene a login.*.com , quindi viene impostato un cookie di sessione e il gioco è fatto, i vari service1.*.com , service2.*.com non hanno la password effettiva.

Per tutti questi piccoli motivi, SessionLock non lega direttamente il suo segreto condiviso alle credenziali.

E come menzionato da altri commentatori, fai attenzione. SessionLock impedisce solo agli attaccanti di rete passivi di rubare la tua sessione. Il carico utile è ancora leggibile dagli intercettatori e sei sfortunato contro gli attaccanti di rete attivi.