La mejor manera de almacenar la contraseña en sql

Question

en mi contraseña actual de la aplicación de Windows C# se ha almacenado en texto sin formato, lo que obviamente no es bueno. así que solo quiero saber cuál es la mejor manera de encriptar la contraseña y almacenarla en SQL Server. He leído que usar hash + sal es mejor. pero creo que es mejor utilizar "EncryptByPassPhrase", "DecryptByPassPhrase" nueva característica en sql 2005 porque está manejando todo desde SQL Server y supongo que usa triple DES. ¿alguien puede sugerir que es bueno usarlo?

Answer 1

A hash & sal es el camino a seguir, porque es imposible recuperar la contraseña original de la misma. Si cifra, descifre la contraseña, la contraseña de texto plano se puede recuperar, por lo que no es la mejor.

Answer 2

Acepto que tiene sentido tener el encriptado todo en 1 lugar. Sin embargo, si separa la clave de los datos (clave en el código C#, datos en el db), eso aumentará la seguridad. Además, el servidor Sql utiliza una clave maestra al encriptar, lo que significa que si necesita restaurar los datos a un nuevo servidor, tendrá problemas para restaurar los datos.

Todo se reduce a la administración de claves y cómo desea hacer esto.

Answer 3

¿Necesita tener acceso a la contraseña original, o simplemente va a tratar de comparar una contraseña ingresada con una en la base de datos?

Si necesita acceder a la contraseña original, entonces tendrá que usar un algoritmo de cifrado en lugar de un algoritmo hash.

Si todo lo que hace es almacenar una contraseña en la base de datos para que pueda verificarla más tarde contra un valor de entrada conocido, entonces funcionará un hash con sal.

Recuerde que cuando el cliente envía las credenciales para ser validadas, ¡no desea enviar la contraseña en texto sin cifrar!

Answer 4

Como con la mayoría de las preguntas, la mejor respuesta depende del contexto de su situación. No hay una buena solución.

Algunas opciones:

1. dejar la contraseña en texto plano o cifrar reversably. Utilice las funciones de SQLServer para encriptar campos importantes en el nivel RDBMS o use funciones similares de cifrado y espere que MS haya implementado una administración de claves razonable y las claves sean razonablemente seguras para sus propósitos. En la práctica, todo encriptamiento hace es colapsar el almacenamiento de un montón de pequeños secretos en el almacenamiento de un gran secreto. Podría hacer que el problema sea más manejable, pero el problema en sí mismo nunca desaparece.

2. Irremediablemente, "Cifre" la contraseña utilizando un algoritmo hash o alguna forma de crypt(). Dependiendo de los vectores de ataque disponibles, este método puede no proporcionar mucho en el camino de la mejora real de la seguridad sobre el almacenamiento de texto sin formato.

. El uso de contraseñas hash limita sus opciones en términos de selección de un algoritmo de autenticación segura. Con este enfoque, es probable que termine enviando textos simples u otro material que no sea mejor que un transporte (independientemente de si se utiliza el cifrado no vinculado o no), esto puede ser un riesgo sustancial de un POV de confianza.

. Aceptable para el ataque de diccionario sin conexión si se roban hashes, la recuperación de una parte de las contraseñas debe asumirse directamente si tienen algún valor para un atacante.

. En algunos casos, el conocimiento del hash de la contraseña puede ser tan malo como conocer la contraseña en términos de acceso al sistema.

Answer 5

Si está seguro de que nunca usará un esquema hash para autenticarse (como HTTP Digest Auth), la contraseña hash es más segura. Para evitar el ataque de la tabla del arco iris, use un nonce (o sal). Yo usaría HMAC-SHA1 y usaría el nonce como clave. La clave debe almacenarse con la contraseña.

De lo contrario, tendrá que almacenar la contraseña cifrada porque la contraseña hash no puede funcionar con la autenticación que implica hashes. Para el cifrado, tengo las siguientes sugerencias,

1. No almacene la clave en DB, tampoco la codifique. Guárdelo en otro lugar seguro, como usar DPAPI en Windows.
2. Asegúrese de tener una versión de llave para poder girar la llave y cumplir con ciertos estándares.
3. No estoy familiarizado con el cifrado en SQLServer. Asegúrese de que tenga un Vector inicial aleatorio. Puede verificar esto encriptando la misma contraseña dos veces, debe producir texto cifrado diferente. Si no hay IV aleatorio, no lo use, solo cifrelo en su aplicación.