Come implementare in modo sicuro l'auto-login

15

Ho letto molti, molti, molti post su come "probabilmente stai memorizzando le password sbagliate". Si riferiscono sempre alla memorizzazione di password su un server in cui un utente sta effettuando l'accesso; hanno sostanzialmente riformulato consigli onnipresenti (giochi di parole) come assicurarsi di salare le password, ecc. ecc. Tuttavia, non ho mai visto un articolo sulle migliori pratiche per l'archiviazione delle password su un client in modo che il client non debba accedere manualmente ogni volta che vogliono accedere; la funzione "Ricordami".

Molti software hanno questa funzione, dai browser a programmi come Dropbox.

Recentemente ho letto un vecchio articolo su come Dropbox stava memorizzando un ID sul tuo computer che potevi semplicemente copiare / incollare su un altro computer e avviare Dropbox e accedere come dispositivo da cui hai ottenuto l'ID; nessun accesso, niente di nulla e pieno accesso all'account Dropbox. Sembra un design davvero stupido, ma non riesco a pensare a un modo migliore per farlo.

Non sono nemmeno sicuro di come evitare di memorizzare qualcosa come un cookie in testo semplice. Se lo crittografate, dove conservate la chiave per decrittografarla?

L'unico modo in cui vedo di non introdurre vulnerabilità di sicurezza è rimuovere la funzione di accesso automatico e fare in modo che l'utente digiti la password ogni volta che desidera utilizzare un servizio, ma questa è una lotta per l'usabilità e gli utenti hanno l'imbarazzo di aspettarsi di non doverlo fare.

Cosa posso leggere sull'archiviazione locale delle credenziali in modo sicuro per implementare la funzione di accesso automatico? Se i principi sono troppo semplici per un intero articolo, quali sono? Il software in questione non dovrebbe dipendere da funzionalità non presenti su tutte le piattaforme (come il "portachiavi" di alcune distribuzioni di Linux).

security login

— Jay Simon
fonte

2

Riguarda ciò di cui ti fidi. Se non ti fidi dell'ID dell'archivio macchina, questo è il tuo problema. Se ti fidi del portachiavi, questa è la massima sicurezza che otterrai. Ovviamente potresti aggiungere un po 'di sicurezza personalizzata come rilevare l'hardware del dispositivo o qualcosa del genere, ma è tutto falso-quindi non puoi saperlo alla fine. È fuori dal tuo controllo. Ovviamente cose stupide come il salvataggio di password in chiaro sono escluse.

— Luc Franken,

@LucFranken come puoi fidarti della macchina? Qualcuno può sfruttarti come hanno fatto Dropbox. Inoltre mi fiderei del portachiavi ma non tutti i computer ne hanno uno e Windows non lo fa mai (AFAIK). E se stai memorizzando le password, come eviti di memorizzarle in chiaro? Se li crittografate, dove conservate la chiave per decrittografarla?

— Jay Simon,

Questo è esattamente il problema, non puoi fidarti. L'utente può solo definire di fidarsi. Ciò tiene in considerazione che l'utente capisce quanto sia sicura la sua macchina. Scrivere un virus per ottenere dati da Dropbox è possibile. Lo stesso vale per le chiavi archiviate localmente e altri dati locali. Puoi aiutare a renderlo più sicuro (pensa alle app che richiedono un codice di 5 numeri) ma alla fine è locale e fuori dal tuo controllo.

— Luc Franken,

@LucFranken sono solo io o l'autologin sembra una funzione onnipresente? Se lo è, perché le persone non hanno scritto su come farlo nel modo giusto?

— Jay Simon,

È un requisito così comune sebbene alcuni software aziendali non lo consentano. Ad esempio SalesForce consente di salvare solo il nome utente, non la password. Diciamo chiaro tra l'altro. che non è necessario archiviare la password sul client per un accesso. È possibile memorizzare un hash casuale che corrisponde a un hash sul server.

— Luc Franken,

12

Un modo è:

Quando l'utente accede, archivia un ID sessione in un cookie sul computer client (non il nome utente o la password).
Associa la sessione all'indirizzo IP, quindi un singolo ID sessione funziona solo con il computer su cui è stato avviato.

A seconda del framework utilizzato per sviluppare il tuo sito, questo comportamento potrebbe essere disponibile come funzionalità integrata.

Si noti che, poiché il protocollo HTTP è comunque apolide, in realtà non vi è alcuna differenza funzionale tra mantenere qualcuno connesso durante una singola sessione di utilizzo del sito Web e "auto-login" al successivo utilizzo del sito; è solo una questione di quanto tempo concedi prima della scadenza della sessione.

Aggiornamento: inoltre, utilizzare HTTPS per una maggiore sicurezza, ovviamente.

Aggiornamento 2: Notare che questo approccio ha dei limiti, in quanto non funziona bene per gli utenti che cambiano molto il loro indirizzo IP. Tuttavia, fornisce un maggiore livello di sicurezza e può essere utile in alcune situazioni.

1

Associarlo a un indirizzo IP non aiuta molto perché qualcuno potrebbe avere un computer dietro lo stesso firewall di te.

— Jay Simon,

2

@JaySimon, non direi "non aiuta molto". Il numero di computer dietro lo stesso firewall è notevolmente inferiore al numero di computer nel mondo. Si tratta di limitare la tua potenziale esposizione agli attacchi e questo lo limita notevolmente. Questo è un approccio standard e non credo davvero che ci sia molto altro da fare oltre. Se qualcuno ha lo stesso indirizzo IP dell'utente e riesce a ottenere un ID di sessione, quella persona sarà indistinguibile dall'utente dal punto di vista del server. Se hai qualsiasi tipo di accesso al tuo sito, sei esposto a tale attacco.

