form create regex validation authentication passwords

regex - create - element drupal 8



Referencia-Validación de contraseña (1)

Muy a menudo, las preguntas (especialmente las expresiones regex etiquetadas) piden formas de validar las contraseñas. Parece que los usuarios suelen buscar métodos de validación de contraseña que consisten en garantizar que una contraseña contenga caracteres específicos, coincida con un patrón específico y / o obedezca un recuento mínimo de caracteres. Esta publicación está destinada a ayudar a los usuarios a encontrar los métodos adecuados para la validación de la contraseña sin disminuir en gran medida la seguridad.

Entonces la pregunta es: ¿cómo se debe validar correctamente las contraseñas?

¿Por qué las reglas de validación de contraseña son malas?

Nuestro propio Jeff Atwood (bloguero de Coding Horror y cofundador de y Stack Exchange) escribió un blog sobre las reglas de contraseña en marzo de 2017 titulado Password Rules are Bullshit . Si no ha leído esta publicación, le recomiendo que lo haga, ya que refleja en gran medida la intención de esta publicación.

Si nunca ha oído hablar del NIST (Instituto Nacional de Estándares y Tecnología) , es probable que no esté utilizando los métodos de ciberseguridad correctos para sus proyectos. En ese caso, eche un vistazo a sus Pautas de identidad digital . También debe mantenerse actualizado sobre las mejores prácticas para la ciberseguridad. La publicación especial NIST 800-63B (Revisión 3) menciona lo siguiente sobre las reglas de contraseña:

Los verificadores NO DEBEN imponer otras reglas de composición (por ejemplo, que requieran mezclas de diferentes tipos de caracteres o que prohíban caracteres repetidos consecutivamente) para los secretos memorizados.

Incluso la documentación de Mozilla sobre validación de datos de formularios se burla de las reglas de contraseña ( página archivada aquí ):

"Su contraseña debe tener entre 8 y 30 caracteres y contener una letra mayúscula, un símbolo y un número" (¿en serio?)

¿Qué sucede si impone reglas de composición para sus contraseñas? Está limitando la cantidad de contraseñas potenciales y eliminando las permutaciones de contraseña que no coinciden con sus reglas. ¡Esto permite a los hackers asegurarse de que sus ataques hagan lo mismo! "Sí, pero hay como un billón (1,000,000,000,000,000 o 1x10 15 ) de permutaciones de contraseña" : el clúster de 25 GPU descifra cada contraseña estándar de Windows en <6 horas (95 8 = 6,634,204,312,890,625 ~ 6.6x10 15 contraseñas).

Esta publicación de seguridad de StackExchange extiende el cómic XKCD anterior.

¿Cómo valido las contraseñas?

1. No cree su propia autenticación

Deje de requerir contraseñas por completo y permita que las personas inicien sesión con Google, Facebook, Twitter, Yahoo o cualquier otra forma válida de licencia de conducir de Internet con la que se sienta cómodo. La mejor contraseña es una que no tiene que almacenar .

Fuente: Su contraseña es demasiado corta por Jeff Atwood.

2. Creando tu propia autenticación

Si realmente debe crear sus propios métodos de autenticación, al menos siga los métodos probados de ciberseguridad. Las siguientes dos secciones (2.1 y 2.2) están tomadas de la publicación actual del NIST , sección 5.1.1.2 Verificadores secretos memorizados .

2.1. Siga los métodos PROBADOS de ciberseguridad

NIST declara que DEBERÍA :

  • Exigir que los secretos memorizados elegidos por el suscriptor tengan al menos 8 caracteres de longitud.
    • Jeff Atwood propone que las contraseñas deben tener un mínimo de 10 caracteres para usuarios normales y un mínimo de 15 caracteres para usuarios con mayores privilegios (es decir, administradores y moderadores).
  • Permita secretos memorizados elegidos por el suscriptor de hasta 64 caracteres o más de longitud.
    • Idealmente, ni siquiera deberías poner un límite superior a esto.
  • Permita todas las impresiones ASCII (incluido el carácter de espacio) y Unicode.
    • A los fines de los requisitos de longitud, cada punto de código Unicode DEBERÁ contarse como un solo carácter.
  • Compare los posibles secretos con una lista que contiene valores conocidos por ser de uso común, esperados o comprometidos. Por ejemplo:
    • Contraseñas obtenidas de cuerpos de infracción anteriores.
    • Diccionario de palabras.
    • Caracteres repetitivos o secuenciales (p. Ej. 1234abcd , 1234abcd )
    • Palabras específicas del contexto, como el nombre del servicio, el nombre de usuario y sus derivados.
  • Ofrecer orientación al suscriptor, como un medidor de seguridad de contraseña.
  • Implemente un mecanismo de limitación de velocidad que limite efectivamente la cantidad de intentos fallidos de autenticación que se pueden realizar en la cuenta del suscriptor (consulte Limitación de velocidad (limitación) ).
  • Forzar un cambio si hay evidencia de compromiso del autenticador.
  • Permita que los reclamantes utilicen la funcionalidad de pegar al ingresar un secreto memorizado (facilita el uso de administradores de contraseñas, lo que generalmente aumenta la probabilidad de que los usuarios elijan secretos memorizados más fuertes)

2.2. ¡NO use ninguno de los métodos de esta sección!

