La prepending di una password salata invece di inserirla nel mezzo diminuisce la sicurezza?

Ciò che questo articolo avrebbe potuto significare è che mettere il sale da qualche parte nel mezzo della password aumenterebbe presumibilmente la possibilità di essere incrinato da un attacco di dizionario o dalla forza bruta, perché le regole per comporre lo stesso hash non potevano essere implementate nel tuo password cracker di scelta. In realtà, questa è probabilmente un'assurdità completa.

Come funziona?

Se usi un programma come John the Ripper , lo nutri con il tuo file di password in questo modo (non la sintassi esatta ):

username:password:salt

Quindi si passa il formato come parametro a cui si pensa venga generato l'hash. Questo può essere:

md5(pass + salt)
md5(salt + pass)
md5(md5(pass) + md5(salt))
md5(pass + md5(salt))
md5(md5(...(salt + pass + salt)...))
...
and whatnot.

John the Ripper ha un set di circa 16 sotto formati che puoi scegliere tra.

Mettere il sale da qualche parte nella password sarebbe probabilmente il seguente:

md5(password.substring(0,4) + salt + password.substring(4,end))

Quindi, usando una tecnica come questa, devi prima scrivere un piccolo plug-in per John, prima di poter iniziare a crackare (il che non dovrebbe essere affatto un problema).

Inoltre, come utente malintenzionato potresti avere un elenco di hash + sali di origine sconosciuta e non avere alcuna conoscenza del modo in cui viene composto un hash. Questo è raramente il caso. Se tu, in qualità di utente malintenzionato, riesci a estrarre hash e sali da un database, probabilmente troverai un modo per estrarre l'algoritmo di hashing della password del sito web o semplicemente crei un nuovo account con una password conosciuta, estrai l'hash e il sale per e forza bruta l'algoritmo che è stato usato per comporre l'hash finale (che può essere più o meno impegnativo).

Tutto sommato, è quasi del tutto arbitrario dove si inserisce il sale e se si o meno iterare l'algoritmo di hashing diecimila volte o meno. Questo NON fornisce una quantità significativa di sicurezza.

Se vuoi sicurezza, puoi fare meglio usando un algoritmo di hashing migliore o bcrypt o qualcos'altro che è dispendioso dal punto di vista computazionale.

Dipende dalla funzione di hash.

Con un oracolo casuale (che è la "funzione di hash ideale"), non c'è alcuna differenza su come si mettono insieme il sale e la password, a patto che entrambi entrino.

Con vere funzioni di hash live potrebbero esserci delle differenze sulla posizione dell'input (come, ci sono attacchi di estensione).

Ma di solito, di solito vuoi usare uno speciale schema di hashing delle password come PBKDF-2, bcrypt o scrypt, e questi sono già fatti con tre input, uno è la password e l'altro il sale (il terzo il lavoro fattore). Semplicemente usali come dovevano essere usati.

È meglio avere casualità all'inizio della stringa di input, che alla fine.

Se il sale è un valore costante per tutte le password, allora è più facile bruteforce più password se il sale viene applicato come:

hash(salt . password)

anziché

hash(password . salt)

Il motivo è semplicemente perché alcuni (e penso che entrambi gli algoritmi di hashing di md5 e sha-1 si adattino a questa descrizione) siano iterativi - e se la stringa che si sta facendo ha inizio con un valore costante noto è possibile seminare qualsiasi tentativo di cracking con il risultato dell'operazione di hashing del sale, eliminando così i vantaggi della salatura delle password.

Se i valori salt sono specifici della password (quali dovrebbero essere), quanto sopra non si applica e probabilmente il sale è più casuale della password stessa. Per questo motivo, è meglio anteporre il sale, anche se la differenza / beneficio è trascurabile.

Il suggerimento di inserire il sale nel mezzo della stringa di input è probabilmente un'altra permutazione di non iniziare la stringa di input con un valore costante - finché si evita di farlo, la password è sicura come l'algoritmo di hash e l'applicazione usandolo.

Sarebbe potenzialmente leggermente più sicuro, ma trascurabilmente. Non me ne preoccuperei e lo annetterò per semplicità. Quasi tutte le società per le quali ho lavorato non usavano nemmeno un sale, quindi sei già più sicuro della maggior parte.

Le probabilità che un hacker con un hash rubato dal tuo database o un attacco man-in-the-middle a cui è applicato un sale è molto improbabile in confronto agli hash non salati che possono potenzialmente essere risolti facilmente con tavoli arcobaleno.

In altre applicazioni, quando si utilizza un HMAC, sia la preparazione preliminare che l'aggiunta della chiave segreta sono vulnerabili a diversi tipi di attacco. Nessuno di questi si applica alla salatura di un hash della password, quindi, uno dei due dovrebbe essere soddisfacente.

È (anche se solo leggermente) più sicuro in base al fatto che se qualcuno dovesse assumere e testare contro la salatura, assumerebbe sicuramente un sale preposto a causa della frequenza con cui si verifica (e in base a quanto volevano accesso possono quindi provare un sale aggiunto)

Anche se inizia a diminuire il tempo / il compromesso della memoria, puoi sicuramente generare tabelle arcobaleno usando password salate e sono comunque utili. Ovviamente, impiegano molto più tempo per generare e occupare molto più spazio ma anche io li ho usati per alcuni progetti.

Stavo implementando il mio algoritmo di hashing della password, inclusa la salatura, che avrei scelto da qualche parte che non era la parte anteriore o la parte finale di sicuro. Ovviamente non utilizzerei nemmeno un sale codificato a causa del minimo di problemi che ne deriverebbero.

Non riesco a pensare a nessuna ragione per cui non vorrei aumentare la sicurezza (indipendentemente da quanto trascurabile possa essere un aumento) al costo di un aumento minimo o nullo.