Conta come salatura unica contro le tavole arcobaleno

Question

Conta come salatura unica contro le tavole arcobaleno

#1 da (1 voti)
#2 da (1 voti)

0

** A causa delle limitazioni della mia situazione, l'exe (cioè l'origine), l'hash, sale, tutto viene archiviato localmente in quanto è un'applicazione locale.

Questa idea avrebbe battuto le tavole arcobaleno?

Password = Input (always 8 in length, 0-9 accepted) (unique to person)
Check = Input2 (always 2 in length, 0-9 accepted) (unique to person)

HashedPassworwd = Hash(Password, SHA_512)

Salt = Starting at string position Check, take 32 chars onwards

HashedSalt = Hash(Salt, SHA_512)

FinalHash = Hash(HashedPassworwd+HashedSalt, SHA_512)

Sarebbe questo battere le tavole arcobaleno e funzionerebbe solo contro la forza bruta?

hash salt rainbow-table

posta ian smith 12.09.2016 - 22:52

fonte

2 risposte

Leggi altre domande sui tag hash salt rainbow-table

Quali sono le normative federali e di settore PCI, SOX, GLBA, ISO 17799, HIPAA, CA1386? Come funziona davvero l'algoritmo HMACSHA1?

score 1 · Answer 1

Probabilmente stai meglio aumentare la lunghezza e la forza della password piuttosto che fare qualcosa con check e salt - sale è destinato ad essere memorizzato con la password hash come principio generale.

Ciò che hai effettivamente fatto con il controllo è aumentare l'entropia della password di 2 cifre, rendendo più difficile l'utilizzo di librerie standard. Se stai usando solo 0-9, questo è solo 10 ^ 10 - anche con sale, anche con SHA512, che è irrinunciabile da qualcuno che vuole davvero - specialmente se i tuoi utenti usano pattern prevedibili, che probabilmente lo faranno.

Perché limitare la lunghezza della password e i caratteri validi: verrà comunque sottoposto a hash, senza distogliere lo sguardo dal punto di vista dello storage. Con un set di caratteri migliore, puoi semplicemente usare un hash sale e sha512 dritto e essere sicuro.

score 1 · Answer 2

La tua idea non è chiaramente del tutto esclusa, quindi, come previsto, questa è una domanda quasi senza speranza a cui rispondere. Ma tuttavia vedo un sacco di problemi chiari:

Risolto, lunghezza della password breve di 8 caratteri. Devi accettare password molto lunghe se gli utenti desiderano fornirle.
Il problema della lunghezza della password è particolarmente aggravato dal fatto che accetti solo cifre da 0-9.
Se gli utenti scelgono le proprie password, non puoi presumere che saranno uniche. Nella vita reale, molte persone usano le stesse password, come "12345678", che è una delle password più comuni nella pratica .
Se la variabile Check è di 2 cifre, non può essere "univoco per persona" a meno che non ci siano più di 100 persone.
Poiché i tuoi sali derivano da una variabile Check che ha solo 100 combinazioni distinte, ci sono solo 100 sali distinti. Ciò rende la lunghezza di 32 caratteri inutile. (Suppongo che la "stringa" da cui prendi i 32 caratteri sia sempre la stessa. Non ci hai detto nulla su questa stringa.)
SHA-512 non ha alcuna forma di fattore di lavoro regolabile per rallentare un utente malintenzionato. Se hai accesso a SHA-512, hai accesso a PBKDF2-HMAC-SHA512, quindi dovresti usare almeno . (Non che ti faccia bene, visto quanti altri problemi hai!)
Non capisco di quale tipo di limitazioni si stia parlando nella prima frase, ma se l'autore dell'attacco ha accesso al codice dell'oggetto del programma, può semplicemente modificarlo per ignorare tutto ciò.
Sembra che tu sia fissato su tavoli arcobaleno quando sono probabilmente il minimo dei tuoi problemi.