¿Regulaciones que especifican la longitud de la contraseña?

Creo que el Instituto Nacional de Estándares y Tecnología (NIST) publica la Línea de base de configuración del gobierno de los Estados Unidos ( USGCB , anteriormente conocido como Federal Desktop Core Configuration o FDCC) listas de comprobación , que especifican la complejidad de la contraseña, la vida útil y los requisitos de historial para las organizaciones federales de los EE. UU. Además, el Centro de Seguridad de Internet (CIS) publica puntos de referencia para varias plataformas, que incluyen recomendaciones similares.

Entre los dos, la marca más alta es:

• Mínimo de 12 caracteres.
• Al menos tres tipos de caracteres.
• Caducidad en 60 días.
• Duración mínima de 1 día.
• No se puede reutilizar dentro de las 24 contraseñas.
• Se pueden aplicar algunos requisitos adicionales específicos del SO.

Esos ajustes se aplican a nivel del sistema operativo. No estoy seguro de si alguna de las organizaciones tiene especificaciones similares específicamente orientadas a aplicaciones o sitios web, pero la mayoría de las organizaciones que están sujetas a ellas probablemente solo usarán los mismos requisitos que en el sistema operativo.

Una búsqueda en Google de cualquiera de los términos anteriores debería generar una gran cantidad de información. (Puedo agregar enlaces aquí yo mismo más tarde, o cualquier otra persona es libre de editarlos).

Para ser honesto, la "documentación oficial" de todos estos estándares está incompleta, y como CISSP en la industria es realmente molesta .

Cómo lo veo es que nadie lo aprobará si tiene vulnerabilidades conocidas en su software, punto. La autoridad para esto es los Equipos de Respuesta de Emergencia Comunitaria (CERT), y los CERT emiten números de CVE para las vulnerabilidades. Todos los CERTs utilizan el sistema Enumeración de debilidad común para clasificar las vulnerabilidades en el software.

Hay CWE-521 - Requisitos de contraseña débil que enumera lo siguiente:

1. Longitud mínima y máxima;
2. Requieren conjuntos de caracteres mixtos (alfa, numéricos, especiales, mayúsculas y minúsculas);
3. No contiene nombre de usuario;
4. Vencimiento;
5. Sin reutilización de contraseña.

Se debe tener en cuenta que el sistema CWE es un árbol, y el padre de CWE-521 es CWE-255 gestión de credenciales .

Ya que busca CUALQUIER organismo regulador, sea aplicable a usted o no, Departamento de Defensa Instrucción 8500.2 , estados de implementación de Aseguramiento de la información:

  

Para sistemas que utilizan un   ID de inicio de sesión como identificador individual, las contraseñas son, como mínimo, un caso sensible,   Mezcla de 8 caracteres de mayúsculas, minúsculas, números y caracteres especiales.   caracteres, incluido al menos uno de cada uno (por ejemplo, emPagd2!). Al menos cuatro personajes   debe cambiarse cuando se crea una nueva contraseña.

NIST SP 800-63b [en borrador] ahora proporciona una guía detallada para las contraseñas a diferentes niveles de autenticación.

  

Un Secreto Memorizado (a.k.a 'contraseña') DEBE tener al menos 8 caracteres   de longitud si es elegido por el suscriptor; secretos memorizados elegidos   Al azar por el CSP o el verificador DEBE tener al menos 6 caracteres en   longitud y PUEDE ser enteramente numérico.

La mayoría de las regulaciones federales son ambiguas a propósito. Dicen que debes estar seguro, pero no te dan instrucciones específicas sobre cómo hacerlo. PCI-DSS es un Contrato que debe firmar para hacer negocios con tarjetas de crédito. Debido a cosas como la Ley de informes crediticios justos que impone la carga de las transacciones con tarjetas de crédito robadas en las compañías de tarjetas de crédito, puede apostar a que su trasero será muy específico y mensurable.

Para responder a su pregunta directamente, no, no conozco ninguna otra regulación o contrato que especifique controles de seguridad medibles que no sean PCI-DSS. La mayoría de las respuestas enumeradas son cosas que usted / su empresa pueden prescribir, pero no son obligatorias . Se requieren PCI-DSS, HIPAA, SOX, GLBA dependiendo de si se trata de una tarjeta de crédito, información de salud, cotización pública o financiera. Puede haber algunas leyes legales o internacionales que debería tener en cuenta y esas pueden ser muy específicas y / o muy confusas. Especialmente en Canadá cuando intenta averiguar si tiene que hacer cumplir los controles de privacidad basados en las regulaciones nacionales, provinciales o algún ministerio a través del contrato.

La mejor regulación que he visto con respecto a la complejidad de las contraseñas se encuentra en las pautas de CIS a las que hacen referencia otras regulaciones. Pero incluso ellos dicen "La configuración que se muestra arriba es una posible política. Modifique estos valores para que se ajusten a las políticas de contraseña de su propia organización". Un ejemplo de aquí enlace

6.3.2 Establecer parámetros de requisitos de creación de contraseñas utilizando pam_pwquality (Scored)

Aplicabilidad del perfil:

• Nivel 1

Descripción: El módulo pam_pwquality comprueba la fortaleza de las contraseñas. Realiza comprobaciones, como asegurarse de que una contraseña no sea una palabra del diccionario, tiene una cierta longitud, contiene una mezcla de caracteres (por ejemplo, alfabeto, numérico, otros) y más. Las siguientes son definiciones de las opciones de pam_pwquality.so.

• try_first_pass: recupera la contraseña de un módulo PAM apilado anterior. Si no está disponible, pídale al usuario una contraseña.
• reintentar = 3: permite 3 intentos antes de devolver un error.

Las siguientes opciones se configuran en el archivo /etc/security/pwquality.conf:

• minlen = 14: la contraseña debe tener 14 caracteres o más
• dcredit = -1: proporcionar al menos 1 dígito
• ucredit = -1: proporcione al menos un carácter en mayúscula
• ocredit = -1: proporciona al menos un carácter especial
• lcredit = -1: proporciona al menos un carácter en minúscula