2010-05-20 13 views
6

Estoy buscando la forma más segura (pero factible) de administración de contraseñas en una aplicación web.Administración de contraseñas de aplicación web: hashing, salazón, etc.

En este momento, guardo la contraseña como hash. La cuenta de DB de la aplicación está restringida a la ejecución de procedimientos almacenados y autentico a los usuarios dando el nombre de usuario y la contraseña hash a un procedimiento almacenado que devuelve 1 (verdadero) o 0 (falso).

Por lo tanto, no existe la posibilidad de obtener la contraseña del servidor, incluso si tiene la cuenta de base de datos de la aplicación. Eso es lo que me gusta de esta solución. Pero para usar esto, el cliente debe enviar su contraseña a través de la web, o al menos un hash estático que podría ser atrapado.

así que vine a idea de usar un apretón de manos como esto:

  • cliente solicita el servidor para la sal.
  • Se da sal aleatoria al cliente y se almacena en el servidor para este único cliente.
  • cliente hace Hash (sal + contraseña) y devuelve este hash al servidor
  • Server hace Hash (sal + contraseña) y comprueba si la misma a continuación, desde el cliente

El uso de este apretón de manos hace que sea posible comprobar la contraseña sin enviarse a sí mismo o un hash estático de la misma. Solo un hash salado dinámico, que es diferente cada vez que el usuario inicia sesión => Altamente seguro.

Pero para este apretón de manos necesito la contraseña o al menos la contraseña hash de la base de datos. Pero esto permite que alguien obtenga al menos la contraseña hash y la fuerza bruta fuera de la aplicación.

¿Qué prefieres? ¿Mantener la contraseña dentro de DB y hacer algo allí (servidor seguro), o sacarla de DB y hacerlo afuera (transmisión segura)?

Gracias de antemano, Marcas

Respuesta

3

Su solución propuesta en realidad no se resuelve el problema. Sin embargo, el servidor debe saber la contraseña, por lo que tuvo que ser transferida en algún momento, lo cual era lo que quería evitar en primer lugar. De esta forma, solo evitará que se vuelva a enviar la contraseña cada vez, pero si alguien la atrapó la primera vez que se transfirió?

Creo que no debe reinventar la rueda :-) Use SSL para todas las conexiones y luego sus primeras soluciones funcionan bien. Incluso puede realizar el hashing en el lado del cliente, por lo que solo el hash se envía a través del canal seguro. Su servidor nunca sabrá la contraseña, y no tiene que ser así.

+1

De acuerdo, SSL debe ser lo suficientemente seguro. Definitivamente hash las contraseñas en la base de datos también, aunque MD5 es sospechoso en estos días, así que podría utilizar un algoritmo hash más seguro para hacer esto. El apretón de manos propuesto es similar al MS-CHAP, que también es sospechoso. –

+0

Tiene razón, pero creo que es menos probable que la contraseña se detecte por única vez, que una de las siguientes cientos o miles de veces que el usuario inicia sesión. Mi conexión es SSL menos, solo quería algo de seguridad adicional . En este momento utilizo FormsAuthentications construido en hash SHA1, pero necesito SHA-256 en otro lugar, así que creo que voy a cambiar a eso. ¿Cree que el procedimiento almacenado GetUser debe devolver la contraseña hash? ¿O simplemente devuelve null en su lugar? – Marks

+1

Cuando habla de "seguridad", siempre asume el peor de los casos. Usted supone que el atacante siempre está presente y explota todas las debilidades de su sistema con la máxima eficacia.En este sentido, no importa si puede leer su contraseña una o cien veces, lo cierto es que puede leerla. Sus clientes no quieren escucharlo decir "no es probable que un atacante pueda leer su contraseña" :-) Si su procedimiento almacenado devuelve el hash o 'null' depende de usted, el servidor debe estar protegido con otros medios para evitar el acceso remoto de todos modos (firewall, parches de seguridad, ...) –

Cuestiones relacionadas