Non sono registrati in modo permanente account intrinsecamente insicuri?

Un buon identificatore (lungo, strong) è molto più difficile da indovinare di una password tipica. Questo è abbastanza sicuro.

Il trucco qui è usare l'autenticazione "multi-fattore".

Il cookie, più l'indirizzo IP, più qualsiasi altra informazione nell'intestazione HTTP fornisce una certa "continuità" dell'utente. La lingua di accettazione e il programma utente, ad esempio, non cambiano molto se si utilizza sempre lo stesso computer dalla stessa posizione.

Un piccolo JavaScript può restituire le informazioni di window.screen , che, analogamente, non dovrebbero cambiare molto spesso.

Sì, può essere falsificato. Ma la maggior parte delle volte, un cookie rubato si verifica anche su un indirizzo IP imprevisto con un valore di intestazione HTTP imprevisto nella richiesta.

Qualsiasi dubbio sulle altre intestazioni indica che il cookie è dubbio e deve essere fornita una sfida.

Anche il trucco fa sì che "alla fine" vada oltre la durata prevista dell'Universo. È piuttosto facile a causa di esponenziali: basta usare un cookie abbastanza lungo. Ogni bit aggiunto raddoppia il numero di possibili valori del cookie.

Ad esempio, supponiamo di avere 16 miliardi di utenti (ad esempio, ogni essere umano, compresi i bambini, crea due o tre account). Si tratta di 2 account ³⁴ . Usa i cookie a 160-bit (20 byte, niente da invadere per un cookie). Questo è 2 ¹⁶⁰ possibili valori del cookie, quindi un solo valore del cookie sempre 2 ¹²⁶ è collegato a un account esistente. Ora, il nostro aggressore è davvero motivato e proverà un miliardo valori al secondo (che è davvero grande perché "provare un valore del cookie" significa connettersi al tuo server, quindi presumiamo che il tuo server sia sufficientemente kick-ass gestire un miliardo di connessioni al secondo - presumibilmente se lo potessi permettere, se tutta l'umanità è il tuo cliente). Un miliardo è di circa 2 ³⁰ , quindi l'aggressore dovrà, in media, provare per circa 2 ⁹⁶ secondi prima di colpire un valore di cookie valido. "2 ⁹⁶ seconds" è una quantità di tempo nota anche come "circa 2500 miliardi di miliardi di anni": quell'attaccante è sicuramente paziente e dedicato.

Quindi questo non è un problema nella pratica: pochi altri byte e attaccanti sono ostacolati da numeri puri. Non è necessario implementare funzionalità di blocco (soprattutto perché le funzionalità di blocco possono a volte ritorcersi contro colpire i clienti onesti afflitti da qualsiasi tipo di bug del browser di cui non eri a conoscenza, o qualcosa di brutto come quello). Ovviamente ciò presuppone che i valori dei cookie siano generati con un generatore di numeri casuali abbastanza strong; pensa CryptGenRandom () su Windows, /dev/urandom su Linux / * BSD / Solaris, java.security.SecureRandom con Java.

(Il bit sulla vita dell'Universo è vero solo se l'ipotesi Big Crunch è vera e non c'è Dio [perché anche l'eternità è troppo lunga]).

La cosa più importante è proteggere la connessione con TLS / SSL. Senza di esso, sei vulnerabile ad attacchi come FireSheep, come documentato su Puoi proteggere un'app Web da FireSheep senza usare SSL? .

A quel punto entrano in gioco altri grossi rischi, come qualcuno che compromette la macchina che ha effettuato l'accesso o che ha accesso fisico ad essa.

Tornando alla domanda sulla quantità di entropia nel cookie, come altri hanno notato, non è difficile ottenere un cookie abbastanza lungo e abbastanza casuale. Vedi anche Quanto dovrebbe durare un nonce casuale? - Sicurezza IT - Stack Exchange

Un altro problema che non è stato ancora sollevato, e questo ha più a che fare con la domanda intitolata (account con accesso permanente), e meno con il cookie di sessione:

Gli account con accesso permanente forniscono al potenziale aggressore una finestra di attacco molto più grande.
Se l'attaccante riesce a in qualche modo a rubare il tuo cookie (es. FireSheep, accesso alla tua macchina, ecc.), Quindi sarà valido a tempo indeterminato, e quindi renderà più probabile l'uso improprio di un cookie rubato.
Inoltre, se qualcuno ottiene l'accesso alla tua macchina client in futuro, ad es. desktop condivisi, laptop presi in prestito (o rubati), Internet cafè - sei ancora loggato.

Detto questo, si tratta di un compromesso, che spesso ha senso per gli utenti, a seconda del contesto dell'applicazione. Ad esempio, voglio rimanere connesso al mio gmail (e ai siti SE), ma non alla mia banca.
D'altro canto, proteggere i cookie da eventuali furti (SSL, non accedere su un computer pubblico, disconnettersi quando hai finito, ecc.) È sempre una buona idea.

Ci sono alcuni motivi per cui non dovresti preoccuparti troppo di questo tipo di attacco come descritto di seguito:

• Dimensione - Con un nonce abbastanza grande, presumibilmente parte del valore del cookie, diventerà proibitivo (tempo e hardware saggio) generare un valore corrispondente a un cookie attualmente valido. Sto anche assumendo che tutte le variabili aggiuntive incluse nel processo di generazione dei cookie siano note all'attore, solo per essere belle.
• Limitazioni degli endpoint - Il server che gestisce le connessioni di rete sul tuo terminale sarà probabilmente un collo di bottiglia incredibile se si considera la quantità di connessioni di rete necessarie per ottenere un ragionevole throughput di ipotesi al secondo (Si consideri l'intervallo di potenziali valori dei cookie!).
• Larghezza di banda della rete - Anche supponendo che tu abbia accesso a una mostruosa macchina infernale di un server, l'attaccante sarà limitato dalla larghezza di banda disponibile per effettuare l'attacco.

Supponendo che l'obiettivo di un utente malintenzionato sia quello di impersonare un utente, direi che è molto più probabile che proverà a rubare i cookie dagli utenti ignari.

Sì, ti stai preoccupando di nulla.

Prima di tutto, dovresti usare una chiave abbastanza grande in modo che non possa essere semplicemente indovinata provando tutte le combinazioni. Ad esempio, se SHA1 cripta il nome di accesso, la password e alcune altre informazioni, impiegherà più tempo l'età dell'universo a indovinare una combinazione corretta, anche se fosse possibile tentare un miliardo di combinazioni al secondo.

Ovviamente, è più rischioso, ma la sicurezza consiste nel valutare il rischio rispetto alla ricompensa (nel caso, l'usabilità).

È molto più probabile che tu faccia un altro errore di base, come non forzare l'uso di HTTPS ovunque, piuttosto che avere un problema con il cookie.