La misma publicación también establece que NO DEBE :

  • Truncar el secreto.
  • Permita que el suscriptor almacene una sugerencia que sea accesible para un reclamante no autenticado.
  • Solicite a los suscriptores que usen tipos específicos de información (por ejemplo, "¿Cuál era el nombre de su primera mascota?") Al elegir secretos memorizados.
  • Imponer otras reglas de composición (p. Ej., Requerir mezclas de diferentes tipos de caracteres o prohibir caracteres repetidos consecutivamente) para los secretos memorizados.
  • Exigir que los secretos memorizados se cambien arbitrariamente (por ejemplo, periódicamente).

Hay una gran cantidad de sitios web que explican cómo crear formularios de validación de contraseña "adecuados" : la mayoría de ellos están desactualizados y no deben usarse.

3. Uso de la entropía de contraseña

Antes de continuar leyendo esta sección, tenga en cuenta que la intención de esta sección no es brindarle las herramientas necesarias para implementar su propio esquema de seguridad , sino brindarle información sobre cómo los métodos de seguridad actuales validan las contraseñas. Si está considerando crear su propio esquema de seguridad, debería pensar tres veces y leer este artículo de la comunidad de seguridad de StackExchange.

3.1. Descripción general de la entropía de contraseña

En el nivel más básico, la entropía de contraseña se puede calcular utilizando la siguiente fórmula:

En la fórmula anterior:

  • representa la entropía de contraseña
  • es el número de caracteres en el grupo de caracteres únicos
  • es el número de caracteres en la contraseña

Esto significa que representa el número de contraseñas posibles; o, en términos de entropía, el número de intentos necesarios para agotar todas las posibilidades.

Desafortunadamente, lo que esta fórmula no considera son cosas como:

  • Contraseñas genéricas: es decir, Password1 , admin
  • Nombres: es decir, John , Mary
  • Palabras de uso común: es decir, en el idioma inglés, I
  • Palabras invertidas / invertidas: es decir, drowssap (contraseña al revés)
  • Sustitución de letras (también conocido como leet): es decir, P@$$w0rd

Agregar lógica para estas consideraciones adicionales presenta un gran desafío. Consulte 3.2 para ver los paquetes existentes que puede agregar a sus proyectos.

3.2. Proyectos existentes de entropía de contraseñas

Al momento de escribir esto, la biblioteca existente más conocida para estimar la seguridad de la contraseña es zxcvbn de Dropbox (un proyecto de código abierto en GitHub). Se ha adaptado para admitir .net angularjs c c# c ++ go java javascript objective-c ocaml php python rest ruby rust scala

Haciéndolo de la manera incorrecta

Sin embargo, entiendo que todos tienen requisitos diferentes y que a veces las personas quieren hacer las cosas de manera incorrecta. Para aquellos de ustedes que cumplen con este criterio (o que no tienen otra opción y han presentado todo lo que se encuentra arriba de esta sección y más a su gerente pero se niegan a actualizar sus métodos), al menos permitan los caracteres Unicode. En el momento en que limite los caracteres de la contraseña a un conjunto específico de caracteres (es decir, asegurarse de que exista un carácter ASCII en minúsculas az o especificar caracteres que el usuario puede o no puede ingresar !@#$%^&*() ), Solo está solicitando ¡problema!

PD: Nunca confíe en la validación del lado del cliente, ya que puede deshabilitarse muy fácilmente. Eso significa para aquellos de ustedes que intentan validar las contraseñas con javascript STOP . Consulte JavaScript: validación del lado del cliente frente al lado del servidor para obtener más información.

El siguiente patrón de expresión regular no funciona en todos los lenguajes de programación, pero sí en muchos de los principales lenguajes de programación ( java .net php perl ruby ). Tenga en cuenta que la siguiente expresión regular puede no funcionar en su idioma (o incluso en la versión de idioma) y es posible que necesite usar alternativas (es decir, python : consulte Python regex que coincide con las propiedades Unicode ). Algunos lenguajes de programación incluso tienen mejores métodos para verificar este tipo de cosas (es decir, usar el complemento de validación de contraseña para mysql ) en lugar de reinventar la rueda. Usando node.js lo siguiente es válido si usa el complemento XRegExp o alguna otra herramienta de conversión para clases Unicode como se discute en Javascript + expresiones regulares Unicode .

Si necesita evitar que se ingresen caracteres de control, puede avisar al usuario cuando se produce una coincidencia de expresiones regulares utilizando el patrón [^/P{C}/s] . Esto SOLO coincidirá con los caracteres de control que no son también espacios en blanco, es decir, pestaña horizontal, avance de línea, pestaña vertical.

La siguiente expresión regular asegura que exista al menos una letra minúscula, mayúscula, número y símbolo en una contraseña de más de 8 caracteres:

^(?=/P{Ll}*/p{Ll})(?=/P{Lu}*/p{Lu})(?=/P{N}*/p{N})(?=[/p{L}/p{N}]*[^/p{L}/p{N}])[/s/S]{8,}$

  • ^ Afirmar la posición al comienzo de la línea.
  • (?=/P{Ll}*/p{Ll}) Asegúrese de que exista al menos una letra minúscula (en cualquier script).
  • (?=/P{Lu}*/p{Lu}) Asegúrese de que exista al menos una letra mayúscula (en cualquier script).
  • (?=/P{N}*/p{N}) Asegúrese de que exista al menos un carácter numérico (en cualquier secuencia de comandos).
  • (?=[/p{L}/p{N}]*[^/p{L}/p{N}]) Asegúrese de que al menos uno de los caracteres (en cualquier script) no sea una letra o un dígito existe
  • [/s/S]{8,} Coincide con cualquier personaje 8 o más veces.
  • $ Afirmar posición al final de la línea.

Utilice la expresión regular anterior a su propio criterio. ¡Usted ha sido advertido!