Abbiamo recentemente sviluppato alcune funzionalità per la nostra app Web per consentire a un utente di rimanere connesso a tempo indeterminato, e sono interessati a conoscere le implicazioni sulla sicurezza di farlo. L'obiettivo era prevenire la perdita dei dati degli utenti se impiegavano troppo tempo per modificare una pagina, in precedenza dovevano copiare / incollare negli appunti una volta scaduta la sessione, poiché i POST venivano bloccati e l'accesso veniva gestito su una schermata diversa .
Quindi, ora rileviamo se una sessione utente è prossima alla scadenza e quindi li presenta con una modale che consente loro di fare clic su un pulsante per mantenere viva la sessione. Se ignorano questa modal di avviso per un periodo abbastanza lungo, la sostituiamo con una modal "log-in" appena la loro sessione scade.
Il primo meccanismo di avviso / modal funziona tramite una chiamata AJAX al server che restituisce il tempo fino alla disconnessione. Se il tempo è inferiore a 15 minuti apriamo il modal "Keep me logged in" che ha due opzioni: disconnettimi ora o resta loggato. Disconnettiti fa l'ovvio, rimanendo loggato, un altro AJAX arriva al server di nuovo aggiorna i cookie di autenticazione dell'utente.
Il secondo modal è più complicato - il modale blocca ulteriormente l'interazione con la pagina e viene rimosso solo dopo il rientro corretto della password. Siamo consapevoli che una modale non proteggerà veramente i dati di lettura dalla pagina, ma questa è la natura del requisito.
I dati richiesti all'utente per il nuovo accesso (come nome utente e ruolo precedente) sono memorizzati in testo normale nei campi di input nascosti all'interno del modale. Abbiamo preso in considerazione l'hashing, ma non sembrava necessario: il nome utente non è particolarmente critico e il ruolo richiesto viene rivalutato al nuovo accesso; non è possibile eseguire l'upgrade a un ruolo a cui non si ha accesso se si è tentato di "regolare" il POST.
Lo scenario peggiore che abbiamo considerato è che qualcuno modifica il POST con un nome utente / password diverso ma valido e accede come qualcun altro rimanendo sulla pagina. Sarebbero in grado di leggere la pagina ma possono farlo comunque: la navigazione in uscita li riporterà agli schermi corretti per il "nuovo" login. Probabilmente abbiamo bisogno di un po 'di lavoro per garantire che tutti i POST siano bloccati in questo scenario, ma c'è qualcos'altro da considerare? C'è qualcosa da guadagnare costringendo l'utente a ri-identificare digitando di nuovo manualmente il proprio nome utente?
L'app Web è ASP.NET MVC3.
Aggiorna
Grazie per il feedback finora.
Abbiamo accettato di non fidarsi dei dati del client, quindi abbiamo deciso di crittografare il nome utente e il ruolo insieme e quindi lo decodifichiamo al tentativo di accesso. Da allora abbiamo scoperto che, a causa delle protezioni AntiForgeryToken che abbiamo già in vigore se un altro utente doveva effettuare il login, qualsiasi azione post non avrebbe avuto esito positivo.
Non riteniamo che ci sarà un grosso problema di usabilità con il popup poiché il timeout è attualmente impostato su 60 minuti con un avviso di 15 minuti. Abbiamo già preso in considerazione la scadenza di scorrimento non aggiornata fino a metà strada (http://msdn.microsoft.com/en-us/library/system.web.configuration.formsauthenticationconfiguration.slidingexpiration.aspx). È importante ricordare che tutto questo è stato implementato per affrontare i reclami degli utenti sulla perdita di dati - inseriscono una grande quantità di testo sul nostro sistema che può richiedere molto tempo e ha un'alta probabilità che la sessione vada in stallo prima che siano finiti.
Un'altra funzione da aggiungere in un secondo momento sarebbe gestire un utente che modifica i campi di input e invia un heartbeat al server (a meno che non siano già non autenticati). Non abbiamo ancora deciso come gestire questo evento o per attivare l'heartbeat in modo che non spari ogni keypress. Una volta che questo è a posto la finestra di dialogo di avviso di timeout dovrebbe mostrare meno spesso.
Qualcos'altro che vale la pena menzionare è che l'intero sito è HTTPS e usiamo ASP.Net AntiForgeryToken che sono HttpOnly Cookie contrassegnati come sicuri.
Se qualcuno ha ulteriori commenti o suggerimenti sarebbe bello sentirti.