2011-08-18 9 views
5

He estado dando vueltas por la cuestión de cómo almacenar las contraseñas en mi base de datos desde hace un tiempo. Esta es la primera vez que hago una aplicación segura con un inicio de sesión web, por lo que quería establecer algunas buenas prácticas.Hashing y salazón de un campo de contraseña

Primero, leo sobre hash y salazón. Parece que la idea es ...

  1. Get algoritmo de hash
  2. obtener la contraseña de usuario
  3. Add 'sal' a contraseña en texto plano de usuario
  4. hash de la contraseña completa (incluyendo sal)
  5. tienda de la sal en el PP para que pueda recuperarlo más tarde (para la verificación de PSWD)

Y eso me hizo pensar ... Si un hacker conoce su sal (b Debido a que está almacenado en la base de datos en algún lugar, tal vez una columna llamada this_is_not_the_salt_ur_looking_for o algo igualmente ambiguo, pueden volver a generar el diccionario de contraseñas y obtener acceso.

Entonces tuve una idea. ¿Qué pasa si almacenó su sal dentro de el campo de contraseña hash. Así que siga los pasos 1-4 (generación aleatoria de la sal), entonces en el paso 5, insertar la sal en la contraseña en algún lugar conocido por la clase de interpretación contraseña o servicio:

xxxxxsaltvaluexxxxxxxxxxxxxxxx

donde x es los valores de cadena hash . ¿Alguien puede ver algún problema con esto? ¿Es completamente innecesario?

Respuesta:
No hay ninguna razón por la cual no podía hacerse de esta. Como dice Yahia, otros métodos para asegurar una contraseña incluyen doble (o n) hash. En otra nota, BCrypt parece un buen método para detener los ataques de fuerza bruta casi por completo, pero no pude encontrar una biblioteca confiable para C#

¡Gracias!
TTD

+0

He estado pensando en esto yo mismo, gracias por preguntar al respecto . –

Respuesta

6

Desde el punto de vista de seguridad que no es necesario, siempre y sólo se almacena el hash de la contraseña (NUNCA tienda de la contraseña sin cifrar!), Además de la sal ...un atacante es "permitido" para conocer la sal: su seguridad debe diseñarse de manera que incluso con el conocimiento de la sal siga siendo segura.

¿Qué hace la sal?

La sal ayuda a defenderse contra los ataques de fuerza bruta utilizando "tablas arcoiris" precalculadas.
La sal hace que la fuerza bruta sea mucho más cara (en términos de tiempo/memoria) para el atacante.
El cálculo de dicha tabla es costoso y, por lo general, solo se realiza cuando puede utilizarse para más de un ataque/contraseña.
SI utiliza la misma sal para todas las contraseñas, un atacante podría precomputar dicha tabla y luego aplicar fuerza bruta a sus contraseñas en texto sin formato ...
Siempre que genere una nueva (mejor criptográficamente fuerte) sal aleatoria para cada contraseña que desea almacenar el hash de no hay problema.

cuanto a su idea de "disfrazar" la sal
Eso es más de "seguridad por oscuridad" que debe ser evitado.
Aunque en este caso no veo ningún efecto positivo ni negativo.

SI desea reforzar aún más la seguridad
Se podría calcular el hash varias veces (hash de la almohadilla, etc.) - esto no le costará mucho, pero hace un ataque de fuerza bruta/cálculo "tablas arcoiris" aún más costosas ... por favor no invente usted mismo - existen métodos estándar probados para hacerlo, vea por ejemplo http://en.wikipedia.org/wiki/PBKDF2 y http://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes.aspx

+0

¿Dónde almacenaría la sal, en la BD, en el software, en un archivo de configuración ...? Usted dice que al atacante se le permite conocer la sal, por lo que tal vez no importa dónde se almacena, ya que no hay beneficio en saber qué es, ¿o no? – GeoffM

+0

Lo almacenaría en la Base de Datos ... si quieres hacerlo (un poco) más difícil para un atacante, podrías almacenar la sal y el hash en diferentes tablas – Yahia

+0

Entendido, gracias. – GeoffM

3

Estás a punto de caer en un agujero de conejo. Use bcrypt.

+0

Gracias por el aviso, pero estaba buscando el método de ocultar la sal, por lo que un ataque de fuerza bruta es inútil a menos que el hacker sepa a qué índice de la contraseña comienza la sal y la longitud de la misma –

+0

+1 para interesante información sobre bcrypt. –

0

Simplemente haga clic en la Contraseña y guarde el valor Hash en su Base de datos, una vez que el Usuario inicie sesión nuevamente, calcule el valor Hash de la contraseña que enteres y lo compare con el guardado en su Base de Datos, no necesita saber contraseña. un pirata informático no podría obtener la contraseña si obtiene el Hashvalue.

Si usa Salting aumentará la seguridad al guardar el valor Salt and Hash al que pertenece, el valor final se calcula utilizando la sal generada combinada con la contraseña a partir de la cual se calculó el valor hash, la contraseña no se guarda en su base de datos, pero solo el valor Hash calculado, significa un evtl. Hacker no puede hacer nada con solo el valor Hash y la sal.

Leer this

+0

Me doy cuenta de que mi pregunta fue engañosa. Ya estoy utilizando la contraseña, estoy buscando un método para ocultar la sal almacenándola en un índice conocido dentro del campo de contraseña. Entonces, una contraseña de 16 caracteres con una sal de 6 caracteres tendría una longitud de 22 caracteres –

Cuestiones relacionadas