Il timeout della sessione rende un'app più sicura in un A + HTTPS / chiave di sessione casuale?

Il timeout della sessione può prevenire o mitigare diversi tipi di attacchi. Di seguito vengono in mente.

Workstation non protetta. Boss lascia la scrivania per il pranzo, l'impiegato si siede e si concede un aumento.

Dispositivi condivisi. Donald Trump utilizza un iPad gratuito presso il Resort Mar-a-la-go. Il terrorista è in grado di ottenere iPad in seguito. Ottiene codici nucleari.

Forza bruta. L'attacco FREAK riduce la crittografia SSL / TLS a 512 bit; server farm contenente 1.000 gameplay PS-4 incrina la chiave in poco più di 31 minuti.  Solo i siti con un timeout della sessione di 30 minuti sfuggono alla catastrofe.

Session identifier theft. Odd Job Trojan infetta i browser di tutto il mondo e invia le chiavi di sessione a un hacker situato a Hoboken, nel New Jersey. Hacker ha tutto il tempo del mondo per setacciare le chiavi raccolte e usarle per scopi nefandi. Alcune chiavi non funzioneranno più quando arriverà a loro, quelle con i timeout di sessione.

CSRF. Hacker invia un milione di email con una GIF divertente che si collega a https://www.wellsfargo.com/Transfer.aspx?ToAccount=1234&Amount=100000 . Del milione di destinatari di e-mail, 10.000 li aprono. Di questi, 100 sono ancora registrati in Wellsfargo perché il timeout della sessione è troppo lungo. Hacker ottiene milioni di dollari, si ritira in Costa Rica, dove ora passa il tempo pubblicando su Stack Exchange.

Se non si implementa il timeout della sessione, si è più vulnerabili a tutti i tipi di attacchi sopra indicati. L'uso di una connessione HTTPS e / o l'uso di un identificatore di sessione casualmente graficamente sono passaggi validi e importanti, ma nessuno dei due ha salvato nessuno negli attacchi precedenti.

Solo tu puoi decidere se il rischio degli attacchi di cui sopra è abbastanza importante da compensare l'ulteriore disagio per l'utente finale. Se è solo un'app social, forse no. Se si tratta di un'applicazione bancaria, quasi certamente sì.

C'è un compromesso tra facilità d'uso e sicurezza. Avrai bisogno di fare scelte appropriate in base a come i tuoi utenti interagiscono con il tuo sito e alla tua valutazione delle minacce su cosa accadrebbe se un utente non autorizzato avesse accesso al proprio account (dall'accesso dopo pochi minuti di inattività). / p>

Ad esempio, se l'utente tipico desidera rimanere connesso per diverse ore con lunghi periodi di inattività intercalati in mezzo - ad esempio con un programma webmail, un'applicazione di chat di gruppo (ad esempio, IRC, slack), piattaforma di social media (ad es. , facebook / instagram / twitter), quindi non avrebbe senso costringerli a uscire dopo cinque minuti di inattività. I logout forzati che richiedono ripetutamente l'accesso vanificherebbero gli utenti che migrerebbero ad altre piattaforme.

Il rovescio della medaglia, se sei una banca e gli utenti di solito effettuano l'accesso per fare qualcosa di veloce (ad esempio, controllare un saldo, pagare un conto o trasferire denaro) e raramente rimangono per lunghi periodi di tempo, rende perfetto senso di registrarli dopo alcuni minuti di inattività.

Ha anche senso pensare agli scenari peggiori. Se qualcuno lascia la loro casa mentre è ancora registrato sul proprio conto bancario sul proprio computer, un ladro che si introduce in casa potrebbe potenzialmente trasferire i risparmi di una vita su un conto che controlla. Nel frattempo, se qualcuno lascia la propria casa mentre è ancora registrato nel proprio account di social media, potrebbe essere leggermente imbarazzato (e spiegare che il proprio account è stato violato).

Potrebbero esserci anche scenari in cui la minaccia di un uso non autorizzato è così grande che ogni volta che viene eseguita un'azione deve essere autenticata. Ad esempio, prima di cambiare la password, è sempre necessario che l'utente effettui nuovamente l'autenticazione. O prima di effettuare il checkout del carrello in un e-store (in particolare per i beni digitali che non possono essere restituiti), potresti sempre costringere l'utente ad autenticarsi.

Le banche usano l'autenticazione a 2 fattori. Questo secondo fattore, un token o qualsiasi altra cosa, è diverso da un pasword, non qualcosa che un utente può memorizzare permanentemente nel suo gestore di password. Quindi, è necessario che un utente, dopo un certo periodo di inattività, re-identifichi.

Quando si utilizza solo l'autenticazione con nome utente / password, è molto meno sensato, poiché in genere in questi giorni i browser o gli strumenti esterni memorizzano le credenziali dell'utente di base. Dare fastidio agli utenti con uno schermo che richiede solo loro di inviare un modulo precompilato non aumenta la sicurezza. Non è altro che preoccupare i tuoi utenti finali.

È tuttavia importante che gli ID di sessione non possano essere forzati brute. A meno che non si stia costruendo il proprio schema di autenticazione, i framework dei giorni moderni avranno probabilmente ID di sessione randomizzati che non possono essere indovinati entro settimane di forzatura bruta.