hash della password con ampio stato interno

Question

hash della password con ampio stato interno

#1 da (3 voti)
#2 da (0 voti)
#3 da (0 voti)

1

scrypt è stato progettato per utilizzare molta memoria e, se non fosse stata utilizzata tutta la memoria, sarebbe stato più lento calcolare alcuni ordini di grandezza. Ad ogni modo, neutralizza gli attacchi hardware personalizzati, dove tende a non essere disponibile così tanta memoria.

Stavo pensando, perché preoccuparsi di consentire un compromesso di memoria del tempo? Non sarebbe meglio usare una funzione di hash con uno stato interno molto grande (accordabile ovviamente)? La dimensione dello stato interno determina i requisiti di memoria e il numero di cicli è il fattore di lavoro.

memory hash password-cracking scrypt

posta EPICI 13.09.2017 - 05:17

fonte

3 risposte

Leggi altre domande sui tag memory hash password-cracking scrypt

Potenziale intrusione sulla rete domestica? Autenticazione login Jetpack automatica ... Perché non si tratta di un difetto di sicurezza?

score 3 · Answer 1

Penso che tu abbia descritto SHA-3 , dove capacity c (e ad un in misura minore, il rate r ) sono esattamente lo "stato interno molto grande (accordabile naturalmente)" di cui parli.

Non devi aumentare molto il livello (512 bit / 1024 bit) per ottenere i tuoi livelli di sicurezza a 256/512 bit.

Ricorda però che l'obiettivo della crittografia non è quello di fare molto lavoro all'aggressore, ma di fare in modo che l'autore dell'attacco esegua molto più lavoro che l'utente legittimo . L'hashing implica operazioni costose sullo stato interno, quindi accostare alla cieca le dimensioni dello stato interno fa male agli utenti legittimi tanto quanto fa male all'attaccante.

Le grandi esigenze di memoria di scrypt hanno lo scopo di sfruttare una risorsa che è abbondante per l'utente legittimo (un server che gestisce un piccolo numero di richieste di accesso alla volta), ma scarsa per l'hacker in esecuzione su piattaforme hardware in parallelo.

score 0 · Answer 2

Si chiama "trade-off" per una ragione. :)

Come suggerisce Mike Ounsworth, c'è un'asimmetria tra l'attaccante e l'utente legittimo. Ma c'è anche asimmetria tra i casi di utilizzo legittimi .

Ad esempio, l'implementazione dello scrypt potrebbe essere ottimizzata per autenticare una piccola percentuale degli utenti in parallelo durante le normali condizioni. Ma se c'è un'interruzione o un'interruzione tale che tutti gli utenti sono disconnessi, e quindi (forse automaticamente) provare a riconnettersi contemporaneamente? Se la modalità di errore è un potenziale caso d'uso per l'applicazione, potrebbe essere necessario regolare di conseguenza i parametri sintonizzabili di scrypt.

Ma se si utilizza solo lo scrypt per proteggere un singolo volume crittografato altamente sensibile su un sistema personale, un ritardo di alcuni secondi potrebbe essere accettabile per te e desiderabile aumentare il costo di un attacco.

Questo è il compromesso.

score 0 · Answer 3

In una certa misura, un compromesso tra memoria e tempo è una conseguenza inevitabile di avere un grande stato interno. I ragazzi di CS.SE potrebbero probabilmente fornire una spiegazione più formale, ma in pratica, se l'hash della password richiede l'elaborazione, la memorizzazione e, in seguito, utilizzando un numero elevato di valori intermedi, un utente malintenzionato con memoria limitata può sempre semplicemente calcolare quei valori su richiesta.