Con quale frequenza devo resettare il mio sale?

Question

Con quale frequenza devo resettare il mio sale?

#1 da (17 voti)
#2 da (9 voti)
#3 da (1 voti)

6

Sto pensando di implementare uno schema di riciclaggio del sale sul mio database delle credenziali utente. La motivazione alla base di questa decisione è che anche se l'hacker riesce a mettere le mani sul database e ha abbastanza tempo per craccare una password o due, nel momento in cui fa il sale sarà resettato e il suo i risultati saranno inutili.

Il mio attuale codice di registrazione dell'utente è il seguente (pseudocodice con PHP):

function getSalt($username){
    $salt=$username.getFromUrandom($SALT_RANDOM_READ); //64 bytes
    $salt=sha256($salt);
    return $salt;
}

function setPass($username, $salt, $pass){
    $pass=bcrypt($BCRYPT_WORK_FACTOR, $pass, $salt); //factor is set to 8 for now
    store_to_db($username, $pass);
}

setPass($username, getSalt($username), $plainpass);

Quello che mi propongo di fare è, invece di cambiare semplicemente il fattore per tenere il passo con la legge di Moore, anche cambiare il sale ogni pochi giorni circa. Ovviamente ciò andrebbe a vantaggio solo degli utenti regolari che accedono ogni due giorni. Nel codice:

if(today() - getLastLogin() > $SALT_CHANGE_THRESHOLD || /*work factor increased*/)
    setPass($username, getSalt($username), $plainpass); //as above

Le mie domande:

Quante volte dovrebbe cambiare un sale? Sono tentato di farlo ogni giorno, ma sono preoccupato che potrebbe essere un po 'eccessivo
Sta cambiando abbastanza il sale per fare a meno della reimpostazione della password ogni due mesi? Non lo implementerò perché so che gli utenti lo trovano fastidioso e potrebbe costringerli a selezionare una password che in seguito potrebbero dimenticare.

Come ho detto sopra, gli utenti non di ritorno non trarranno beneficio da questo. Anche gli utenti che utilizzano la stessa password con un altro servizio compromesso non trarranno alcun vantaggio, ma non sono preoccupato.

Sono anche molto tentato di utilizzare l' elenco di password più comuni e di impedire agli utenti di selezionare nessuno di loro al fine di proteggere dall'uso di password compromesse (anche se l'utilizzo di tutti i 10000 è un po 'estremo).

passwords password-management password-policy salt

posta rath 31.07.2013 - 05:31

fonte

3 risposte

9

Mai. La reimpostazione del sale non fornisce alcun miglioramento della sicurezza. La tua motivazione è che "anche se l'hacker riesce a mettere le mani sul database e ha abbastanza tempo per craccare una password o due, nel momento in cui fa il sale sarà resettato e i suoi risultati saranno inutili." Ma questo è completamente sbagliato! L'utente malintenzionato sta cercando di trovare la password. I suoi risultati saranno utili indipendentemente da quale hash salato della stessa password che ha attaccato. In termini di protezione diretta della password o dell'accesso all'account, la modifica di sale è neutra, non ha alcun impatto sulla sicurezza.

Il ripristino totale del sale riduce la sicurezza. Principalmente, riduce la sicurezza perché aggiunge complessità: è una nuova fonte di potenziali bug. Inoltre riduce la sicurezza rendendo il lavoro dell'aggressore più semplice, anche se in modo sostanzialmente teorico: se l'utente malintenzionato ottiene più copie del database delle password in momenti diversi, può ottenere la stessa password con diversi sali. Portato all'estremo, l'attaccante può aspettare finché non trova un sale per il quale è precalcolato un tavolo arcobaleno. Questo non è un problema pratico perché richiede un tempo esponenziale per ottenere una riduzione lineare dell'effetto del sale (l'esposizione degli hash 2 ⁿ con sali distinti equivale a rendere il sale n bit più corto). Tuttavia, hai diminuito la sicurezza.

Pensaci in questo modo: tagliando la password con più sali, stai esponendo di più la password. Questo va contro l'obiettivo di mantenere la password segreta.

Cambia il sale solo quando la password cambia o quando aumenti il numero di iterazioni sulla funzione di derivazione hash della password.

risposta data 31.07.2013 - 13:04

fonte

1

Ci sono due possibilità: l'autore dell'attacco ha trovato la password effettiva o l'autore dell'attacco ha trovato una collisione hash.

Nel primo caso, cambiare il sale è inutile, nel caso successivo potrebbe essere d'aiuto. Se sia utile dipende in gran parte dal fatto che abbiano trovato la partita forzando la password (iniziando con "", e finendo con "password1") o se hanno provato varie possibilità conosciute e trovato una corrispondenza (cioè iniziato con "password" e terminato con "password1"). Se più tardi, hanno quasi certamente la password e non solo una collisione hash.

Inoltre, ricorda che la sicurezza reale non dipende dal fatto che l'attaccante ignori le tue difese - se l'attaccante sa che tu cambi il sale, allora un errore gli dà due vie di attacco per la stessa password. E con l'accesso continuo, più cambi il sale più informazioni sulla password che stai dando all'attaccante.

risposta data 31.03.2014 - 09:57

fonte

Leggi altre domande sui tag passwords password-management password-policy salt

L'installazione di una vecchia versione di OpenBSD su un server con connessione Internet rappresenta un rischio per la sicurezza? Quali sono i punti deboli di questo metodo di generazione di password? Come può essere migliorato?

score 17 · Accepted Answer

Il tuo sale probabilmente non ha bisogno di cambiare più spesso della tua password. La rotazione attraverso i sali non ti protegge da nulla in particolare.

Si noti che il salt che l'utente malintenzionato usa per forzare brute-force una password non deve essere lo stesso di sale in uso quando usa la password. Solo la password deve essere la stessa. E poiché il risultato del suo attacco è determinare la password corretta, quella password continuerà a funzionare indipendentemente dalla frequenza di rotazione del tuo sale.