@anacard@gallir
> El segundo salt podría estar incrustado directamente en el código fuente (mala práctica) o tomarse a partir de archivos de configuración
- el salt tiene que ser distinto para cada usuario, o no funciona. Si usas el mismo salt, es contraproducente.
- si tienen acceso a tu db de usuarios puedes asumir que también tienen acceso a la app. El código fuente, o la config, estarán en memoria.
> Seguramente en rendimiento no merece la pena, pero quería plantear el escenario de que el atacante sólo tuviera acceso a una parte del salt.
El salt es algo público, casi por definición. La idea es que el hash y el salt son públicos y conocidos, mientras que el password es secreto y es (casi)imposible de deducir a partir del hash y el salt.
@anacard@gallir sobre guardar el salt en otra db. Cuantos más factores añadas, mejor. Pero:
- Desventaja 1: No añade seguridad.
Se asume que alguien que ha accedido a tu base de datos de contraseñas también tiene acceso a esa otra base de datos externa. La dificultad de romper las claves es la misma, por lo que la ventaja 1 desaparece.
Idem para sistemas que calculan otro factor "secreto" a partir de los datos de usuario (base64 del email, md5 de la fecha de creación, etc). Se asume que el código se filtra.
- Desventaja 2: Rendimiento y complejidad.
Si para validar cada usuario tienes que acceder y cruzar datos de varios sitios, el rendimiento empeora. Si usas un slow hash (PBKDF2), ya es bastante lento como para añadir más pasos.
En todo caso, el artículo se centra en cómo mitigar daños cuando la db de usuarios se ha filtrado. Lo que tú propones es cómo evitar que el atacante se haga con los datos, y sobre ese tema da para otro artículo igual de largo.
@anacard Mil gracias Anacard. cosas así se agradecen después de la que me ha caído :). Voy a estudiar lo que me dices y solucionaría gran parte de mi problema.
> El segundo salt podría estar incrustado directamente en el código fuente (mala práctica) o tomarse a partir de archivos de configuración
- el salt tiene que ser distinto para cada usuario, o no funciona. Si usas el mismo salt, es contraproducente.
- si tienen acceso a tu db de usuarios puedes asumir que también tienen acceso a la app. El código fuente, o la config, estarán en memoria.
> Seguramente en rendimiento no merece la pena, pero quería plantear el escenario de que el atacante sólo tuviera acceso a una parte del salt.
El salt es algo público, casi por definición. La idea es que el hash y el salt son públicos y conocidos, mientras que el password es secreto y es (casi)imposible de deducir a partir del hash y el salt.
- Desventaja 1: No añade seguridad.
Se asume que alguien que ha accedido a tu base de datos de contraseñas también tiene acceso a esa otra base de datos externa. La dificultad de romper las claves es la misma, por lo que la ventaja 1 desaparece.
Idem para sistemas que calculan otro factor "secreto" a partir de los datos de usuario (base64 del email, md5 de la fecha de creación, etc). Se asume que el código se filtra.
- Desventaja 2: Rendimiento y complejidad.
Si para validar cada usuario tienes que acceder y cruzar datos de varios sitios, el rendimiento empeora. Si usas un slow hash (PBKDF2), ya es bastante lento como para añadir más pasos.
En todo caso, el artículo se centra en cómo mitigar daños cuando la db de usuarios se ha filtrado. Lo que tú propones es cómo evitar que el atacante se haga con los datos, y sobre ese tema da para otro artículo igual de largo.