È sicuro archiviare le password nei cookie?

La pagina iniziale della mia applicazione Web ha una casella di controllo RememberMe . Se l’utente lo controlla, io memorizzerò l’e-mail e la password nei cookie. Questo è il mio codice:

if (this.ChkRememberme != null && this.ChkRememberme.Checked == true) { HttpCookie cookie = new HttpCookie(TxtUserName.Text, TxtPassword.Text); cookie.Expires.AddYears(1); Response.Cookies.Add(cookie); } 

Quello che voglio sapere è:

  • È sicuro archiviare le password nei cookie?
  • Qual è il modo corretto di fare lo stesso?
  • Quali sono le migliori pratiche nell’impostazione del tempo per un cookie?

NON è sicuro memorizzare le password nei cookie perché sono disponibili come testo normale.

Un buon posto per trovare alcune risposte sui cookie è Cookie Central. Per l’appartenenza di solito viene utilizzato un cookie con una lunga stringa chiamata “token” che viene emessa dal sito Web quando si forniscono il nome utente e la password. Maggiori informazioni sul processo che puoi trovare in questo articolo . Quando si utilizza l’autenticazione basata su form in ASP.NET, è ansible impostare il cookie di autenticazione in questo modo:

 FormsAuthentication.SetAuthCookie(userName, isPersistanceCookie); 

Il secondo parametro è usato per la funzionalità “Ricordami” – se vero creerà i cookie permanenti che dureranno dopo che avrai lasciato il sito. Puoi anche manipolare in modo programmatico il cookie in questo modo:

 HttpCookie authCookie = HttpContext.Current.Request.Cookies[FormsAuthentication.FormsCookieName]; 

No! Non memorizzare le password nei cookie!

In ASP.NET, utilizzare

 FormsAuthentication.SetAuthCookie(username, true); 

Il valore del secondo argomento determina se il cookie è persistente (il valore della casella di controllo Ricordami).

No, non remotamente sicuro. Non si ha alcuna garanzia che i cookie non vengano archiviati in formato testo (e infatti la maggior parte delle implementazioni li memorizza come testo normale).

Intendiamoci, “ricordati di me” è intrinsecamente insicuro, in quanto chiunque intercetta il cookie ottiene l’accesso all’applicazione. Ma esporre la password di un utente fa un passo in più nella scala di insicurezza. 🙂 E probabilmente rende l’utente davvero pazzo, se lo scoprono.

Uso una stringa di cookie crittografata che incorpora il nome dell’account dell’utente combinato con un token che non è in nessun altro modo associato all’account dell’utente, tranne in una tabella sul mio server. Quando l’utente torna al sito, decifriamo il cookie e cerchiamo se quel token sia effettivamente associato a quell’account. Il token (e quindi il cookie) modifica ogni accesso automatico e invalida quello utilizzato per quell’accesso automatico. (Esiste una relazione molti a uno tra i token e l’account, per consentire l’accesso automatico da più posizioni. Si può limitare se lo si desidera.) I token scadono se non vengono utilizzati entro X giorni. (Questo non è fatto solo limitando la durata del cookie, ma anche dal lato server.) Ci sono alcune altre cose che lancio lì per rendere la vita un po ‘ difficile per qualcuno che cerca di decodificare il cookie (dopo aver decrittografato con successo it) o ​​utilizzare un cookie rubato (che non richiede la decrittografia), ma non ha senso andare in overkill (di nuovo, “ricordami” è intrinsecamente insicuro).

Lo uso in un sito in cui la sicurezza robusta non è realmente necessaria (ovviamente) e che ha un numero elevato di client IP dinamici, quindi non provo a bloccarlo su un IP. Ma persino bloccarlo su un IP non lo rende sicuro, riduce solo leggermente la superficie di attacco.

Ci si potrebbe chiedere perché ho il nome utente nel cookie. Per gli scopi “ricordami” direttamente, non ti consiglio di averlo lì, anche se è crittografato (dopotutto, è la metà della coppia di autenticazione in un nome utente + sistema di password). Sono stato un po ‘sorpreso di trovarlo nel nostro cookie quando ho guardato il formato quando mi ricordo come lo abbiamo fatto per questa domanda; ma poi ho visto i commenti che spiegano perché è lì e ci sono ragioni non correlate a “ricordami” (non necessariamente ragioni persuasive , a ben vedere, ma ragioni).

Una nota finale, il fatto che “ricordami” sia intrinsecamente insicuro è una delle molte ragioni per cui i registri dei siti sono molto importanti e perché è necessario richiedere la reverifica della password nel processo di consentire modifiche a informazioni importanti sull’account (per renderlo più difficile qualcuno che ha rubato il cookie per diventare proprietario dell’account).

Questo è quello che non dovresti mai fare, perché è molto facile cambiare il valore di un cookie e inviarlo al server. Anche la memorizzazione di “utente ingannato come ‘ingenuo'” in un cookie è sbagliato, perché potrei quindi cambiarlo in “utente registrato come ‘Pandiya Chendur'”.

