Restricción de juego de caracteres de contraseña de usuario

Question

Trabajar en un sistema de inicio de sesión: el punto donde el cliente elige su contraseña para acceder al sitio.

Más allá de usar RegEx para garantizar que la contraseña sea lo suficientemente segura, normalmente en nuestro sistema todos los datos que terminarán en la base de datos se verifican contra la inyección, etc. y se aplica un conjunto de caracteres razonablemente restringido en todos los campos. Realmente no quiero un juego de caracteres particularmente restrictivo para la contraseña, ya que creo que es un poco anti-patrón en seguridad controlarlo demasiado.

Sin embargo, en el caso de la contraseña, la manipularé con un SHA-512 salado para insertar de todos modos, lo que plantea un puñado de preguntas:

• ¿Hay algún punto en restringir el juego de caracteres que el cliente puede usar en la contraseña, es decir, estoy expuesto a vulnerabilidades fuera de la inyección que supongo que el hash evitaría por completo?

• Debe haber aspectos negativos para un enfoque de permitir todo: puedo pensar en el hecho de que en el futuro lo que es una combinación inocente ahora podría convertirse en una peligrosa, es una preocupación real, y ¿hay otros que yo puede haber fallado?

• ¿Hay caracteres / cadenas que deben ser rechazados? ¿Podrían pasar por la protección nativa de ASP.NET de todos modos?

• Tal vez un poco más subjetivo, pero dado que es un hash SHA-512, ¿hay algún punto en restringir la longitud máxima de contraseña que el usuario puede elegir (dentro de parámetros razonables), suponiendo que una contraseña significativa tamaño / complejidad podría generar una advertencia para confirmar que desean configurarlo.

Gracias por su ayuda.

EDITAR: Esta es una aplicación web ASP.NET que accede a una base de datos MSSQL2008 usando ADO.NET (no LINQ / EF).

Answer 1

Hay pocas razones para preocuparse por los ataques de inserción de SQL a menos que en realidad esté insertando la contraseña en la base de datos en texto plano (¡Peligro, Will Robertson, Peligro!) e incluso si paramateriza la consulta no será una problema. Debe permitir [a-zA-Z0-9] más algún conjunto de caracteres especiales. Probablemente el único carácter para restringir es '& Lt;' que activará la advertencia de validación ASP.net. Existen varias herramientas divertidas para verificar la complejidad de la contraseña en el lado del cliente. Me gusta este . Proporciona algunos comentarios instantáneos al usuario mientras escribe.

Answer 2

Desde una perspectiva no inglesa: no debe haber restricciones en la contraseña.

Por ejemplo, ¿por qué restringir que un hablante de idioma japonés use el juego de caracteres ASCII de EE. UU.? ¿Y por qué un hablante francés no debe usar caracteres acentuados?

Dado que su hash se conserva correctamente, no hay ninguna razón técnica para restringirlo.

Answer 3

Dado que la contraseña está cifrada, se almacenará en la base de datos en formato decimal hexadecimal. Por lo tanto, no veo ningún punto de restringir el tipo de caracteres permitidos. Si quisiera usar una letra china en mi contraseña, debería poder hacerlo. Si he instalado una extensión para Firefox que genera bytes aleatorios y los usa para mis contraseñas, debería poder hacerlo. La lección aquí es no limitar las contraseñas de sus usuarios.

También tenga en cuenta que RegEx tiene un soporte unicode que es capaz de detectar si el usuario ha usado una letra de algún idioma. Eso puede ser útil cuando está validando la seguridad de la contraseña.