Ci sono usi di avere un valore salino non deterministico per gli hash?

3

Quindi mi sono divertito con l'idea di avere valori di sale non deterministici per gli hash.

Lascia che ti spieghi cosa intendo:

Fondamentalmente, ho applicato alcune proprietà da Bitcoin, inclusa una "difficoltà" (ovvero, il valore hash deve iniziare con un certo numero di bit 0) e ho trovato qualcosa che potrebbe essere utilizzato per gli hash delle password.

Il mio algoritmo:

string hashstring=password;
for(int i = 0; i < int.MaxValue; i++)
{
    var hash = Hash(hashstring);
    hashstring = Convert.ToBase64String(hash);
    if(MeetsDifficulty(hash, difficulty))
    {
        Console.WriteLine("i: "+i);
        return hashstring;
    }
}

password in questo caso, è qualcosa come password+salt dove sale è un sale random criptografico standard memorizzato con l'hash. Tuttavia, come puoi vedere, esiste anche un valore i per quante volte deve essere sottoposto a hash, che non è archiviato insieme all'hash.

In questo modo, devi hash la password un numero di volte finché non trovi qualcosa che soddisfi il livello di difficoltà richiesto. È facile da verificare, ma richiede tempo perché è sconosciuto esattamente quante volte il valore deve essere sottoposto a hash.

Ci sono alcune proprietà interessanti di questo meccanismo:

  • Una password errata è leggermente non rilevabile. L'unico modo per sapere che non è corretto è se conosci il livello di difficoltà e trovi un hash che lo soddisfa, ma non corrisponde all'hash
  • Probabilmente è abbastanza difficile calcolare tutto questo in parallelo?
  • In teoria, è completamente sconosciuto quanto tempo ci vorrà per verificare o calcolare un hash (diverso dalle probabilità)
  • Bruteforce sarebbe probabilmente difficile perché ogni password tentata potrebbe comportare una quantità enorme di hash necessari per verificarlo alla difficoltà

Tuttavia, non riesco davvero a trovare un buon uso di queste proprietà. C'è qualche cosa buona per applicare un tale schema o c'è qualcosa che usa un tale schema?

Inoltre, ci sono dei potenziali punti deboli in questo schema di hashing?

Per i miei test, ho usato SHA256 come algoritmo di hashing, ed è diventato piuttosto lento dopo una difficoltà di circa 20 bit di zeri. Tuttavia, questo potrebbe essere facilmente sostituito con l'uso di scrypt, bcrypt o SHA512

Inoltre, un'altra idea è che potresti costruire "velocemente" per verificare gli hash, ma solo quando hai la password corretta. (cambiando il sale se, ad esempio, hai già cancellato il valore X volte e vuoi scegliere come target solo l'hashing del valore Y volte per verificarlo quando viene fornita una password corretta)

    
posta Earlz 28.04.2013 - 05:14
fonte

1 risposta

1

Non proprio. Questo ti protegge dal forcing brute lato client, ma ti apre su attacchi DoS-like.

Il difetto qui è che quando qualcuno sta tentando di forzare una password, la potenza della CPU che usano è yours , non loro. Il che significa che il tuo sistema può essere messo in ginocchio molto più velocemente da un attacco di forza bruta distribuito. Soprattutto perché non c'è "escape" nel ciclo for fino all'overflow dei numeri interi: se inserisco una password errata, il server proverà a ottenere l'hash giusto per un po 'di tempo.

Non sarai in grado di mantenere la difficoltà troppo alta. Il fatto è che questo calcolo esatto viene eseguito ogni volta che la persona vuole accedere . Questo non è difficile da fare, ma facile da verificare come il sistema Bitcoin. Poiché i è sconosciuto, questo è altrettanto difficile da fare è verificare.

L'unica cosa che protegge (solo leggermente) è se il tuo database è stato compromesso - allora sarai protetto contro la bruteforcing. Ma i sali su SHA256 gestiscono comunque bene questo lavoro.

    
risposta data 28.04.2013 - 09:10
fonte

Leggi altre domande sui tag