Dovrei anche cancellare l'ID della mia sessione prima di memorizzarlo nel database? [duplicare]

2

Sto scrivendo un'API che distribuisce id di sessione usando la funzione uniqid di PHP (sì usando più entropia). Comunque mi chiedo se aggiunga più sicurezza per hash questo id sul server, proprio come le password?

I miei pensieri:

Con

  • In realtà non è un segreto che passa ad altri siti, come le password.
  • Se il database è compromesso, tutti i dati sono comunque leggibili. Non c'è bisogno di prendere la via dell'API.

Pro

  • L'autore dell'attacco non può leggere il valore da inviare direttamente.
  • Con il sale gli ID non saranno uguali nel database, anche se lo sono.
posta Thomas 30.09.2016 - 22:55
fonte

3 risposte

2

With salt the id's won't look the same in the database, even if they are.

  • I token di sessione devono essere generati con un generatore di numeri casuali crittograficamente sicuro.

  • I token di sessione dovrebbero avere 72 bit di entropia o più.

Per il prevedibile futuro , un token casuale a 72 bit sarà globalmente unico, quindi Il sale non è necessario.

Pro [to hashing] The attacker can't read the [plain session token] to send directly.

  • È meglio controllare un indirizzo IP corrispondente oltre al token di sessione. Questo potrebbe non funzionare per gli utenti di dispositivi mobili, perché se il loro IP cambia (cioè segnale debole), allora verrebbero cancellati.

Altrimenti l'attaccante può usare il token di sessione da qualsiasi IP, che, come suggerito, (dopo un attacco SQLi) è poco più che una comodità, perché l'attaccante ha già accesso al database completo.

Tuttavia, dirottare una sessione in questo modo sarebbe molto utile se alcuni file / dati sono memorizzati al di fuori del database. (e se le sessioni compromesse hanno accesso per vedere quei dati)

[The session token] is not really a secret that leaks to other sites, like passwords would.

True.

If the database is compromised, all data is readable anyways. No need [for the attacker] to take the API way.

  1. A volte file o dati sono archiviati al di fuori del database.

  2. Una procedura di sicurezza abbastanza comune è usare account utente di database separati , quindi è possibile che i token di sessione possano essere rubati con un SQLi di sola lettura (cioè utente con accesso limitato al database), con i dati più sensibili che rimangono sicuri ( cioè richiede un utente di database con scopi speciali)

  3. Puoi usa password (e token di sessione) per accedere alle chiavi di crittografia lungo la strada.

È davvero facile eseguire un rapido SHA-2 sul token di sessione, quindi se c'è qualche possibilità che il # 1, il # 2 o il # 3 siano implementati in fondo alla strada, allora prendi il controllo!

    
risposta data 30.09.2016 - 23:53
fonte
2

È una buona funzionalità, ma non assolutamente obbligatoria.
Avresti molto di più di cui preoccuparti se un utente malintenzionato è in grado di filtrare i dati dal tuo spazio di archiviazione. Se stai facendo una buona gestione delle sessioni, non dovresti preoccuparti molto dell'hash della chiave di sessione.

Puoi fare riferimento alla guida OWASP alla gestione delle sessioni: link
E un altro post sul blog: link

    
risposta data 30.09.2016 - 23:15
fonte
1

Mi vengono in mente due vettori di attacco:

Iniezione SQL - contro il tuo sito pubblico o un sito di gestione amministrativa - Può consentire a un utente malintenzionato di ottenere un ID sessione in tempo reale, il che significa che potrebbero impersonare qualsiasi utente. Vedi anche questo articolo

Meccanismo di registrazione: il tuo sito sta registrando eventi di sessione, e se questi sono registrati con l'ID di sessione cleartext e i controlli di accesso ai file di log non sono sicuri quanto il tuo database, allora avrai lo stesso problema. Link alle linee guida OWASP su questo argomento

    
risposta data 30.09.2016 - 23:04
fonte

Leggi altre domande sui tag