¿Está bien usar la clave principal como el salt en una tabla de Usuarios?
La única desventaja que puedo ver es si la PK cambia (es poco probable), entonces se rompen las contraseñas.
¿Cuáles son tus pensamientos?
¿Está bien usar la clave principal como el salt en una tabla de Usuarios?
La única desventaja que puedo ver es si la PK cambia (es poco probable), entonces se rompen las contraseñas.
¿Cuáles son tus pensamientos?
No veo problemas inmediatos con ese enfoque. Especialmente si utiliza una sal por sitio web además de una sal por usuario. Para que tu sal combinada sea lo suficientemente compleja. La función principal de un salt en el hashing de contraseñas es evitar las tablas de arco iris. Y no necesitas una sal altamente aleatoria para eso.
Todavía no lo haría de esa manera, ya que usar una sal aleatoria es una práctica estándar. E inventar tu propio cripto suele ser una mala idea, porque es fácil equivocarse. Así que simplemente seguiría la práctica estándar a menos que haya una buena razón para no hacerlo.
OMI, es más importante usar una función de Desactivación de clave con suficientes iteraciones para disminuir los ataques de fuerza bruta que preocuparse por la aleatoriedad de su sal. Tener algo de sal es esencial, pero solo una de las cosas que necesitas.
La sal siempre debe contener bits aleatorios generados por un método criptográficamente sólido. La clave principal es todo menos aleatoria; ¡No lo hagas!
EDITAR: Lo que estoy tratando de resolver aquí es que su clave principal por sí sola no contendrá suficiente entropía. Es posible generar una tabla de arco iris separada para cada valor de sal. Su sal debe contener suficientes bits de entropía, por lo que no es posible generar tablas suficientes para permitir que un atacante precaliente sus hashes.
¿Está bien usar la clave principal como el salt en una tabla de Usuarios?
puede ser aceptable, en pocas ocasiones, pero aun así es poco probable que ofrezca beneficios reales. Básicamente, no hagas esto.
Las situaciones en las que podría estar bien son donde la clave principal es a) un valor grande, y b) un valor aleatorio. Un ejemplo de esto podría ser un UUID Tipo 4 se utiliza como clave principal.
El único beneficio que obtendría de esto es guardar unos pocos bytes por usuario. Esto es completamente insignificante, ningún motor de base de datos actual notaría este ahorro, incluso si tiene millones de usuarios.
Sin embargo, existen importantes inconvenientes en el uso de la clave principal como sal, en las áreas de seguridad y necesidades de desarrollo de software:
En el desarrollo de software:
Los buenos equipos de desarrollo usarán un OR / M , y a los buenos OR / M les gusta mucho Tener control exclusivo de la clave primaria. Esto abre buenas optimizaciones de rendimiento. Un ejemplo es el algoritmo NHibernate Hi / Lo , que permite a NHibernate 'escribir de forma perezosa' a la base de datos, acelerando las cosas.
A las buenas bases de datos también les gusta tener el control exclusivo de la clave principal. Y a menudo estructuran su archivos de datos por la clave principal , lo que conduce a importantes mejoras de rendimiento con la clave principal correcta.
Muchas bases de datos, como la clave principal, son pequeñas, para un entero de 32 bits, porque la clave principal suele incluirse en los índices que se encuentran en la RAM.
En seguridad:
Respuesta final: Depende de lo que realmente estés utilizando para la clave principal . Pero en casi todos los casos, esta es una mala idea.
¿Está bien usar la clave principal como el salt en una tabla de Usuarios?
Definitivamente, no está bien . Utilice un sal aleatoria para cada usuario. Utilice blowfish (el estándar) o algo equivalente.
Además de aceptar una sal aleatoria, el pez globo es adaptive , lo que significa que puedes hacerlo Más largo para calcular a medida que las CPU se vuelven más rápidas.
Editar: lo siento, me equivoqué: pensé en la "clave principal" como un tipo de clave privada del servidor (por ejemplo, en un contexto HTTPS), no en el significado de la base de datos SQL. Sin embargo, la clave principal de la base de datos aún es única en esa base de datos , pero si el software se usa en varias instalaciones de servidores distintas, es probable que en todos ellos aparezcan los mismos valores de "clave principal". Por lo tanto, aún se prefiere una sal aleatoria (larga), en lo que respecta a la seguridad (la aleatoriedad asegura la singularidad con alta probabilidad, si la sal es lo suficientemente grande, por ejemplo, de 16 bytes o más).
Respuesta original:
No está bien. La sal será única por instancia: cada contraseña con hash para cada usuario debe tener su propio valor de sal. Ese es el punto central de la sal: ser tal que cada contraseña se revisa con un esquema específico, distinto de la forma en que se hacen otras contraseñas, de modo que un atacante no puede compartir los costos de ataque a través de varias contraseñas atacadas.Por otro lado, la sal no necesita ser secreta (de lo contrario se llamaría una "clave"). Es posible tener un esquema de hashing de contraseñas que dependa de una clave (básicamente, MAC ) pero esto implica una amenaza diferente. modelo, en particular con la gestión de claves, que se sabe que es un problema difícil. Utilice una sal aleatoria por contraseña, almacenada a lo largo de la contraseña con hash, sin ninguna clave, y estará más contento.
No recomendaría el uso de la clave principal como la sal. Esa práctica es frágil.
Los buenos diseños deben ser robustos y sin mantenimiento. Los sistemas no son estáticos; a menudo necesitamos mantenerlos a lo largo del tiempo, agregar nuevas funciones, corregir errores, mejorar el rendimiento, etc.
Usar la clave principal como sal es una mala práctica porque hace que la seguridad dependa de algo que está fuera de nuestro control. No hay garantía de que una clave principal sea impredecible y tenga suficiente entropía para una sal; los requisitos para una sal (unicidad en los sitios, impredecible) son diferentes y un superconjunto de los requisitos para una clave principal (unicidad dentro de una sola base de datos). Usar una clave principal para un propósito para el cual no fue diseñado parece imprudente.
Incluso si el uso de la clave principal como sal es seguro cuando se implementa inicialmente, sería fácil que se vuelva inseguro en algún momento en el futuro, ya que el software se mantiene. Supongamos que la base de datos o la aplicación cambia la forma en que elige las claves primarias. Esto podría no afectar la corrección de la base de datos y podría parecer un cambio inocuo para algunos diseñadores de bases de datos o desarrolladores de software, pero podría reducir sutilmente la seguridad de la creación de su contraseña.
Para ser claro, no veo esto como una violación atroz. Si lo viera en una aplicación existente, no saltaría para corregirlo ahora, ahora, ahora. Pero si está escribiendo una nueva aplicación, parece una mala práctica y no lo recomendaría. Es demasiado inteligente por la mitad.
Lea otras preguntas en las etiquetas passwords cryptography encryption