Está haciendo algo como esto
sha256(sha512(password+salt))
Menos seguro que simplemente haciendo
sha256(password+salt)
He oído que aumentará las posibilidades de colisión.
Puedo pensar en 3 razones para hacer esto
Esto se siente como reinventar la rueda, y dudo que logre algún aumento tangible de seguridad. Los diseñadores de esas funciones realmente consideraron todos esos aspectos al crear esas funciones hash seguras.
Las colisiones no son relevantes para el hashing de contraseñas. Olvídate de las colisiones. La seguridad aquí se basa en la resistencia a preimágenes , no en colisiones.
Sobre tus "tres razones":
Es menos probable que el atacante tenga una tabla de arco iris: debido a que está utilizando sales, el atacante no tiene tablas de arco iris, ni ningún otro tipo de tabla precomputada. Ese es el punto central de la sal: para vencer los ataques basados en tablas.
El acortamiento de la salida de SHA-256: si tiene poco espacio, también puede truncar la salida de SHA-512 a la longitud que le convenga. La resistencia de preimagen será adecuada si mantienes al menos 12 bytes más o menos (eso es 16 caracteres si codificas la salida con Base64).
Sobre la velocidad de cálculo: eso es un atisbo de la verdad. Hacer el proceso de hash más lento es una buena idea; Pero, en realidad, tienes que hacerlo mucho más lento que eso. No hagas dos invocaciones de función hash; haga dos millions.
Por supuesto, en lugar de reinventar la rueda, es mucho mejor usar los buenos algoritmos que se han diseñado para resolver el problema del hashing de contraseñas; esto significa bcrypt o PBKDF2 . Estos algoritmos han sostenido años de análisis por criptógrafos enfurecidos, que no encontraron nada mortal en ellos. Un plan casero no puede presumir como tal.
Como señaló Yoav, este esquema es básicamente inútil para sus intentos y, en el peor de los casos, perjudica su seguridad al reducir la entropía de la contraseña dada.
La única forma en que puedo crear imágenes para mejorar la seguridad al utilizar más de una función hash es almacenar todos los resultados de hash por separado y compararlos todos al autenticar. Se prefieren diferentes algoritmos como sha, md5 y bcrypt.
hash1 = sha512 (contraseña + salt1)
hash2 = md5 (contraseña + salt2)
hash3 = bcrypt (contraseña + salt3)
De esta manera, las posibilidades de encontrar una colisión con éxito son muy bajas.
Overkill en mi opinión. SHA256 usa 64 iteraciones de funciones sobre una matriz de 8 columnas. SHA512 con 80 iteraciones sobre una matriz de 5 columnas. No hay necesidad de hacer doble hash porque nadie ha sido capaz de fuerza bruta ninguno de estos todavía. Las tablas de arco iris no serán útiles para un atacante mientras haya sal.
Suponiendo una entrada de 32 bytes (que es razonable para su caso - 20 bytes de sal + 12 bytes de contraseña) mi máquina toma ~ 0,22s (~ 2 ^ -2s) para 65536 (= 2 ^ 16) cálculos. Por lo tanto, 2 ^ 256 cálculos se realizarían en 2 ^ 240 * 2 ^ 16 cálculos que se realizarían
2^240 * 2^-2 = 2^238 ~ 10^72s ~ 3,17 * 10^64 years
Para protegerse realmente, todo lo que tiene que hacer es aumentar el tamaño total de la cadena, como 32 bytes, y ni siquiera tendrá que preocuparse por eso.
Comprueba esto para comprender cuán locas son las funciones de la serie SHA:
Puedo pensar en 3 razones para hacer esto
1. Es menos probable que un hacker tenga una tabla de arco iris para él
Eso no es una buena defensa, aún pueden construir una tabla aplicable a cada usuario en su sistema. Una mejor defensa es usar sales (que suena como si estuvieras).
2. sha256 devuelve una cadena más corta y luego sha512
¿Por qué es un plus?
3. Tomará más tiempo calcular el hash
Esa es una buena razón, pero no es necesario usar dos hashes separados, y dos iteraciones no son suficientes. Mejor sería algo en la línea de hashing cientos / miles de veces, o usar un hash que fue diseñado para ser lento .