Hola! Tengo algunos buenos viejos amigos por aquí a los que les gustará saber que el espíritu de Fogonazos se ha materializado en esta aventura estratosférica. Os dejo esto por aquí y perdón por el autobombo youtu.be/h3YJjVDcNvI
¡Eran otros tiempos! Hace 10 años cualquier red social era más informal y distendida de lo que son ahora. Los trolleos eran simpáticos, se captaban las ironías, etc. Había que venir llorado de casa . Y las disputas más salvajes se solventaban en las quedadas, ¿recuerdas?
Ha cambiado mucho. Las redes sociales se usan para ofenderse, nadie entiende el sarcasmo ni el humor negro, y los trolleos "benignos" han degenerado en campañas de acoso y boicot. La autocensura limita la difusión de ideas controvertidas...
Menéame ya no es lo que era (de hecho, Menéame nunca fue lo que era)
@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.
@Paumal Más que una queja, que sería absurdo a estas alturas, era una forma de expresar mi pena por que cayera una historia bonita. Pero vamos, ni que hubiera dicho "Jehová" @visualito@Berlusconi@elwing (PD. Gracias por refereciarme )
Vengo a desmentir que @gallir y @benjami hayan pagado alguna vez a los admins con sobres de dinero B. El dinero siempre fue A y venía en maletines dada la cuantía.
¡Eran otros tiempos! Hace 10 años cualquier red social era más informal y distendida de lo que son ahora. Los trolleos eran simpáticos, se captaban las ironías, etc. Había que venir llorado de casa
Ha cambiado mucho. Las redes sociales se usan para ofenderse, nadie entiende el sarcasmo
Menéame ya no es lo que era
Enlazar sigue sin ser delito. Besis a los trolls.
¡Saludos!
> 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.
Eso fue... ¿ayer?
-1 a @lamonjamellada y @samarkanda: ¡Volved a vuestro tráiler, camioneras!
Saludos.