Accesso persistente tramite cookie e variables di session

Ho cercato i modi migliori (e più sicuri) per implementare accessi persistenti sul mio sito web, e ho scoperto quanto segue:

Quando un utente effettua l'accesso, viene creato un cookie contenente l'ID utente / nome utente e un numero generato a caso (token). Il token è memorizzato in una tabella relazionale insieme all'ID utente / nome utente. Ogni volta che viene caricata una pagina riservata ai membri, questo cookie viene verificato rispetto alla tabella relazionale e, se esiste e corrisponde al token, il login è valido e la pagina può essere caricata. In caso contrario, tuttavia, il login non è valido, il cookie viene distrutto e all'utente viene richiesto di accedere.

Stavo pensando … di salvare l'accesso al database each volta che una pagina viene caricata, potrei anche avere una variabile di session che dura, per esempio, 10 minuti, e viene distrutta automaticamente quando il browser si chiude. Se la session è triggers, viene aggiornata e l'utente può procedere. Se la session scade, ma il cookie è ancora valido, controlla il cookie, reimposta il token, memorizza il nuovo token nel database (eliminando il vecchio token o memorizzandolo in una tabella di archivi per riferimento futuro) e reimposta il cookie utilizzando il nuovo valore del token.

Tuttavia, cosa conteneva la session? E come potrebbe la session non essere falsificata semplicemente con qualche JavaScript? Forse la session contiene un hash crittografato unidirezionale? Cosa verrebbe utilizzato per generare quell'hash (ID utente, ecc.)?

Sono un po 'bloccato su where andare da qui. Ottengo i cookie, ma l'uso di sessioni temporanee (per evitare chiamate ripetute al database each volta che viene caricata una pagina) mi sfugge. Qualsiasi aiuto? Grazie.

I cookie dovrebbero andare bene (un'alternativa potrebbe essere memorizzarla nell'intestazione HTTP), tuttavia non vedo la necessità di memorizzare il nome utente / l'ID nel cookie. Il token stesso dovrebbe essere sufficiente. È ansible utilizzare un UUID come token. Memorizzalo insieme al nome utente e a last_access_timestamp nella tabella del database. E invia solo il token (in un cookie o nell'intestazione della richiesta HTTP) ad each richiesta. Questo è sufficiente per implementare le sessioni secondo me.

Un token viene generato su un login di successo di un utente, memorizzato nel database e passato all'utente. Ogni volta che un utente accede alla pagina Web, il token viene passato nella richiesta e viene validationto. Se valido, last_acces_timestamp viene aggiornato e l'utente può procedere. La ricerca nella validation verrà effettuata da token e con il nome utente è ansible eseguire l'authentication e l'authorization. Se il token non è valido o è scaduto, inoltrare l'utente a una pagina di accesso.

L'eliminazione delle sessioni scadute dal db può essere eseguita periodicamente utilizzando un process cron o durante la creazione di una nuova session.

Per ragioni di performance, potresti pensare di memorizzare la session in una hashmap in memory. Dal momento che potrebbe essere costoso aggiornare sempre il database.

Pensa anche all'utilizzo di HTTPS, per impedire alle persone di sniffare il token.

Ho risolto questo modo nel modo seguente, alcuni mesi fa: https://stackoverflow.com/questions/12829994/java-custom-session-implementation-expired-sessions

L'utilizzo di UUID non è raccomandato in base alla RFC 4122 , si afferma che

Non dare per scontato che gli UUID siano difficili da indovinare; non dovrebbero essere usati come funzionalità di sicurezza.

Raccomanderei di combinare e moltiplicare tutte le seguenti informazioni insieme in un hash con anche la crittografia utilizzando una chiave pubblica memorizzata nel server.

  • UserId (o UUID utente che è stato generato per ciascun utente durante la logging)
  • Crittografata la sua password (considerata come chiave privata per la crittografia per each utente)
  • Data e ora
  • Sistema operativo client
  • Agente utente del client (nome del browser)

Per conservare i token, puoi usare memcache che viene utilizzato pesantemente nelle grandi aziende o redis se ti concentri sulla persistenza.

Assicurati che i tuoi cookie abbiano i seguenti attributi, per maggiori informazioni sui cookie

  • HTTP Solo cookie
  • Cookie sicuro