'Ricordo-me' funzione di autenticazione, lo fa sempre media sito web 'non protetto'?

Question

Sto pensando di attuare il classico 'ricorda-me' casella di controllo sul mio webapp per consentire l'utente autenticato di essere 'ricordato' una volta che torna a visitare il mio sito.

Gmail , Facebook e altri hanno questo tipo di funzione, ma io non sono troppo sicuro di come proteggere può essere.

Un quadro Java come usi Primavera di sicurezza un 'Hash-Based approccio token'. Il token che viene generato (con nome utente, password, ExpirationTime e un PrivateKey) è memorizzato nel cookie del Cliente 'token = 567whatever567'. Il token viene poi riutilizzato per ri-autenticare l'utente la prossima volta che torna.

Sono preoccupato del fatto che, anche se il processo di accesso è accaduto sotto una connessione HTTPS, a ogni successiva richiesta HTTP il cookie viene inviato in chiaro sulla rete.

In sostanza tutti in grado di leggere il token e riutilizzarla per l'autenticazione.

Sto cercando di avere uno sguardo a come Gmail o Facebook stanno implementando questa funzionalità. Riesco a vedere un po 'di biscotto come 'presenza = DJ267619445G09H0L15228675 .....' in FB, gli altri in Gmail.
Io non sono troppo sicuro se usano qualche altro trucco per la protezione contro qualcuno che tenta di rappresentare qualche altro utente.

Cercherò di impersonare me stesso utilizzando qualcosa di simile cURL per vedere se sono solo utilizzando uno specifico token per ricordare all'utente.
Se lo sono mi sembra un grosso problema di sicurezza. Forse no facebook (non mi importa di esso), ma con Gmail, se non si imposta ' Usa sempre https ' una connessione HTTP sarà utilizzato e invierà i vostri gettoni in chiaro su internet.
Cosa ne pensi?

Ho anche notato che Facebook campi nome utente / password sono esposti sotto http (non https). A questo proposito mi chiedo anche: Sono tutte le espongono campo username / password su HTTP non protetta 'per natura' siti web. Una volta che la richiesta viene inviata tramite HTTP non c'è 'redirect a https' in grado di risolvere le 'credenziali visibile al mondo' problema.

Grazie

Modifica :
Le mie preoccupazioni erano fondate http://codebutler.com/
Grazie alle Firesheep creatori per evidenziare il problema !!!

Answer 1

Non è un problema del genere per implementare un ricordo-me. Quello che dovete fare è quello di mantenere la sessione in vita per lungo (e impostare il cookie per durare a lungo). Anche Gmail log out dopo un certo periodo (penso che sia due settimane o un mese). Tuttavia, è necessario rendersi conto che mantenere la stessa sessione aperto più a lungo aumenta la possibilità di dirottare in esso. Come contromisura, è necessario aumentare la forza della vostra identificatore di sessione. identificatore di sessione è quello che è nel cookie (o nel URI, come comunemente visto in alcuni software come "file.php? PHPSESSID = 1234 ...").

La chiave è quello di mantenere un forte identificatore di sessione. Per esempio, in Gmail, si dispone di una GX cookie con un valore simile a

DQAAAJoAAAA8mnjaAwgkS7y8Ws5MYCl-PAQLp9ZpMXpGKR47z4L9mlBH-4qEyApAtFbnLkzv1pPqxua1hOWMGiKYpBZr-h7Icyb-NUUg2ZW_nUFIymvw9KjmjSECYTowbCsDerkAxCzSDa83b5YC1mykPv1a9ji4znt6Fsna-AKgNTntvmUxeJ92ctsSlg9iGySEmXnisVyyJiQvI8jzbZqSpE_N2RKZ

Il motivo per cui Session Hijacking è praticamente è impossibile, perché l'identificatore di sessione è così forte, e perché il sito utilizza HTTPS Everywhere. Nessuno può immaginare o comunque ottenere il vostro identificatore di sessione (quindi non può dirottare nella sessione). Su una rapida occhiata, l'identificatore di sessione sopra sembra avere un po '~ 1250-bit di forza, 1 * 10 ^ 376 diverse possibilità. Nessuno può immaginare che.

Ovviamente ci saranno sempre possibili modi per dirottare ancora nella sessione. Ad esempio, le vulnerabilità XSS aprono la strada porta per ottenere i cookie e quindi il vostro identificatore di sessione, ma questo non è colpa tua sessioni in qualsiasi modo, e non ha nulla a che fare con un "ricordo-me".

  

Sono preoccupato del fatto che, anche se il processo di accesso è accaduto sotto una connessione HTTPS, a ogni successiva richiesta HTTP il cookie viene inviato in chiaro sulla rete.

Se si imposta il cookie bandiera sicuro per vero, mentre in HTTPS, il cookie non verrà mai inviata quando si accede al sito tramite HTTP. E 'un must da fare per i siti HTTPS-solo.

In generale, le persone sembrano utilizzare solo HTTPS per il log-in pagina, che è sbagliato. Se uno realmente si preoccupano, si dovrebbe usare HTTPS per tutta la pagina. In caso contrario, è impossibile evitare tutti i tentativi di dirottamento di sessione.

