Sta facendo qualcosa di simile
sha256(sha512(password+salt))
Meno sicuro quindi solo facendo
sha256(password+salt)
Ho sentito che aumenterà le probabilità di collisione.
Posso pensare a 3 motivi per farlo
Sembra di reinventare la ruota e dubito che raggiungerà un aumento tangibile della sicurezza. I progettisti di queste funzioni hanno davvero preso in considerazione tutti questi aspetti durante la creazione di quelle funzioni di hash sicure.
Le collisioni non sono rilevanti per l'hashing della password. Dimentica le collisioni. La sicurezza qui si basa sulla resistenza alle pre-analisi , non alle collisioni.
Informazioni sui "tre motivi":
L'aggressore ha meno probabilità di avere una tabella arcobaleno: dal momento che stai usando sali, l'attaccante non ha tabelle arcobaleno o qualsiasi altro tipo di tabella precompiata. Questo è l'obiettivo principale di Salt: sconfiggere gli attacchi basati su tabelle.
La brevità dell'output SHA-256: se si ha poco spazio, è possibile anche troncare l'output di SHA-512 in base alla lunghezza desiderata. La resistenza di preimage sarà adeguata se si mantengono almeno 12 byte o giù di lì (cioè 16 caratteri se si codifica l'output con Base64).
Informazioni sulla velocità di calcolo: questo è un assaggio della verità. Rendere più lento il processo di hashing è una buona idea; ma, in realtà, devi renderlo molto più lento di quello. Non effettuare due invocazioni di funzioni hash; crea due milioni .
Ovviamente, invece di reinventare la ruota, è molto meglio usare i buoni algoritmi che sono stati progettati per risolvere il problema dell'hash delle password; questo significa bcrypt o PBKDF2 . Questi algoritmi hanno sostenuto anni di analisi da parte di crittografi infuriati, che non hanno trovato nulla di mortale in loro. Uno schema fatto in casa non può vantare come tale.
Come sottolineato da Yoav, questo schema è fondamentalmente inutile per i tuoi intenti e, nel peggiore dei casi, danneggia la tua sicurezza riducendo l'entropia della password fornita.
L'unico modo per migliorare la sicurezza utilizzando più di una funzione di hash è archiviare separatamente tutti i risultati di hash e confrontarli tutti durante l'autenticazione. Algoritmi preferibili come sha, md5 e bcrypt.
hash1 = sha512 (password + sale1)
hash2 = md5 (password + salt2)
hash3 = bcrypt (password + salt3)
In questo modo le probabilità di trovare una collisione con successo sono molto basse.
Overkill secondo me. SHA256 utilizza 64 iterazioni di funzioni su un array di 8 colonne. SHA512 con 80 iterazioni su un array di 5 colonne. Non è necessario raddoppiare l'hash perché nessuno è stato ancora in grado di potenziare nessuno di questi. I tavoli arcobaleno non saranno utili a un attaccante finché c'è del sale.
Assumendo un input da 32 byte (che è ragionevole per il tuo caso - 20 byte salt + 12 byte di password) la mia macchina impiega ~ 0,22s (~ 2 ^ -2s) per i calcoli 65536 (= 2 ^ 16). Quindi i calcoli 2 ^ 256 verrebbero eseguiti in calcoli 2 ^ 240 * 2 ^ 16 che richiederebbero
2^240 * 2^-2 = 2^238 ~ 10^72s ~ 3,17 * 10^64 years
Quindi, per proteggere davvero te stesso, tutto ciò che devi fare è rendere grande la dimensione totale della tua stringa, come 32 byte, e non dovrai nemmeno preoccuparti di questo.
Controllalo per capire quanto pazze funzioni della serie SHA siano:
I can think of 3 reasons to do this
1. A hacker is less likely to have a rainbow table for it
Questa non è una buona difesa: possono ancora costruire una tabella applicabile a tutti gli utenti del tuo sistema. Una difesa migliore sta usando i sali (che sembra che tu sia).
2. sha256 returns a shorter string then sha512
Perché è un plus?
3. It will take more time to compute the hash
Questa è una buona ragione, ma non è necessario utilizzare due hash separati e due iterazioni non sono sufficienti. Meglio sarebbe qualcosa sulla linea di hashing centinaia / migliaia di volte, o usando un hash che era progettato per essere lento .