3

Pensi che un tale approccio sarà fastidioso per gli utenti di telefoni cellulari che l'indirizzo IP può cambiare spesso?

— Jay Simon,

@JaySimon, se accadesse all'interno di una sessione l'utente lo sperimenterebbe come un logout improvviso, il che sarebbe sicuramente fastidioso. Tuttavia, non so quanto spesso cambino effettivamente (una rapida ricerca su Google non rivela una risposta definitiva). Non sarei troppo preoccupato per questo a meno che l'IP non potesse cambiare mentre lo stavano effettivamente usando.

Limitare la sessione all'IP non è davvero realistico, come detto. Gli utenti cambiano spesso posizione. Con telefoni cellulari ma anche con computer portatili; ad esempio il lavoro flessibile. Il meglio che puoi fare è che alcuni controlli GeoIP si combinano con il tempo per percorrere quella distanza; come fa Gmail.

— Lode

5

Amazon (e molti altri) usano un approccio ibrido. Forniscono autologin per la navigazione, l'aggiunta di articoli al carrello e l'inoltro di ordini utilizzando combinazioni di indirizzi di spedizione / assistenza di credito utilizzate in precedenza. Tuttavia, richiedono l'inserimento della password per molte azioni come l'aggiunta di carte di credito, l'aggiunta / modifica degli indirizzi di spedizione, l'aggiornamento delle password, la visualizzazione degli ordini passati (facoltativamente per l'utente) e molte altre impostazioni dell'account.

Quindi sì, le persone che ottengono l'accesso al tuo computer potrebbero dirottare la tua sessione, ma ottieni comunque ciò che ordinano! (Ancora più importante, l'incentivo a dirottare una sessione è praticamente negato.) Ma se qualcuno ha accesso al mio computer, ho problemi più grandi rispetto alle persone che rubano le sessioni medie del sito.

Se hai parti della tua applicazione che non necessitano di un livello di sicurezza elevato, puoi scegliere un modello ibrido in cui archiviare un ID sessione (con hash o qualsiasi altra cosa desideri) per accedere automaticamente agli utenti in parti a bassa sicurezza del sito , ma è necessario che inseriscano la password quando si accede alle aree di sicurezza superiore ed eliminano il token di sicurezza elevata al termine della sessione.

Naturalmente se si tratta di un sito di livello bancario, l'accesso automatico non è un'opzione. Ancora una volta, i siti che utilizzano questi tipi di sicurezza assumono il valore dei dati che stanno proteggendo e la maggiore praticità per l'utente sopporta il potenziale rischio di una sessione compromessa. Se ritieni che non sia il caso della tua applicazione, non implementare gli accessi automatici. Devi accedere a quale livello di compromessi di sicurezza / usabilità sono appropriati per il tuo caso d'uso.

— Eric G
fonte

2

In realtà non è così difficile. Prima memorizza un cookie con questo formato:

userID.token

Puoi usare un hash sha1 per il token. Quindi, nella tabella del database remember_me_tokens, archiviare userID, un hash bcrypt del token e l'ora in cui il token è stato generato.

Quindi quando qualcuno visita il tuo sito, controlla se il cookie è impostato. Se il cookie è impostato, verifica se nel database è presente una riga valida negli ultimi 7 giorni. Se nel database è presente una riga valida per il cookie, impostare la sessione per indicare che l'utente ha effettuato l'accesso ed eliminare anche la riga corrispondente del cookie / database e generare una nuova riga cookie / token / database.

Se si disconnettono quindi eliminare il cookie.

Esegui un processo cron per potare remember_me_tokens che sono più vecchi di dire 7 giorni.

— Ryan
fonte

Cosa impedisce a qualcuno di copiare questa chiave, incollarla sul proprio computer e ottenere l'accesso all'account senza nome utente o password?

— Jay Simon,

come hai intenzione di ottenere la chiave? è memorizzato localmente sul computer di qualcuno.

— Ryan,

ti avvicini al computer e apri il file in cui è memorizzato :)

— Jay Simon,

2

@JaySimon Questo stesso argomento può essere fatto per qualcuno che accede e se ne va per 5 minuti senza bloccare il proprio computer, oppure fa clic su Remember Me e qualcuno salta sulla password del proprio account. Se puoi accettare questa possibile situazione di sicurezza, la praticità è buona, ma è per questo che non vedi una funzione Ricordami nell'elenco NIA CIA :) Il server deve fornirti un tipo di token che il client deve archiviare sul filesystem. Tuttavia, non è più nelle tue mani dal punto di vista del server.

— maple_shaft

@maple_shaft perché qualcuno si è sorpreso che tu potessi farlo su Dropbox allora? (L'ho collegato alla mia domanda.)

— Jay Simon

0

Puoi solo se ti fidi del dispositivo in cui lo memorizzi. Spetta all'utente (se non è possibile influenzare il dispositivo) quanto sia sicuro. È semplicemente fuori dalle tue mani.

Come indicato nei commenti:

Riguarda ciò di cui ti fidi. Se non ti fidi dell'ID dell'archivio macchina, questo è il tuo problema. Se ti fidi del portachiavi, questa è la massima sicurezza che otterrai. Ovviamente potresti aggiungere un po 'di sicurezza personalizzata come rilevare l'hardware del dispositivo o qualcosa del genere, ma è tutto falso-quindi non puoi saperlo alla fine. È fuori dal tuo controllo.

— Luc Franken
fonte