Protezione dell'autenticazione basata su cookie

Question

Attualmente sto riesaminando una delle mie applicazioni Web e speravo in qualche consiglio sul miglioramento della sicurezza.

Noterò che l'applicazione è in ASP.net e l'implementazione corrente mi impedisce di utilizzare l'autenticazione integrata. Anche questa non è in alcun modo un'applicazione che richiede un'elevata sicurezza, mi piace solo avere le mie basi coperte.

In passato ho archiviato l'id e un token. Il token è un hash dell'ID dell'utente + l'utente Salt (riutilizzando il valore dalle informazioni di autorizzazione) Quando un utente visita il sito, l'ID viene controllato contro il token e autenticato di conseguenza.

Mi viene in mente che qui c'è un grosso buco. In teoria se qualcuno ha messo le mani su un valore di sale tutto quello che avrebbero dovuto fare è indovinare l'algoritmo di hash e scorrere tra i possibili ID finché non sono entrati. Non mi aspetto che ciò accada, ma sembra ancora un errore .

Qualche consiglio su come confermare correttamente che i cookie dell'utente non sono stati modificati?

Answer 1

Il modo in cui la maggior parte dei siti web fanno è per autenticare il utilizzare e, in caso di esito positivo, inviare al browser un cookie per archiviare e inviare eventuali richieste successive. Se un utente malintenzionato è riuscito a impossessarsi del token (prima che sia scaduto) sarà in grado di impersonare l'utente.

Per questo motivo il processo di autenticazione e cookie deve essere sempre eseguito su una sessione https. L'unico modo realistico con cui un utente malintenzionato deve impossessarsi del cookie è quindi intercettarlo sul computer dell'utente finale e, se sono in grado di farlo, probabilmente possono installare un keylogger e ottenere comunque la password dell'utente.

Per quanto riguarda il tipo di token da utilizzare, non importa fintanto che sia abbastanza pseudo-casuale da renderlo computazionalmente costoso da indovinare per un utente malintenzionato. Io stesso uso GUID. se hai bisogno di ulteriori informazioni nel cookie oltre a un sessionid, puoi aggiungere un GUID ad esso e probabilmente hash o crittografarlo solo per un approccio di cintura e parentesi graffe.

Answer 2

due modi:

1. Crittografare con un algoritmo simmetrico (AES).

Questo è utile perché consente di decrittografarlo; ma si potrebbe obiettare che non è necessario decrittografarlo (a seconda di quale altra cosa si memorizza lì).

2. Hash e Sign it. Anche in questo caso viene utilizzata una chiave privata, quindi anche se qualcuno conosce i contenuti esatti, non è possibile riprodurre l'hash, perché hanno bisogno della chiave privata.

Probabilmente avrei (e ho già fatto) l'opzione 1.

Answer 3

perché non memorizzare solo l'hash nel cookie o qualsiasi altro numero pseudocasuale? Quindi selezionare il database per ottenere l'ID utente.

le altre cose: solo fare il http biscotto, cioè non possono essere impostati con javascript Se si tratta di un'opzione, ne fanno essere trasmesso solo con i dati HTTPS

Answer 4

Il modo migliore è memorizzare un ID sessione come valore del cookie.

Ogni volta che l'utente esegue l'accesso, si crea un record nel database o in un altro archivio di sessioni con un ID di sessione casuale. Metti l'ID in un cookie. Quando vedi il cookie in un secondo momento, puoi recuperare tutte le informazioni utente dal database.

Questo approccio presenta i seguenti vantaggi,

1. E 'molto sicuro. L'ID sessione è semplicemente un numero casuale. Non devi preoccuparti della chiave compromessa o del sale.
2. Il cookie può essere facilmente revocato dal server. Tutto quello che devi fare è rimuovere il record della sessione e questo renderà l'ID inutile.
3. Il valore del cookie può essere molto breve.

Se questo non funziona, prova la crittografia. Hash sarebbe la mia ultima scelta. Hash stesso è inutile. Devi memorizzare l'ID utente e altre informazioni in un altro cookie in chiaro. Hai finito per esporre le informazioni dell'utente.