With salt the id's won't look the same in the database, even if they are.
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.
-
A volte file o dati sono archiviati al di fuori del database.
-
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)
-
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!