Posizionamento di sale prima dell'hash monodirezionale

Question

Posizionamento di sale prima dell'hash monodirezionale

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

7

Nell'hash unidirezionale è comune anteporre o aggiungere il sale al segreto e poi cancellarlo: (sale + segreto) o (segreto + sale). Stavo pensando a questa metafora come il sale che cade su un piatto di cibo. Ovviamente non tutto cade all'inizio o alla fine del piatto.

C'è qualche vantaggio in termini di sicurezza se invece dovessi distribuire casualmente il sale all'interno del segreto come di seguito?

Semplice esempio in cui sale viene distribuito ogni altra lettera:


Salt = lk2jn35  
Secret = hello  
Salted = lhke2ljlno35

Sono sicuro che potrei anche trovare una variabile "maschera" che descrive la distribuzione del sale nel segreto e la distribuzione del sale stesso potrebbe diventare casuale come questa:


Salt = lk2jn35  
Secret = hello  
SaltMask = 010011101011  
Salted = hlelk2jlno35

La domanda però ha vantaggi di sicurezza aggiuntivi oltre al metodo tradizionale di antefatto o aggiunta ?

cryptography hash salt

posta TugboatCaptain 13.08.2013 - 10:11

fonte

2 risposte

Leggi altre domande sui tag cryptography hash salt

Cambio password BitLocker In che modo due sistemi sono in grado di configurare un tunnel SSH sicuro su una connessione pubblica?

score 9 · Answer 1

Come il sale e la password sono mescolati insieme non ha alcuna importanza SE la funzione hash è "perfetta" (cioè è un oracolo casuale ). Tuttavia, le funzioni di hash perfette non esistono realmente; non sappiamo nemmeno se esistano persino funzioni di hash "leggermente imperfette" (funzioni che non sono oracoli casuali ma sono comunque garantite come resistenti alle preimage). Le funzioni di hash pratiche hanno "stranezze" che si riferiscono alla loro struttura interna e devono essere evitate avendo cura di come viene preparato l'input. È estremamente difficile dire in che modo combinare password e sale è meglio, quindi il modo normale è di lasciarlo a crittografi esperti. Queste persone sono venute fuori, dopo decenni di lavoro, con alcune costruzioni che sembrano essere forti, ed è improbabile che uno sviluppatore solitario possa inventare qualcosa di significativamente migliore schiacciando una o due funzioni.

In ogni caso, anche se il tuo metodo di mixare password e sale è buono (potrebbe potrebbe essere buono, ma è difficile saperlo con certezza), la tua funzione è ancora troppo veloce . Dovresti avere migliaia o anche milioni di invocazioni di funzioni hash annidate qui, perché una funzione di hashing della password dovrebbe essere intrinsecamente lenta . Vedi questa risposta per un trattamento completo della domanda.

score 3 · Answer 2

Vedi Perché è sempre 'HASH (salt + password) 'che consigliamo? . Se stai cercando un metodo sicuro per la verifica della password, ci sono opzioni migliori, come sottolinea Thomas Pornin nella sua risposta a questa domanda, e Tom Leek sottolinea sopra.

Il metodo H(salt|secret) potrebbe essere suscettibile agli attacchi di estensione della lunghezza sebbene io possa Per vedere un modo in cui può essere utile in questo contesto (poiché è necessario conoscere entrambi i componenti per eseguire questo tipo di attacco, non c'è alcun vantaggio), non c'è motivo di eliminarlo immediatamente.

Supponendo che l'algoritmo hash scelto sia adatto allo scopo , allora suggerisco le seguenti considerazioni:

Lo scopo di sale non è quello di "migliorare" l'hash, ma di rendere costoso l'esecuzione di alcuni attacchi precompilati
La concatenazione del sale è un'operazione computazionalmente banale, e non altrettanto efficace quanto la allungamento della chiave in termini di spesa . Mescolare i bit in una manciata di volte è un'operazione relativamente banale.
Dato l'intento di un sale come usato qui, una cosa che si può dire è che un sale più lungo e casuale è migliore allo scopo previsto. Ne consegue che non rende il sale più (o meno) efficace se si mescolano semplicemente bit di input intorno.

Supponendo che "migliore sicurezza" equivale a "più difficile per un utente malintenzionato", non vi è alcun vantaggio poiché l'hacker conosce il sistema e la sfida non è più complessa di prima. Il segreto è ancora lo stesso segreto e la quantità di lavoro da fare per recuperarlo è praticamente invariata.

(E, come sempre, c'è il rischio che tu abbia trascurato qualche aspetto sottile del sistema, o sei semplicemente sfortunato oggi, e hai in qualche modo gestito per peggiorare la sicurezza generale.)