Come implementare in modo sicuro l'accesso automatico

15

Ho letto molti, molti, molti post su come "probabilmente stai memorizzando le password in modo errato". Si riferiscono sempre alla memorizzazione di password su un server in cui un utente sta registrando; sono fondamentalmente consigli di rilegatura (gioco di parole) come assicurarsi di salare le password, ecc. ecc. Tuttavia, non ho mai visto un articolo sulle migliori pratiche per memorizzare le password su un client in modo che il client non deve accedere manualmente ogni volta che vogliono accedere; la funzione "ricordami".

Molti software hanno questa caratteristica, dai browser ai programmi come Dropbox.

Ho letto un vecchio articolo di recente su come Dropbox ha archiviato un ID sul tuo computer che potresti semplicemente copiare / incollare su un altro computer e avviare Dropbox e accedere come dispositivo dal quale hai ottenuto l'ID; nessun accesso, niente e accesso completo all'account Dropbox. Sembra un disegno davvero stupido, ma non riesco a pensare a un modo migliore di farlo.

Non sono nemmeno sicuro su come evitare di memorizzare qualcosa come un cookie in testo normale. Se lo cripti, dove memorizzi la chiave per decodificarlo?

L'unico modo che vedo per non introdurre vulnerabilità di sicurezza è rimuovere la funzionalità di autologin e fare in modo che l'utente digiti la propria password ogni volta che vuole utilizzare un servizio, ma questa è una lotta per l'usabilità e gli utenti sono viziati dall'aspettare di non dover fallo.

Che 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 caratteristiche non presenti su tutte le piattaforme (come il "portachiavi" di cui alcune distribuzioni Linux hanno).

    
posta Jay Simon 05.06.2013 - 10:36
fonte

4 risposte

12

Un modo è:

  • Quando l'utente effettua il login, memorizza un ID di sessione in un cookie sul computer del cliente (non il nome utente o la password).
  • Collega la sessione all'indirizzo IP, quindi un ID di sessione individuale funziona solo con il computer su cui è stato avviato.

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

Si noti che, poiché il protocollo HTTP è stateless in ogni caso, non vi è in realtà alcuna differenza funzionale tra il mantenere qualcuno connesso durante una singola sessione di utilizzo del sito Web e il "login automatico" la prossima volta che usano il sito; è solo una questione di quanto tempo permetti prima che la sessione scada.

Aggiornamento: Inoltre, usa HTTPS per aumentare la sicurezza, ovviamente.

Aggiornamento 2: Si noti che questo approccio presenta limitazioni, 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.

    
risposta data 05.06.2013 - 11:12
fonte
5

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

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

Se hai parti della tua applicazione che non necessitano di una sicurezza elevata, puoi scegliere un modello ibrido in cui archiviare un ID di sessione (con hash o qualsiasi altra cosa se vuoi) per accedere automaticamente agli utenti a porzioni di sicurezza bassa del sito, ma chiedono loro di inserire la password quando entrano in aree di sicurezza più elevate ed eliminano il token di sicurezza alto quando termina la sessione.

Naturalmente, se si tratta di un sito a livello bancario, il login automatico non è un'opzione. Anche in questo caso, i siti che utilizzano questi tipi di sicurezza assumono il valore dei dati che stanno proteggendo e la maggiore praticità per l'utente soppesa 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 sicurezza / compromessi di usabilità sono appropriati per il tuo caso d'uso.

    
risposta data 21.06.2013 - 18:50
fonte
2

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

userID.token

È possibile utilizzare un hash sha1 per il token. Quindi nel tuo userid dell'archivio della tabella del database remember_me_tokens, un hash bcrypt del token e l'ora in cui è stato generato il token.

Quindi, quando qualcuno visita il tuo sito, controlla se il cookie è impostato. Se il cookie è impostato, verifica se esiste una riga valida nel database 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, elimina il cookie.

Esegui un cron job per eliminare remember_me_tokens che sono più vecchi di dire 7 giorni.

    
risposta data 05.06.2013 - 11:04
fonte
0

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

Come indicato nei commenti:

It is about what you trust. If you don't trust the machine store the ID then that is your issue. If you trust the keychain then that is the maximum security you will get. Off course you could add some custom safety like detecting device hardware or something but it's all fake-able so you cannot know in the end. It is out of your control.

    
risposta data 05.06.2013 - 11:21
fonte

Leggi altre domande sui tag