Quello che puoi fare nei cookie è dare informazioni ai clienti che, anche se modificati, non hanno senso per il server. Ad esempio, il colore preferito, il layout della prima pagina e così via.

Puoi dare loro l’ID di sessione che è memorizzato in un cookie, perché non possono migliorare nulla per se stessi, se cambiano il valore in qualcos’altro (a meno che non conoscano un ID di sessione valido da un’altra sessione).

Cosa dice MSDN di Microsoft sull’utilizzo dei cookie :

I problemi di sicurezza con i cookie sono simili a quelli di ottenere dati dal client. Nella tua applicazione, i cookie sono un’altra forma di input da parte dell’utente e sono quindi soggetti a esame e spoofing. Un utente può come minimo vedere i dati che si memorizzano in un cookie, poiché il cookie è disponibile sul proprio computer dell’utente. L’utente può anche modificare il cookie prima che il browser lo invii.

Non si dovrebbero mai memorizzare dati sensibili in un cookie, come nomi utente, password, numeri di carte di credito e così via. Non mettere nulla in un cookie che non dovrebbe essere nelle mani di un utente o di qualcuno che potrebbe in qualche modo rubare il cookie.

Allo stesso modo, sii diffidente delle informazioni che esci da un cookie. Non dare per scontato che i dati siano gli stessi di quando li hai scritti; utilizzare le stesse misure di sicurezza nel lavoro con i valori dei cookie che si farebbe con i dati che un utente ha digitato in una pagina Web. Gli esempi precedenti in questo argomento hanno mostrato la codifica HTML del contenuto di un cookie prima di visualizzare il valore in una pagina, come si farebbe prima di visualizzare qualsiasi informazione ottenuta dagli utenti.

I cookie vengono inviati tra browser e server come testo normale e chiunque possa intercettare il traffico Web può leggere il cookie. È ansible impostare una proprietà cookie che fa sì che il cookie venga trasmesso solo se la connessione utilizza Secure Sockets Layer (SSL). SSL non protegge il cookie dall’essere letto o manipolato mentre si trova sul computer dell’utente, ma impedisce che il cookie venga letto mentre è in transito perché il cookie è crittografato. Per ulteriori informazioni, vedere Pratiche di sicurezza di base per le applicazioni Web.

Non è sicuro memorizzare le password nei cookie perché sono disponibili come testo normale. ma se i tuoi criteri preferiti è quello di farlo o qualsiasi requisito dell’utente è lì puoi farlo crittografando le stringhe. questo può renderlo abbastanza sicuro.

ma non è raccomandato,

Penso che sia necessario creare un token con nome utente e una stringa di autenticazione crittografata che si ottiene da Windows Identity. Non è necessario memorizzare la password sui cookie. Abbiamo la nostra applicazione che memorizza il nome utente e la stringa autenticata

Btw, le password degli store non sono sicure ovunque, sia lato client che lato server.

Non hai bisogno di farlo.

Cosa disse Branislav e …

Oltre a non inserire dati sensibili nei tuoi cookie, devi proteggerli inserendo almeno quanto segue nel tuo web.config:

  

Per maggiori dettagli vedi: Come si configura esattamente httpOnlyCookies in ASP.NET?

Non è affatto sicuro. I cookie sono memorizzati nel computer client, che può essere manomesso.

  • Se si utilizza SSL che si dovrebbe se si sta trasmettendo qualsiasi informazione sicura, che elimina una terza parte dall’ascolto del traffico web. Questo sarebbe lo stesso problema indipendentemente dall’archiviazione di credenziali di un utente in un cookie perché quando effettuano l’accesso inviano il proprio nome utente e password al server in ogni caso, dove presumo che il server lo hashing e lo confronta con la password hash che si ha per quell’utente.

  • Altri domini non saranno mai in grado di leggere il tuo cookie a causa del cross-origine, quindi non è un problema.

  • Quindi è davvero l’unico “buco di sicurezza” se vuoi chiamarlo così se qualcuno guadagna fisicamente l’accesso al proprio computer. Se ciò accade, molto probabilmente otterranno comunque le informazioni che vogliono da quella persona. Come spieghi quando chrome auto compila i moduli di accesso per te, è sicuro? Sono sicuro che non lo stiano salvando in testo normale, ma questo non ha importanza. Se vai a una pagina con i riempimenti automatici di Chrome, puoi semplicemente copiare la password dal modulo e verificare che ora hai la password di quella persona.

  • Si tratta davvero di quanto “sicuro” sia necessario. Sono d’accordo che crittografare le informazioni degli utenti con una scadenza come token è il modo migliore per autenticare le chiamate di servizio e fornisce flessibilità. Non vedo il problema con l’archiviazione delle credenziali di accesso in un cookie.