Perché molti usano ancora HTTPS solo per il log-in parte? Probabilmente perché non si rendono conto che cosa è la posta in gioco, o perché è troppo pesante CPU da utilizzare HTTPS Everywhere. Tuttavia, è ancora meglio usare HTTPS per il log-in che non usarlo ovunque - perché di crittografare le credenziali (quindi solo l'identificatore di sessione può essere rubato in seguito, non le credenziali di effettivi durante il log-on)

  

Forse no facebook (non mi interessa di esso), ma con Gmail, se non si imposta 'Usa sempre https' verrà utilizzata una connessione http e invierà i vostri gettoni in chiaro su internet.   Cosa ne pensi?

Credo che il valore dovrebbe di default a HTTPS in tutti i casi, se possibile. L'unica vera ragione per cui non usare HTTPS è denaro (= prestazioni / hardware).

Answer 2

E 'generalmente chiamato un attacco di replay. L'attaccante riproduce una richiesta utilizzando le stesse credenziali (ad esempio cookie) che ha rubato da voi, ed è in grado di impersonare voi. L'attacco XSS è solo una variante di questo, ma è evitabile (per esempio usando HTTPOnly).

L'unico modo per attenuare la maggior parte degli attacchi di riproduzione è HTTPS Everywhere. Questo dovrebbe tenere lontano la maggior parte degli occhi indiscreti.

Ci sono un sacco di tecniche di prevenzione troppo.

Ci sono anche i dispositivi hardware che fanno un lavoro migliore di quanto si possa incidere in software, rallentando il server nel processo, e probabilmente otterrete sbagliato. hardware specializzato in grado di fare un lavoro migliore molto di tracciare le richieste in tempo reale e la determinazione che lo stesso motivo viene utilizzato da molti diversi IP tutto di al tempo stesso, e più veloce di un singolo operatore umano dovrebbe essere in grado di richiesta.

In ASP.NET 2.0 +, quando si usano le forme di autenticazione, è possibile specificare requireSSL='true' per indicare che i browser devono solo inviare il cookie di autenticazione quando una connessione HTTPS è fatta. Vedere questo articolo MSDN per ulteriori informazioni sulla protezione autenticazione basata su form.

---

L'unica ragione per non permettere remember me è se sei un bancaria o un'applicazione simile. Se non siete, basta seguire alcune semplici regole:

1. Se hai remember me, porre scadenza sulla biscotto al massimo 30 giorni nel futuro e non far scivolare il valore. Costringendo l'utente a login una volta al mese, non è poi così male.
2. Le eventuali operazioni sensibili richiede di una password. Durante l'aggiornamento di fatturazione, carte di credito o dettagli dell'account sempre ri-richiesta la password degli utenti. La forma più probabile di abuso è tipicamente tramite lo stesso computer che la persona sta usando, ma assicura anche che anche un cookie di autenticazione rubata su di essa la propria non può fare troppo male. Si può vedere il mio equilibrio, ma non è possibile trasferire qualsiasi cosa.

Answer 3

Sono d'accordo con la maggior parte delle osservazioni di cui sopra. Se siete preoccupati per la sicurezza, si dovrebbe -

a) l'utilizzo di HTTPS in tutto. Anche Gmail recentemente passato a utilizzare HTTPS di default - vedi http : //gmailblog.blogspot.com/2010/01/default-https-access-for-gmail.html

b) Impostare la bandiera sicuro nel vostro cookie di sessione per evitare che il browser di inviarlo tramite una connessione http.

c) XSS Fix nell'applicazione. Se avete problemi di XSS, l'implementazione del 'ricordati di me' sta andando sempre essere non protetta. Vedere OWASP XSS Prevenzione foglietto.

L'indirizzo IP Compresi nel identificatore di sessione non sta per aiuto. Facendo questo renderà il 'Ricorda la funzionalità' praticamente inutile, e non aggiunge molto di sicurezza. So per certo Google non mette gli indirizzi IP nel suo identificatore di sessione.

Answer 4

L'unico modo per fare sito totalmente sicuro è quello di consentire HTTPS Everywhere. Hai ragione, i cookie possono essere annusato e poi utilizzate per rappresentare.

Answer 5

Ci sono un paio di modi di impedendo il dirottamento di sessione , come ad esempio memorizzare l'indirizzo IP del client che ha aperto la sessione. Dati aggiuntivi devono essere conservati sul lato server per verificare le sessioni, anche in assenza di una funzione di login automatico. E 'meglio utilizzare un nonce per il token (o almeno di base su dati non segreta ) piuttosto che il nome utente e la password di hash, come attaccante, concettualmente, potrebbe montare un attacco per trovare le informazioni di autenticazione dato il valore hash.

Se si guarda alla fonte per il Facebook, Gmail e probabilmente le forme d'accesso di altri siti, gli usi form di login di azione HTTPS, che poi reindirizza a una pagina non protetta una volta login riesce.

Answer 6

1 / Quando il controllo utente "ricordati di me": si memorizza un hash di ogni informazioni sul suo computer: IP, il browser, sistema operativo, la lingua ecc ... e scrivere questo hash nei suoi biscotti con il suo ID 2 / quando l'utente è tornato, si calcola il suo nuovo hash. Si confronta questo valore con il valore nel cookie ricevuti, e il valore nel database (per il dato id). se sono tutti uguali, è possibile autenticare l'utente.

E 'chiaro?

HTTPS non ha potuto far nulla se si dispone di un attacco XSS (modo migliore per rubare cookie)