NIST SP 800-63b en Es PDF

Publicación especial NIST 800-63B
Directrices de identidad digital

Autenticación y gestión del ciclo de vida
Paul A. Grassi
James L. Fenton
Elaine M. Newton
Ray A. Perlner
Andrew R. Regenscheid
William E. Burr
Justin P. Richer
Autores de privacidad:
Naomi B. Lefkovitz
Jamie M. Danker
Autores de usabilidad:
Yee-Yin Choong
Kristen K. Greene
Mary F. Theofanos
Esta publicación está disponible de forma gratuita en:

https://doi.org/10.6028/NIST.SP.800-63b
Publicación especial NIST 800-63B
Directrices de identidad digital

Autenticación y gestión del ciclo de vida
Paul A. Grassi Ray A. Perlner

Elaine M. Newton Andrew R. Regenscheid
División de Ciberseguridad Aplicada División de seguridad informática
Laboratorio de tecnología de la información Laboratorio de tecnología de la información
James L. Fenton William E. Burr

Redes Altmode Dakota Consulting, Inc.
Los Altos, California Silver Spring, Maryland
Justin P. Richer
Ingeniería a medida
Billerica, Mass.
Autores de privacidad: Autores de usabilidad:

Naomi B. Lefkovitz Yee-Yin Choong
División de Ciberseguridad Aplicada Kristen K. Greene
Laboratorio de tecnología de la información División de acceso a la información
Laboratorio de tecnología de la información
Jamie M. Danker Mary F. Theofanos

Dirección Nacional de Protección y Programas Laboratorio de Medición de Material de la
Departamento de Seguridad Nacional Oficina de Datos e Informática

Junio de 2017
yo INCLUYE U PDATES A PARTIR DE 03-02-2020; PAGS EDAD VIII
Departamento de Comercio de EE. UU.

Wilbur L. Ross, Jr., Secretario
Instituto Nacional de Estándares y Tecnología

Kent Rochford, director interino del NIST y subsecretario de Comercio para Estándares y Tecnología
Autoridad
Esta publicación ha sido desarrollada por NIST de acuerdo con sus responsabilidades legales bajo la Ley Federal de
Modernización de Seguridad de la Información (FISMA) de 2014, 44 USC § 3551 et seq., Ley Pública (PL) 113-283. El NIST es
responsable de desarrollar estándares y pautas de seguridad de la información, incluidos los requisitos mínimos para los
sistemas federales, pero dichos estándares y pautas no se aplicarán a los sistemas de seguridad nacional sin la aprobación
expresa de los funcionarios federales correspondientes que ejerzan la autoridad política sobre dichos sistemas. Esta guía es
consistente con los requisitos de la Circular A-130 de la Oficina de Administración y Presupuesto (OMB).
Nada en esta publicación debe tomarse en contra de los estándares y pautas que el Secretario de Comercio hizo obligatorios
y vinculantes para las agencias federales bajo la autoridad legal. Estas pautas tampoco deben interpretarse como una
alteración o sustitución de las autoridades existentes del Secretario de Comercio, Director de la OMB o cualquier otro
funcionario federal. Esta publicación puede ser utilizada por organizaciones no gubernamentales de forma voluntaria y no
está sujeta a derechos de autor en los Estados Unidos. Sin embargo, el NIST agradecería la atribución.
Publicación especial 800-63B del Instituto Nacional de Estándares y Tecnología

Natl. Inst. Estar. Technol. Especificaciones. Publ. 800-63B, 79 páginas (junio de 2017)
CODEN: NSPUE2

En este documento se pueden identificar determinadas entidades comerciales, equipos o materiales para describir adecuadamente un procedimiento o
concepto experimental. Dicha identificación no pretende implicar una recomendación o aprobación por parte del NIST, ni tampoco que las entidades,
materiales o equipos sean necesariamente los mejores disponibles para ese propósito.
Puede haber referencias en esta publicación a otras publicaciones actualmente en desarrollo por NIST de acuerdo con sus responsabilidades estatutarias
asignadas. Las agencias federales pueden utilizar la información de esta publicación, incluidos los conceptos y las metodologías, incluso antes de completar
dichas publicaciones complementarias. Por lo tanto, hasta que se complete cada publicación, los requisitos, pautas y procedimientos actuales, cuando existan,
permanecen operativos. Para propósitos de planificación y transición, las agencias federales tal vez deseen seguir de cerca el desarrollo de estas nuevas
publicaciones por parte del NIST.
Se anima a las organizaciones a revisar todos los borradores de las publicaciones durante los períodos de comentarios públicos y proporcionar comentarios al NIST. Muchas
publicaciones de ciberseguridad del NIST, además de las mencionadas anteriormente, están disponibles en
http://csrc.nist.gov/publications .
Los comentarios sobre esta publicación pueden enviarse a:
Instituto Nacional de Estándares y Tecnología

Attn: Applied Cybersecurity Division, Information Technology Laboratory
100 Bureau Drive (Mail Stop 2000) Gaithersburg, MD 20899-2000
Email: dig-comments@nist.gov
Todos los comentarios están sujetos a divulgación bajo la Ley de Libertad de Información (FOIA).
NIST SP 800-63B re IGITAL yo DENTIDAD GRAMO UIDELINES:
UNA UTENTICACIÓN Y L IFECYCLE METRO ANAGEMENT
Informes sobre tecnología de sistemas informáticos
El Laboratorio de Tecnología de la Información (ITL) del Instituto Nacional de Estándares y Tecnología (NIST) promueve la
economía y el bienestar público de los Estados Unidos al proporcionar liderazgo técnico para la infraestructura de medición y
estándares de la nación. ITL desarrolla pruebas, métodos de prueba, datos de referencia, implementaciones de prueba de
concepto y análisis técnicos para avanzar en el desarrollo y uso productivo de la tecnología de la información. Las
responsabilidades de ITL incluyen el desarrollo de normas y pautas de gestión, administrativas, técnicas y físicas para la
seguridad y privacidad rentables de otra información que no sea la relacionada con la seguridad nacional en los sistemas de
información federales. La Publicación Especial de la serie 800 informa sobre la investigación, las directrices y los esfuerzos de
divulgación de ITL en la seguridad del sistema de información y sus actividades de colaboración con la industria.
Esta publicación está disponible de forma gratuita en: https://doi.org/10.6028/NIST.SP.800-63b
Resumen
Estas pautas proporcionan requisitos técnicos para las agencias federales que implementan servicios de identidad digital y no
pretenden restringir el desarrollo o uso de estándares fuera de este propósito. Estas directrices se centran en la autenticación de
sujetos que interactúan con sistemas gubernamentales a través de redes abiertas, estableciendo que un determinado reclamante es
un suscriptor que ha sido previamente autenticado. El resultado del proceso de autenticación puede ser utilizado localmente por el
sistema que realiza la autenticación o puede afirmarse en otro lugar en un sistema de identidad federado. Este documento define los
requisitos técnicos para cada uno de los tres niveles de garantía del autenticador. Esta publicación reemplaza las secciones
correspondientes de la Publicación especial de NIST (SP) 800-63-2.
Palabras clave
autenticación; proveedor de servicios de credenciales; autenticación digital; credenciales digitales; autenticación electrónica;
credenciales electrónicas, federación.
ii
Expresiones de gratitud
Los autores agradecen a Kaitlin Boeckl por sus contribuciones gráficas artísticas a todos los volúmenes de la suite SP
800-63 y las contribuciones de nuestros numerosos revisores, incluidos Joni Brennan del Consejo de Identificación y
Autenticación Digital de Canadá (DIACC), Kat Megas, Ellen Nadeau y Ben Piccarreta de NIST, y Ryan Galluzzo y
Danna Gabel O'Rourke de Deloitte & Touche LLP.
Los autores también quisieran agradecer el liderazgo intelectual y la innovación de los autores originales: Donna F. Dodson, W.
Timothy Polk, Sarbari Gupta y Emad A. Nabbus. Sin sus incansables esfuerzos, no hubiéramos tenido la increíble base desde
la cual evolucionar 800-63 hasta el documento que es hoy. Además, un agradecimiento especial al Grupo de Trabajo de
Autenticación Digital del Consejo Federal de Privacidad por las contribuciones al desarrollo de los requisitos y consideraciones
de privacidad.
Requisitos de notación y convenciones
Los términos “DEBE” y “NO DEBE” indicar los requisitos que se deben seguir estrictamente para cumplir con la publicación
y de los cuales no se permite ninguna desviación.
Los términos "DEBERÍA" y "NO DEBERÍA" indican que entre varias posibilidades se recomienda una como
particularmente adecuada, sin mencionar o excluir otras, o que se prefiere un determinado curso de acción pero no
necesariamente se requiere, o que (en forma negativa) una cierta posibilidad o curso de acción se desaconseja pero no se
prohíbe.
Los términos “PUEDE” y “NO NECESITA” indican un curso de acción permisible dentro de los límites de la publicación.
Los términos “PUEDE” y “NO PUEDE” indican una posibilidad o capacidad, ya sea material, física o causal o, en
sentido negativo, la ausencia de esa posibilidad o capacidad.
iii
Tabla de contenido
1 Propósito................................................. .................................................. ................ 1
2 Introducción ................................................. .................................................. ......... 2
3 Definiciones y abreviaturas ............................................... ............................... 4
4 Niveles de garantía del autenticador ............................................... ........................... 5
Nivel de garantía del autenticador 1 .............................................. ...................... 5
4.1.1 Tipos de autenticadores permitidos ............................................ ................. 5
4.1.2 Requisitos de autenticador y verificador ........................................... ... 6

4.1.3 Reautenticación .............................................. ..................................... 6
4.1.4 Controles de seguridad ............................................. ..................................... 6
4.1.5 Política de retención de registros ............................................ ......................... 6
4.2.3 Reautenticación .............................................. ..................................... 8
4.2.4 Controles de seguridad ............................................. ..................................... 8
4.2.5 Política de retención de registros ............................................ ......................... 8
4.3.3 Reautenticación .............................................. ................................... 10
4.3.4 Controles de seguridad ............................................. ................................... 10
4.3.5 Política de retención de registros ............................................ ....................... 10
Requisitos de privacidad ................................................ ................................... 10
Resumen de requisitos ............................................... ............................ 11
5 Requisitos de autenticador y verificador .............................................. ............ 13
Requisitos por tipo de autenticador .............................................. .............. 13
5.1.1 Secretos memorizados ............................................. ................................ 13
5.1.2 Buscar secretos ........................................... ...................................... 15
5.1.3 Dispositivos fuera de banda ......................................... ................................. dieciséis
5.1.4 Dispositivo OTP de factor único .......................................... ........................ 19
5.1.5 Dispositivos OTP multifactor .......................................... ........................ 20
5.1.6 Software criptográfico de factor único .......................................... ...... 22
iv
5.1.7 Dispositivos criptográficos de factor único .......................................... ....... 22
5.1.8 Software criptográfico multifactor .......................................... ........ 23
5.1.9 Dispositivos criptográficos multifactor .......................................... .......... 24
Requisitos generales del autenticador ............................................... ............. 25
5.2.1 Autenticadores físicos ............................................. ......................... 25
5.2.2 Limitación de velocidad (estrangulamiento) .......................................... .......................... 25
5.2.3 Uso de datos biométricos ............................................ ................................... 26
5.2.4 Atestación .............................................. ............................................ 28

5.2.5 Resistencia a la suplantación de identidad del verificador ............................................ .......... 28
5.2.6 Comunicaciones Verificador-CSP ........................................... ................. 29
5.2.7 Resistencia al compromiso del verificador ........................................... ............. 29
5.2.8 Resistencia a la repetición ............................................. ................................. 30
5.2.9 Intención de autenticación ............................................. .............................. 30
5.2.10 Autenticadores restringidos ............................................. ...................... 30
6 Gestión del ciclo de vida del autenticador ............................................... .................. 32
Enlace de autenticador ................................................ .................................... 32
6.1.1 Vinculante en el momento de la inscripción ............................................ ............................. 33
6.1.2 Encuadernación posterior a la inscripción ........................................... .......................... 34
6.1.3 Vinculación a un autenticador proporcionado por el suscriptor ................................. 35
6.1.4 Renovación .............................................. ............................................... 35
Pérdida, robo, daño y duplicación no autorizada .................................... 35
Vencimiento................................................. .................................................. ... 36
Revocación y terminación ............................................... .......................... 36
7 Gestión de sesiones ................................................ .......................................... 37
Enlaces de sesión ................................................ .......................................... 37
7.1.1 Cookies del navegador ............................................. ................................... 38
7.1.2 Tokens de acceso ............................................. ...................................... 38
7.1.3 Identificación del dispositivo ............................................. .............................. 38
Reautenticación ................................................. .......................................... 39
7.2.1 Reautorización de una federación o afirmación ............... 39
8 Amenazas y consideraciones de seguridad .............................................. ................... 41
Amenazas del autenticador ................................................ .................................... 41
Estrategias de mitigación de amenazas ............................................... ........................... 45
v
Recuperación del autenticador ................................................ ................................. 47
Ataques de sesión ................................................ ............................................ 47
9 Consideraciones de privacidad ................................................ ....................................... 48
Evaluación de riesgos de privacidad ............................................... ............................... 48
Controles de privacidad ................................................ ............................................ 48
Limitación de procesamiento ................................................ .................................... 48
48
Cumplimiento de privacidad específico de la agencia ............................................. ............... 49

10 Consideraciones de usabilidad ............................................... ...................................... 50
Consideraciones de usabilidad comunes a los autenticadores .................................... 51
Consideraciones de usabilidad por tipo de autenticador ... 53
10.2.1 Secretos memorizados .............................................. ............................... 53
10.2.2 Secretos de búsqueda ........................................... ...................................... 54
10.2.3 Fuera de banda .......................................... .............................................. 54
10.2.4 Dispositivo OTP de factor único .......................................... ........................ 54
10.2.5 Dispositivo OTP multifactor ........................................... ......................... 55
10.2.6 Software criptográfico de factor único .......................................... ...... 56
10.2.7 Dispositivo criptográfico de factor único .......................................... ......... 56
10.2.8 Software criptográfico multifactor ........................................... ....... 56
10.2.9 Dispositivo criptográfico multifactor ........................................... .......... 57
Resumen de consideraciones de usabilidad .............................................. ............. 57
Consideraciones de usabilidad biométrica ............................................... ............... 59
11 Referencias ................................................ .................................................. .......... 62
Referencias generales ................................................ ...................................... 62
Estándares ................................................. .................................................. .. 63
Publicaciones especiales del NIST ............................................... .............................. 64
Estándares federales de procesamiento de información .............................................. ..... sesenta y cinco
Lista de apendices
Apéndice A— Fortaleza de los secretos memorizados ........................................... .............. 67
A.1 Introducción .............................................. .................................................. ... 67
A.2 Longitud .............................................. .................................................. ........... 67
A.3 Complejidad .............................................. .................................................. .... 68
vi
A.4 Secretos elegidos al azar ........................................... ................................ 69
A.5 Resumen .............................................. .................................................. ...... 69
Lista de tablas
Tabla 2-1 Secciones normativas e informativas de SP 800-63B ..................................... .. 3
Tabla 4-1 Resumen de requisitos de AAL .......................................... .......................... 11
Tabla 8-1 Amenazas del autenticador ............................................ ........................................ 41
Tabla 8-2 Mitigación de las amenazas del autenticador ........................................... ......................... 45

vii
Errata
Esta tabla contiene cambios que se han incorporado a la Publicación especial 800-63B. Las actualizaciones de erratas pueden
incluir correcciones, aclaraciones u otros cambios menores en la publicación que sean de naturaleza editorial o sustantiva.
Fecha Tipo Cambio Ubicación

2017-12-01 Editorial Descripciones de AAL actualizadas para Introducción
coherencia con otro texto en el documento Eliminado
Editorial "criptográfico" para reflejar consistentemente las opciones §4.3
de autenticación en AAL3 Se refinaron los requisitos

Sustantivo sobre §4.4
procesamiento de atributos
Editorial Hacer coherente el lenguaje relacionado con los §5.1.5.1, 5.1.8.1 y
factores de activación para los autenticadores 5.1.9.1
multifactor
Sustantivo Reconocer el uso de hardware TPM como §5.1.7.1, 5.1.9.1

autenticador de cifrado de hardware
Editorial Mejorar el lenguaje normativo en canales §5.2.3
protegidos autenticados para biometría
Editorial Se cambió "transacción" a "transacción §6.1.1

vinculante" para enfatizar que el requisito no se
aplica a las transacciones de autenticación.
Editorial Se reemplazó la nota fuera de contexto al final de la §7.2

sección 7.2
Editorial Se cambió IdP a CSP para que coincida con la Tabla 8-1
terminología utilizada en otras partes de este
documento
Editorial Se corrigieron las mayúsculas en el ataque de la tabla 8-2 del canal lateral
Sustantivo Cambió el título a procesamiento §9.3

limitación; clarificó el lenguaje, incorporó
objetivos de privacidad
lenguaje, y especificó que el consentimiento es explícito
Editorial Se agregó NISTIR 8062 como referencia Título §11.1

Editorial corregido de SP 800-63C Texto aclarado del §11.3
2020-03-02 Sustantivo verificador §4.3.2
requisito de resistencia a la suplantación
Editorial Se enfatizó el uso de la llave desbloqueada por un §5.1.9.1
factor adicional para firmar nonce Proporcionó
Editorial ejemplos de observaciones de comportamiento §5.2.2
basadas en el riesgo
Editorial Frase redundante eliminada y conjunción §5.2.3

faltante agregada
Editorial URL actualizada para referencia [listas negras] §11.1
viii
1 Propósito
Esta sección es informativa.
Este documento y sus documentos complementarios, Publicación especial (SP) 800-63 , SP 800-63A y SP 800-63C , brindar
lineamientos técnicos a las agencias para la implementación de la autenticación digital.
1
2 Introducción
La identidad digital es la representación única de un sujeto involucrado en una transacción en línea. Una identidad digital es siempre
única en el contexto de un servicio digital, pero no necesariamente debe ser rastreable hasta un tema específico de la vida real. En
otras palabras, acceder a un servicio digital puede no significar que se conozca la representación en la vida real del sujeto subyacente.
La prueba de identidad establece que un sujeto es en realidad quien dice ser. La autenticación digital es el proceso de determinar la
validez de uno o más autenticadores utilizados para reclamar una identidad digital. La autenticación establece que un sujeto que
intenta acceder a un servicio digital tiene el control de las tecnologías utilizadas para autenticarse. Para los servicios en los que se
aplican las visitas posteriores, La autenticación exitosa proporciona garantías razonables basadas en el riesgo de que el sujeto que
accede al servicio hoy es el mismo que accedió al servicio anteriormente. La identidad digital presenta un desafío técnico porque a
menudo implica la verificación de personas a través de una red abierta y siempre implica la autenticación de personas a través de una
red abierta. Esto presenta múltiples oportunidades para la suplantación de identidad y otros ataques que pueden conducir a
afirmaciones fraudulentas de la identidad digital de un sujeto.
La autenticación continua de los suscriptores es fundamental para el proceso de asociar a un suscriptor con su actividad en línea.
La autenticación del suscriptor se realiza verificando que el reclamante controla uno o más autenticadores llamado tokens en
versiones anteriores de SP 800-63) asociado con un suscriptor determinado. Una autenticación exitosa da como resultado la
afirmación de un identificador, ya sea seudónimo o no seudónimo, y opcionalmente otra información de identidad, a la parte que
confía (RP).
Este documento proporciona recomendaciones sobre los tipos de procesos de autenticación, incluidas las opciones de autenticadores, que
se pueden utilizar en varios Niveles de garantía del autenticador ( AAL). También proporciona recomendaciones sobre el ciclo de vida de
los autenticadores, incluida la revocación en caso de pérdida o robo.
Esta directriz técnica se aplica a la autenticación digital de sujetos a sistemas a través de una red. No se refiere a la autenticación de una
persona para el acceso físico (por ejemplo, a un edificio), aunque algunas credenciales utilizadas para el acceso digital también pueden
utilizarse para la autenticación del acceso físico. Esta directriz técnica también requiere que los sistemas federales y los proveedores de
servicios que participan en los protocolos de autenticación se autentiquen ante los suscriptores.
La fuerza de una transacción de autenticación se caracteriza por una medida ordinal conocida como AAL. Una autenticación más
sólida (un AAL más alto) requiere que los actores malintencionados tengan mejores capacidades y gasten más recursos para
subvertir con éxito el proceso de autenticación. La autenticación en AAL más altos puede reducir eficazmente el riesgo de ataques.
A continuación se proporciona un resumen de alto nivel de los requisitos técnicos para cada uno de los AAL; ver Secciones 4 y 5 de
este documento para requisitos normativos específicos.
Nivel de garantía del autenticador 1: AAL1 proporciona cierta seguridad de que el reclamante controla un autenticador vinculado
a la cuenta del suscriptor. AAL1 requiere autenticación de factor único o de factor múltiple utilizando una amplia gama de
tecnologías de autenticación disponibles. Exitoso
2
La autenticación requiere que el reclamante demuestre la posesión y el control del autenticador a través de un protocolo de
autenticación seguro.
Nivel 2 de garantía del autenticador: AAL2 proporciona una gran confianza en que el reclamante controla los autenticadores
vinculados a la cuenta del suscriptor. Se requiere prueba de posesión y control de dos factores de autenticación diferentes a
través de protocolos de autenticación seguros. Se requieren técnicas criptográficas aprobadas en AAL2 y superior.
Nivel 3 de garantía del autenticador: AAL3 proporciona una confianza muy alta de que el reclamante controla los autenticadores
vinculados a la cuenta del suscriptor. La autenticación en AAL3 se basa en la prueba de posesión de una clave a través de un
protocolo criptográfico. La autenticación AAL3 requiere un autenticador basado en hardware y un autenticador que ofrezca
resistencia a la suplantación del verificador; el mismo dispositivo puede cumplir ambos requisitos. Para autenticarse en AAL3, los
reclamantes deben probar la posesión y el control de dos factores de autenticación distintos a través de protocolos de autenticación
seguros. Se requieren técnicas criptográficas aprobadas.
La siguiente tabla indica qué secciones del documento son normativas y cuáles informativas:
Tabla 2-1 Secciones normativas e informativas de SP 800-63B
Nombre de la sección Normativo / Informativo
1. Propósito Informativo
2. Introducción Informativo
3. Definiciones y abreviaturas Informativo
4. Niveles de garantía del autenticador Normativo
5. Requisitos de autenticador y verificador Normativo
6. Gestión del ciclo de vida del autenticador Normativo
7. Gestión de sesiones Normativo
8. Consideraciones sobre amenazas y seguridad Informativo
9. Consideraciones de privacidad Informativo
10. Consideraciones de usabilidad Informativo
11. Referencias Informativo
Apéndice A: Fuerza de memorizado

Informativo
Misterios
3
3 Definiciones y abreviaturas
Ver SP 800-63 , Apéndice A para un conjunto completo de definiciones y abreviaturas.

4
4 Niveles de garantía del autenticador
Esta sección contiene material tanto normativo como informativo.
Para satisfacer los requisitos de una AAL determinada, un reclamante DEBE estar autenticado con al menos un determinado nivel de fuerza
para ser reconocido como suscriptor. El resultado de un proceso de autenticación es un identificador que SE DEBE usar cada vez que el
suscriptor se autentica en ese RP. El identificador PUEDE tener un seudónimo. Los identificadores de suscriptor NO DEBEN ser reutilizados
para una asignatura diferente, pero DEBEN ser reutilizados cuando el CSP reinscribe a una asignatura previamente inscrita. También
PUEDEN proporcionarse otros atributos que identifican al suscriptor como un sujeto único.
Los requisitos normativos detallados para los autenticadores y verificadores en cada AAL se proporcionan en la Sección 5.
Ver SP 800-63 Sección 6.2 para obtener detalles sobre cómo elegir el AAL más apropiado. Los requisitos de FIPS 140 se
satisfacen mediante FIPS 140-2 o revisiones más recientes.
En IAL1, es posible que el servicio de identidad digital recopile y ponga a disposición los atributos. Cualquier PII u otra
información personal, ya sea autoafirmada o validada, requiere autenticación de múltiples factores. Por lo tanto, las agencias
DEBEN seleccionar un mínimo de AAL2 cuando la PII autoafirmada u otra información personal esté disponible en línea.
Nivel de garantía del autenticador 1
Esta sección es normativa.
AAL1 proporciona cierta seguridad de que el reclamante controla un autenticador vinculado a la cuenta del suscriptor. AAL1
requiere autenticación de un solo factor o de múltiples factores utilizando una amplia gama de tecnologías de autenticación
disponibles. La autenticación exitosa requiere que el reclamante demuestre la posesión y el control del autenticador a través de un
protocolo de autenticación seguro.
4.1.1 Tipos de autenticadores permitidos
La autenticación AAL1 DEBE ocurrir mediante el uso de cualquiera de los siguientes tipos de autenticadores, que se definen en Sección 5 :
• Secreto memorizado ( Sección 5.1.1 )

• Secreto de búsqueda ( Sección 5.1.2 )
• Dispositivos fuera de banda ( Sección 5.1.3 )

• Dispositivo de contraseña de un solo factor (OTP) ( Sección 5.1.4 )
• Dispositivo OTP multifactor ( Sección 5.1.5 )
• Software criptográfico de factor único ( Sección 5.1.6 )
• Dispositivo criptográfico de factor único ( Sección 5.1.7 )
• Software criptográfico multifactor ( Sección 5.1.8 )
• Dispositivo criptográfico multifactor ( Sección 5.1.9 )
5
4.1.2 Requisitos de autenticador y verificador
Los autenticadores criptográficos utilizados en AAL1 DEBERÁN utilizar criptografía aprobada. Los autenticadores basados en software
que operan dentro del contexto de un sistema operativo PUEDEN, cuando corresponda, intentar detectar el compromiso (por ejemplo, por
malware) del punto final del usuario en el que se están ejecutando y NO DEBERÍAN completar la operación cuando se detecta dicho
compromiso.
La comunicación entre el reclamante y el verificador (utilizando el canal principal en el caso de un autenticador fuera de banda)
DEBERÁ ser a través de un canal protegido autenticado para proporcionar confidencialidad de la salida del autenticador y
resistencia a man-in-the-middle (MitM) Ataques.
Los verificadores operados por agencias gubernamentales en AAL1 DEBEN ser validados para cumplir con los requisitos de FIPS
140 Nivel 1.
4.1.3 Reautenticación
La reautenticación periódica de las sesiones de los suscriptores DEBERÁ realizarse como se describe en Sección
7.2 . En AAL1, la reautenticación del suscriptor DEBE repetirse al menos una vez cada 30 días durante una sesión de uso extendido,
independientemente de la actividad del usuario. La sesión DEBE finalizar (es decir, cerrar la sesión) cuando se alcance este límite de
tiempo.
4.1.4 Controles de seguridad
El CSP DEBERÁ emplear controles de seguridad adaptados a la medida del bajo línea de base de los controles de seguridad definidos
en SP 800-53 o federal equivalente (por ejemplo, FEDRAMP ) o estándar de la industria. El CSP DEBERÁ garantizar que los controles
mínimos relacionados con la garantía bajo impacto los sistemas, o equivalentes, están satisfechos.
4.1.5 Política de retención de registros
El CSP deberá cumplir con sus respectivas políticas de retención de registros de acuerdo con las leyes, regulaciones y políticas
aplicables, incluido cualquier programa de retención de registros de la Administración Nacional de Archivos y Registros (NARA) que
pueda aplicarse. Si el CSP opta por conservar registros en ausencia de requisitos obligatorios, el CSP DEBERÁ realizar un proceso de
gestión de riesgos, incluidas evaluaciones de los riesgos de privacidad y seguridad, para determinar cuánto tiempo se deben conservar
los registros e DEBERÁ informar al suscriptor de esa política de retención.
Nivel de garantía del autenticador 2
AAL2 proporciona una gran confianza en que el reclamante controla los autenticadores vinculados a la cuenta del suscriptor.
Se requiere prueba de posesión y control de dos factores de autenticación distintos a través de protocolos de autenticación
seguros. Se requieren técnicas criptográficas aprobadas en AAL2 y superior.
6
En AAL2, la autenticación DEBE ocurrir mediante el uso de un autenticador multifactor o una combinación de dos autenticadores
de un solo factor. Un autenticador multifactor requiere dos factores para ejecutar un solo evento de autenticación, como un
dispositivo criptográficamente seguro con un sensor biométrico integrado que se requiere para activar el dispositivo. Los requisitos
del autenticador se especifican en Sección 5 .
Cuando se utiliza un autenticador multifactor, se PUEDE utilizar cualquiera de los siguientes:
• Dispositivo OTP multifactor ( Sección 5.1.5 )

• Software criptográfico multifactor ( Sección 5.1.8 )
Cuando se utiliza una combinación de dos autenticadores de un solo factor, DEBERÁ incluir un autenticador secreto
memorizado ( Sección 5.1.1 ) y un autenticador basado en posesión (es decir, "algo que tienes") de la siguiente lista:
• Secreto de búsqueda ( Sección 5.1.2 )
• Dispositivo fuera de banda ( Sección 5.1.3 )
• Dispositivo OTP de factor único ( Sección 5.1.4 )

• Software criptográfico de factor único ( Sección 5.1.6 )
• Dispositivo criptográfico de factor único ( Sección 5.1.7 )
Nota: Cuando la autenticación biométrica cumple los requisitos de Sección 5.2.3 , el dispositivo tiene que ser
autenticado además del biométrico - un biométrico se reconoce como un factor, pero no se reconoce como un
autenticador por sí mismo. Por lo tanto, al realizar la autenticación con un biométrico, no es necesario utilizar dos
autenticadores porque el dispositivo asociado sirve como "algo que tienes", mientras que el biométrico sirve como
"algo que eres".
Los autenticadores criptográficos utilizados en AAL2 DEBERÁN utilizar criptografía aprobada. Los autenticadores adquiridos por agencias
gubernamentales DEBEN ser validados para cumplir con los requisitos de FIPS 140 Nivel 1. Los autenticadores basados en software que
operan dentro del contexto de un sistema operativo PUEDEN, cuando corresponda, intentar detectar el compromiso de la plataforma en
la que se están ejecutando (por ejemplo, por malware) y NO DEBEN completar la operación cuando tal compromiso es detectado. Al
menos un autenticador utilizado en AAL2 DEBE ser resistente a la reproducción como se describe en Sección 5.2.8 . La autenticación en
AAL2 DEBE demostrar la intención de autenticación de al menos un autenticador como se describe en Sección 5.2.9 .
La comunicación entre el reclamante y el verificador (el canal principal en el caso de un autenticador fuera de banda) DEBERÁ ser
a través de un canal protegido autenticado para proporcionar confidencialidad de la salida del autenticador y resistencia a los
ataques MitM.
Los verificadores operados por agencias gubernamentales en AAL2 DEBEN ser validados para cumplir con los requisitos de FIPS
140 Nivel 1.
7
Cuando se utiliza un dispositivo, como un teléfono inteligente, en el proceso de autenticación, el desbloqueo de ese dispositivo (normalmente
realizado mediante un PIN o datos biométricos) NO DEBE considerarse uno de los factores de autenticación. Generalmente, un verificador
no puede saber que el dispositivo se ha bloqueado o si el proceso de desbloqueo cumplió con los requisitos para el tipo de autenticador
relevante.
Cuando se utiliza un factor biométrico en la autenticación en AAL2, los requisitos de rendimiento establecidos en Sección 5.2.3 DEBE
cumplirse, y el verificador DEBE tomar una determinación de que el sensor biométrico y el procesamiento posterior cumplen con
estos requisitos.
7.2 . En AAL2, la autenticación del suscriptor DEBE repetirse al menos una vez cada 12 horas durante una sesión de uso extendido,
independientemente de la actividad del usuario. La reautenticación del suscriptor DEBERÁ repetirse después de cualquier período de
inactividad que dure 30 minutos o más. La sesión DEBE finalizar (es decir, cerrar la sesión) cuando se alcance cualquiera de estos
límites de tiempo.
La reautenticación de una sesión que aún no ha alcanzado su límite de tiempo PUEDE requerir solo un secreto memorizado o un
biométrico junto con el secreto de sesión aún válido. El verificador PUEDE pedirle al usuario que provoque actividad justo antes
del tiempo de inactividad.
El CSP DEBERÁ emplear controles de seguridad adaptados a la medida del moderar línea de base de los controles de seguridad definidos
en SP 800-53 o federal equivalente (por ejemplo, FEDRAMP ) o estándar de la industria. El CSP DEBERÁ garantizar que los controles
mínimos relacionados con la garantía impacto moderado se satisfacen los sistemas o equivalentes.
aplicables, incluidos los programas de retención de registros de NARA que puedan aplicarse. Si el CSP opta por retener registros en
ausencia de requisitos obligatorios, el CSP DEBERÁ llevar a cabo un proceso de gestión de riesgos, incluidas evaluaciones de los
riesgos de privacidad y seguridad para determinar cuánto tiempo deben retenerse los registros e DEBERÁ informar al suscriptor de esa
política de retención.
Nivel 3 de garantía del autenticador
AAL3 proporciona una confianza muy alta de que el reclamante controla los autenticadores vinculados a la cuenta del suscriptor. La
autenticación en AAL3 se basa en la prueba de posesión de una clave a través de un protocolo criptográfico. La autenticación AAL3
DEBE utilizar un autenticador basado en hardware y un autenticador que proporcione resistencia a la suplantación del verificador; el
mismo dispositivo PUEDE cumplir ambos requisitos. Para autenticarse en AAL3, los reclamantes DEBEN demostrar la posesión y el
control de dos factores de autenticación distintos a través de protocolos de autenticación seguros. Se requieren técnicas
criptográficas aprobadas.
8
La autenticación AAL3 DEBE ocurrir mediante el uso de una combinación de autenticadores que satisfagan los requisitos
de la Sección 4.3. Las posibles combinaciones son:

• Dispositivo criptográfico de factor único ( Sección 5.1.7 ) utilizado junto con Memorized Secret ( Sección 5.1.1 )
• Dispositivo OTP multifactor (software o hardware) ( Sección 5.1.5 ) utilizado junto con un dispositivo criptográfico
de factor único ( Sección 5.1.7 )
• Dispositivo OTP multifactor (solo hardware) ( Sección 5.1.5 ) utilizado junto con un software criptográfico
de factor único ( Sección 5.1.6 )
• Dispositivo OTP de factor único (solo hardware) ( Sección 5.1.4 ) utilizado junto con un autenticador de
software criptográfico multifactor ( Sección 5.1.8 )
• Dispositivo OTP de factor único (solo hardware) ( Sección 5.1.4 ) utilizado junto con un autenticador de
software criptográfico de factor único ( Sección 5.1.6 ) y un secreto memorizado ( Sección 5.1.1 )
La comunicación entre el reclamante y el verificador DEBERÁ realizarse a través de un canal protegido autenticado para proporcionar
confidencialidad de la salida del autenticador y resistencia a los ataques MitM. Al menos un autenticador de dispositivo criptográfico utilizado en
AAL3 DEBERÁ ser resistente a la suplantación del verificador como se describe en Sección 5.2.5 y DEBERÁ ser resistente a la reproducción
como se describe en Sección
5.2.8 . Todos los procesos de autenticación y reautenticación en AAL3 DEBEN demostrar la intención de autenticación
de al menos un autenticador como se describe en Sección 5.2.9 .
Los autenticadores de múltiples factores utilizados en AAL3 DEBERÁN ser módulos criptográficos de hardware validados en FIPS 140 Nivel 2
o superior en general con al menos FIPS 140 Seguridad física de nivel 3. Los dispositivos criptográficos de factor único utilizados en AAL3
DEBEN ser validados en FIPS 140 Nivel 1 o superior en general con al menos FIPS 140 Seguridad física de nivel 3.
Los verificadores en AAL3 DEBEN ser validados en FIPS 140 Nivel 1 o superior.
Los verificadores en AAL3 DEBERÁN ser resistentes al compromiso de los verificadores como se describe en Sección 5.2.7 con respecto a al
menos un factor de autenticación.
Los autenticadores y verificadores basados en hardware en AAL3 DEBEN resistir los ataques de canal lateral relevantes (por ejemplo, análisis
de tiempo y consumo de energía). Los ataques de canal lateral relevantes DEBERÁN determinarse mediante una evaluación de riesgos realizada
por el CSP.
Cuando se utiliza un dispositivo como un teléfono inteligente en el proceso de autenticación, asumiendo que el dispositivo puede
cumplir con los requisitos anteriores, NO se considerará que el desbloqueo de ese dispositivo satisface uno de los factores de
autenticación. Esto se debe a que, en general, el verificador no puede saber que el dispositivo se ha bloqueado ni si el proceso de
desbloqueo cumplió con los requisitos del tipo de autenticador correspondiente.
9
Cuando se utiliza un factor biométrico en la autenticación en AAL3, el verificador DEBE determinar que el sensor
biométrico y el procesamiento posterior cumplen con los requisitos de rendimiento establecidos en Sección 5.2.3 .
7.2. En AAL3, la autenticación del suscriptor DEBE repetirse al menos una vez cada 12 horas durante una sesión de uso extendido,
independientemente de la actividad del usuario, como se describe en Sección 7.2 . La reautenticación del suscriptor DEBERÁ repetirse
después de cualquier período de inactividad que dure 15 minutos o más. La reautenticación DEBE utilizar ambos factores de
autenticación. La sesión DEBE finalizar (es decir, cerrar la sesión) cuando se alcance cualquiera de estos límites de tiempo. El verificador
PUEDE pedirle al usuario que provoque actividad justo antes del tiempo de inactividad.
El CSP DEBERÁ emplear controles de seguridad adaptados a la medida del alto línea de base de los controles de seguridad definidos
en SP 800-53 o un equivalente federal (por ejemplo, FEDRAMP ) o estándar de la industria. El CSP DEBERÁ garantizar que los
controles mínimos relacionados con la garantía alto impacto se satisfacen los sistemas o equivalentes.
aplicables, incluidos los programas de retención de registros de NARA que puedan aplicarse. Si el CSP opta por conservar registros en
ausencia de requisitos obligatorios, el CSP DEBERÁ realizar un proceso de gestión de riesgos, incluidas evaluaciones de los riesgos de
privacidad y seguridad, para determinar cuánto tiempo se deben conservar los registros e DEBERÁ informar al suscriptor de esa política
de retención.
Requisitos de privacidad
El CSP DEBERÁ emplear controles de privacidad adaptados adecuadamente definidos en SP 800-53 o estándar industrial
equivalente.
Si los CSP procesan atributos para fines distintos a la prueba de identidad, la autenticación o la afirmación de atributos (colectivamente, "servicio
de identidad"), la mitigación del fraude relacionado o para cumplir con la ley o el proceso legal, los CSP DEBERÁN implementar medidas para
mantener la previsibilidad y la capacidad de gestión acordes con la privacidad riesgo derivado del procesamiento adicional. Las medidas PUEDEN
incluir proporcionar un aviso claro, obtener el consentimiento del suscriptor o permitir el uso selectivo o la divulgación de atributos. Cuando los
CSP utilizan medidas de consentimiento, los CSP NO DEBEN hacer que el consentimiento para el procesamiento adicional sea una condición del
servicio de identidad.
Independientemente de si el CSP es una agencia o un proveedor del sector privado, los siguientes requisitos se aplican
a una agencia que ofrece o utiliza el servicio de autenticación:
10
• La agencia DEBE consultar con su Oficial Superior de la Agencia para la Privacidad (SAOP) y realizar un análisis
para determinar si la recopilación de PII para emitir o mantener autenticadores activa los requisitos de la Ley de
Privacidad de 1974 [ Acto privado ] (ver Sección 9.4 ).
o La agencia DEBE publicar un Aviso del Sistema de Registros (SORN) para cubrir tales
colecciones, según corresponda.
o La agencia DEBE consultar con su SAOP y realizar un análisis para
determinar si la recopilación de PII para emitir o mantener autenticadores activa los requisitos de la Ley
de gobierno electrónico de 2002 [ EGov ].
o La agencia DEBE publicar una Evaluación de Impacto en la Privacidad (PIA) para cubrir tales
colección, según corresponda.
Resumen de requisitos
La Tabla 4-1 resume los requisitos para cada uno de los AAL:
Tabla 4-1 Resumen de requisitos de AAL
Requisito AAL1 AAL2 AAL3
Secreto memorizado;
Dispositivo MF OTP;
Secreto de búsqueda; Dispositivo criptográfico MF;
Software criptográfico MF;
Fuera de banda; SF Crypto Device más
Dispositivo criptográfico MF;
Dispositivo SF OTP; Memorizado Secreto;
o secreto memorizado
Permitido Dispositivo MF OTP; Dispositivo SF OTP más
más:
Autenticador SF Crypto Dispositivo o Software
• Secreto de búsqueda
Tipos Software; Criptográfico MF;
• Fuera de banda
SF Crypto Device; Dispositivo SF OTP plus
• Dispositivo SF OTP
MF Crypto
• SF Crypto Software SF Crypto Software
Software; más el secreto memorizado
• Dispositivo criptográfico SF
Dispositivo criptográfico MF
Nivel 2 en general
(autenticadores MF)
Nivel 1 en general
Nivel 1 Nivel 1 (Gobierno
FIPS 140 (verificadores y SF
(Gobierno autenticadores de agencia
Verificación Dispositivos criptográficos)
verificadores de agencias) y verificadores)
Nivel 3 físico
seguridad (todo
autenticadores)
12 horas o 30 12 horas o 15 minutos de

minutos de inactividad; inactividad; DEBERÁ utilizar
Reautenticación 30 dias
PUEDE usar uno tanto autenticación
factor de autenticación factores
11
Requisito AAL1 AAL2 AAL3
SP 800-53 Bajo SP 800-53 Moderar SP 800-53 Alto

Controles de seguridad Línea de base (o Línea de base (o Línea de base (o
equivalente) equivalente) equivalente)
Resistencia MitM Necesario Necesario Necesario
Verificador
Interpretación No requerido No requerido Necesario
Resistencia
Verificador
Compromiso No requerido No requerido Necesario
Resistencia
Resistencia de repetición No requerido No requerido Necesario
Autenticación
No requerido Recomendado Necesario
Intención
Retención de registros
Necesario Necesario Necesario
Política
Controles de privacidad Necesario Necesario Necesario
12
5 Requisitos de autenticador y verificador
Esta sección proporciona los requisitos detallados específicos para cada tipo de autenticador. Con la excepción de los requisitos de
reautenticación especificados en Sección 4 y el requisito de resistencia a la suplantación del verificador en AAL3 descrito en Sección
5.2.5 , los requisitos técnicos para cada uno de los tipos de autenticadores son los mismos independientemente de la AAL en la que
se utilice el autenticador.
Requisitos por tipo de autenticador
5.1.1 Secretos memorizados

Un autenticador secreto memorizado, comúnmente conocido como contraseña o, si es numérico, un ALFILER

- es un valor secreto destinado a ser elegido y memorizado por el usuario. Los secretos memorizados deben
ser lo suficientemente complejos y secretos como para que no sea práctico para un atacante adivinar o
descubrir el valor secreto correcto. Un secreto memorizado es algo que sabes
5.1.1.1 Autenticadores secretos memorizados
Los secretos memorizados DEBEN tener al menos 8 caracteres de longitud si los elige el suscriptor. Los secretos memorizados elegidos al
azar por el CSP o el verificador DEBERÁN tener al menos 6 caracteres de longitud y PUEDEN ser completamente numéricos. Si el CSP o
el verificador rechaza un secreto memorizado elegido basándose en su aparición en una lista negra de valores comprometidos, el
suscriptor DEBERÁ elegir un secreto memorizado diferente. No DEBERÍAN imponerse otros requisitos de complejidad para los secretos
memorizados. Una justificación de esto se presenta en Apéndice UNA Fuerza de los secretos memorizados.
5.1.1.2 Verificadores secretos memorizados
Los verificadores DEBEN requerir que los secretos memorizados elegidos por el suscriptor tengan al menos 8 caracteres de longitud. Los
verificadores DEBEN permitir secretos memorizados elegidos por el suscriptor de al menos 64 caracteres de longitud. Toda la impresión ASCII [ RFC
20 ] caracteres así como el carácter de espacio DEBERÍAN ser aceptables en los secretos memorizados. Unicode [ ISO / ISC 10646 ] caracteres
DEBEN ser aceptados también. Para tener en cuenta la posibilidad de errores de escritura, los verificadores PUEDEN reemplazar múltiples
caracteres de espacio consecutivos con un solo carácter de espacio antes de la verificación, siempre que el resultado tenga al menos 8
caracteres de longitud. NO SE DEBE realizar el truncamiento del secreto. A los efectos de los requisitos de longitud anteriores, cada punto de
código Unicode DEBE contarse como un solo carácter.
Si se aceptan caracteres Unicode en secretos memorizados, el verificador DEBE aplicar el Proceso de normalización para cadenas
estabilizadas utilizando la normalización NFKC o NFKD definida en la Sección 12.1 del Anexo 15 del estándar Unicode [ UAX 15 ]. Este
proceso se aplica antes de aplicar hash a la cadena de bytes que representa el secreto memorizado. Los suscriptores que elijan secretos
memorizados que contengan caracteres Unicode DEBEN ser advertidos de que algunos caracteres pueden estar representados de manera
diferente por algunos puntos finales, lo que puede afectar su capacidad para autenticarse correctamente.
13
Los secretos memorizados elegidos aleatoriamente por el CSP (p. Ej., En el momento de la inscripción) o por el verificador (p. Ej., Cuando un
usuario solicita un nuevo PIN) DEBERÁN tener al menos 6 caracteres de longitud y DEBERÁN generarse mediante un generador de bits
aleatorios aprobado [ SP 800-90Ar1 ].
Los verificadores secretos memorizados NO DEBEN permitir que el suscriptor almacene una "pista" que sea accesible para un reclamante no
autenticado. Los verificadores NO DEBEN instar a los suscriptores a usar tipos específicos de información (por ejemplo, “¿Cuál era el nombre
de su primera mascota?”) Al elegir secretos memorizados.
Al procesar solicitudes para establecer y cambiar secretos memorizados, los verificadores DEBERÁN comparar los secretos
potenciales con una lista que contenga valores que se sabe que se usan comúnmente, se esperan o se comprometen. Por ejemplo, la
lista PUEDE incluir, pero no se limita a:
• Contraseñas obtenidas de corporaciones de infracción anteriores.
• Diccionario de palabras.
• Caracteres repetitivos o secuenciales (por ejemplo, 'aaaaaa', '1234abcd').

• Palabras específicas del contexto, como el nombre del servicio, el nombre de usuario y sus derivados.
Si el secreto elegido se encuentra en la lista, el CSP o el verificador DEBERÁ avisar al suscriptor de que deben seleccionar
un secreto diferente, DEBERÁ proporcionar el motivo del rechazo y DEBERÁ solicitar al suscriptor que elija un valor
diferente.
Los verificadores DEBEN ofrecer orientación al suscriptor, como un medidor de seguridad de la contraseña [ Metros ], para ayudar al usuario a
elegir un secreto fuerte memorizado. Esto es particularmente importante después del rechazo de un secreto memorizado en la lista anterior, ya
que desalienta la modificación trivial de los secretos memorizados enumerados (y probablemente muy débiles) [ Listas negras ].
Los verificadores DEBEN implementar un mecanismo de limitación de velocidad que limite efectivamente el número de intentos fallidos de
autenticación que se pueden realizar en la cuenta del suscriptor como se describe en Sección 5.2.2 .
Los verificadores NO DEBEN imponer otras reglas de composición (por ejemplo, requerir mezclas de diferentes tipos de caracteres o prohibir
caracteres repetidos consecutivamente) para los secretos memorizados. Los verificadores NO DEBEN requerir que los secretos memorizados se
cambien arbitrariamente (por ejemplo, periódicamente). Sin embargo, los verificadores DEBEN forzar un cambio si hay evidencia de compromiso
del autenticador.
Los verificadores DEBEN permitir que los reclamantes utilicen la función "pegar" al ingresar un secreto memorizado. Esto facilita el uso de
administradores de contraseñas, que se usan ampliamente y en muchos casos aumentan la probabilidad de que los usuarios elijan
secretos memorizados más fuertes.
Para ayudar al reclamante a ingresar con éxito un secreto memorizado, el verificador DEBE ofrecer una opción para mostrar el secreto, en
lugar de una serie de puntos o asteriscos, hasta que se ingrese. Esto permite al reclamante verificar su entrada si se encuentra en un lugar
donde es poco probable que se observe su pantalla. El verificador también PUEDE permitir que el dispositivo del usuario muestre caracteres
individuales ingresados por un corto tiempo después de que se ingrese cada carácter para verificar la entrada correcta. Esto es
particularmente aplicable en dispositivos móviles.
14
El verificador DEBE utilizar encriptación aprobada y un canal protegido autenticado cuando solicite secretos memorizados
con el fin de brindar resistencia a escuchas ilegales y ataques MitM.
Los verificadores DEBEN almacenar los secretos memorizados en una forma que sea resistente a los ataques fuera de línea. Los secretos
memorizados DEBEN ser salados y hash utilizando una función de derivación de clave unidireccional adecuada. Las funciones de derivación de
claves toman una contraseña, una sal y un factor de costo como entradas y luego generan un hash de contraseña. Su propósito es hacer que
cada prueba de adivinación de contraseña por parte de un atacante que haya obtenido un archivo hash de contraseña sea costosa y, por lo tanto,
el costo de un ataque de adivinación sea alto o prohibitivo. Algunos ejemplos de funciones de derivación de claves adecuadas incluyen la Función
de derivación de claves 2 basada en contraseña (PBKDF2) [ SP 800-132 ] y Globo [ GLOBO ]. DEBERÍA usarse una función de memoria dura
porque aumenta el costo de un ataque. La función de derivación de claves DEBE utilizar una función unidireccional aprobada, como el código de
autenticación de mensajes hash con clave (HMAC) [ FIPS 198-1 ], cualquier función hash aprobada en SP 800-107 , Algoritmo hash seguro 3
(SHA-3) [ FIPS 202 ], CMAC [ SP 800-38B ] o el código de autenticación de mensajes Keccak (KMAC), SHAKE personalizable (cSHAKE) o
ParallelHash [ SP 800-185 ]. La longitud de salida elegida de la función de derivación clave DEBERÍA ser la misma que la longitud de la salida de la
función unidireccional subyacente.
La sal DEBE tener al menos 32 bits de longitud y se elegirá arbitrariamente para minimizar las colisiones de valores de sal entre los
valores hash almacenados. Tanto el valor de sal como el hash resultante DEBERÁN almacenarse para cada suscriptor utilizando un
autenticador secreto memorizado.
Para PBKDF2, el factor de costo es un recuento de iteraciones: cuantas más veces se itera la función PBKDF2, más tiempo se tarda en
calcular el hash de la contraseña. Por lo tanto, el recuento de iteraciones DEBE ser tan grande como lo permita el rendimiento del
servidor de verificación, por lo general al menos 10,000 iteraciones.
Además, los verificadores DEBERÍAN realizar una iteración adicional de una función de derivación de claves utilizando un valor de sal que es
secreto y conocido solo por el verificador. Este valor de sal, si se utiliza, SERÁ generado por un generador de bits aleatorios aprobado [ SP
800-90Ar1 ] y proporcionar al menos la seguridad mínima especificada en la última revisión de SP 800-131A (112 bits a la fecha de esta
publicación). El valor de la sal secreta SE DEBE almacenar por separado de los secretos memorizados con hash (por ejemplo, en un
dispositivo especializado como un módulo de seguridad de hardware). Con esta iteración adicional, los ataques de fuerza bruta a los
secretos memorizados con hash no son prácticos siempre que el valor de la sal secreta permanezca en secreto.
5.1.2 Secretos de búsqueda
Un autenticador secreto de búsqueda es un registro físico o electrónico que almacena un conjunto de secretos
compartidos entre el reclamante y el CSP. El reclamante utiliza el autenticador para buscar los secretos apropiados
necesarios para responder a una solicitud del verificador. Por ejemplo, el verificador puede pedirle a un reclamante que
proporcione un subconjunto específico de cadenas numéricas o de caracteres impresas en una tarjeta en formato de
tabla. Una aplicación común de los secretos de búsqueda es el uso de "claves de recuperación".
almacenado por el suscriptor para su uso en caso de que otro autenticador se pierda o no funcione correctamente. Un secreto de búsqueda es algo
que tienes.
15
5.1.2.1 Búsqueda de autenticadores secretos
Los CSP que creen autenticadores secretos de búsqueda DEBEN utilizar un generador de bits aleatorios aprobado [ SP 800-90Ar1 ] para
generar la lista de secretos y DEBERÁ entregar el autenticador de forma segura al suscriptor. Los secretos de búsqueda DEBEN tener al
menos 20 bits de entropía.
Los secretos de búsqueda PUEDEN ser distribuidos por el CSP en persona, por correo postal a la dirección registrada del suscriptor o por
distribución en línea. Si se distribuye en línea, los secretos de búsqueda DEBERÁN distribuirse a través de un canal seguro de acuerdo con
los requisitos vinculantes posteriores a la inscripción en Sección 6.1.2 .
Si el autenticador usa secretos de búsqueda secuencialmente de una lista, el suscriptor PUEDE deshacerse de los secretos usados, pero solo
después de una autenticación exitosa.
5.1.2.2 Verificadores secretos de búsqueda
Los verificadores de secretos de búsqueda DEBERÁN solicitar al reclamante el siguiente secreto de su autenticador o un secreto
específico (por ejemplo, numerado). Un secreto dado de un autenticador DEBE usarse con éxito solo una vez. Si el secreto de
búsqueda se deriva de una tarjeta de cuadrícula, cada celda de la cuadrícula DEBE usarse solo una vez.
Los verificadores DEBEN almacenar los secretos de búsqueda en una forma que sea resistente a los ataques fuera de línea. Los secretos de
búsqueda que tengan al menos 112 bits de entropía SE DEBEN aplicar hash con una función unidireccional aprobada como se describe en Sección
5.1.1.2 . Los secretos de búsqueda con menos de 112 bits de entropía DEBEN ser salados y hash usando una función de derivación de clave
unidireccional adecuada, también descrita en Sección
5.1.1.2 . El valor de sal DEBERÁ tener una longitud de al menos 32 bits y se elegirá arbitrariamente para minimizar las colisiones de valores
de sal entre los valores hash almacenados. Tanto el valor de sal como el hash resultante DEBERÁN almacenarse para cada secreto de
búsqueda.
Para los secretos de búsqueda que tienen menos de 64 bits de entropía, el verificador DEBERÁ implementar un mecanismo de limitación de
velocidad que limite efectivamente el número de intentos fallidos de autenticación que se pueden realizar en la cuenta del suscriptor como se
describe en Sección 5.2.2 .
El verificador DEBE utilizar encriptación aprobada y un canal protegido autenticado cuando solicite secretos de búsqueda
para brindar resistencia a las escuchas clandestinas y los ataques MitM.
5.1.3 Dispositivos fuera de banda
Un autenticador fuera de banda es un dispositivo físico que es direccionable de forma única y puede
comunicarse de forma segura con el verificador a través de un canal de comunicaciones distinto, denominado
canal secundario. El dispositivo está en posesión y está controlado por el reclamante y admite la comunicación
privada a través de este canal secundario, separado del canal principal para la autenticación electrónica. Un
autenticador fuera de banda es algo que tienes.
El autenticador fuera de banda puede funcionar de una de las siguientes formas:
dieciséis
• El reclamante transfiere un secreto recibido por el dispositivo fuera de banda a través del canal secundario al verificador
que usa el canal primario. Por ejemplo, el reclamante puede recibir el secreto en su dispositivo móvil y escribirlo
(normalmente un código de 6 dígitos) en su sesión de autenticación.
• El reclamante transfiere un secreto recibido a través del canal principal al dispositivo fuera de banda para su transmisión al
verificador a través del canal secundario. Por ejemplo, el reclamante puede ver el secreto en su sesión de autenticación y
escribirlo en una aplicación en su dispositivo móvil o usar una tecnología como un código de barras o un código QR para
efectuar la transferencia.
• El reclamante compara los secretos recibidos del canal principal y el canal secundario y confirma la
autenticación a través del canal secundario.
El propósito del secreto es vincular de forma segura la operación de autenticación en el canal primario y secundario. Cuando la respuesta
es a través del canal de comunicación principal, el secreto también establece el control del reclamante sobre el dispositivo fuera de
banda.
5.1.3.1 Autenticadores fuera de banda
El autenticador fuera de banda DEBE establecer un canal separado con el verificador para recuperar el secreto
fuera de banda o la solicitud de autenticación. Este canal se considera fuera de banda con respecto al canal de
comunicación principal (incluso si termina en el mismo dispositivo) siempre que el dispositivo no filtre información
de un canal a otro sin la autorización del reclamante.
El dispositivo fuera de banda DEBE ser direccionable de forma única y la comunicación a través del canal secundario DEBE estar cifrada a
menos que se envíe a través de la red telefónica pública conmutada (PSTN). Para conocer los requisitos de autenticador adicionales
específicos de la PSTN, consulte Sección 5.1.3.3 . Los métodos que no prueben la posesión de un dispositivo específico, como voz sobre IP
(VOIP) o correo electrónico, NO DEBEN utilizarse para la autenticación fuera de banda.
El autenticador fuera de banda DEBE autenticarse a sí mismo de forma única en una de las siguientes formas cuando se comunica
con el verificador:
• Establezca un canal protegido autenticado para el verificador utilizando criptografía aprobada. La clave utilizada DEBERÁ
almacenarse en un almacenamiento convenientemente seguro disponible para la aplicación de autenticación (por ejemplo,
almacenamiento de llavero, TPM, TEE, elemento seguro).
• Autentíquese en una red pública de telefonía móvil mediante una tarjeta SIM o equivalente que identifique de forma
exclusiva el dispositivo. Este método solo DEBE utilizarse si el verificador envía un secreto al dispositivo fuera de banda
a través de la PSTN (SMS o voz).
Si el verificador envía un secreto al dispositivo fuera de banda, el dispositivo NO DEBE mostrar el secreto de autenticación mientras está
bloqueado por el propietario (es decir, requiere la entrada de un PIN, código de acceso o datos biométricos para verlo). Sin embargo, los
autenticadores DEBEN indicar la recepción de un secreto de autenticación en un dispositivo bloqueado.
Si el autenticador fuera de banda envía un mensaje de aprobación a través del canal de comunicación secundario, en lugar de
que el reclamante transfiera un secreto recibido al canal de comunicación principal, DEBE realizar una de las siguientes
acciones:
17
• El autenticador DEBE aceptar la transferencia del secreto del canal primario que DEBE enviar al verificador por el canal
secundario para asociar la aprobación con la transacción de autenticación. El reclamante PUEDE realizar la transferencia
manualmente o utilizar una tecnología como un código de barras o un código QR para efectuar la transferencia.
• El autenticador DEBE presentar un secreto recibido a través del canal secundario del verificador y solicitar al
reclamante que verifique la coherencia de ese secreto con el canal principal, antes de aceptar una respuesta de sí /
no del reclamante. A continuación, DEBE enviar esa respuesta al verificador.
5.1.3.2 Verificadores fuera de banda
Para conocer los requisitos de verificación adicionales específicos de la PSTN, consulte Sección 5.1.3.3 .
Si la verificación fuera de banda se va a realizar mediante una aplicación segura, como en un teléfono inteligente, el verificador PUEDE enviar
una notificación automática a ese dispositivo. Luego, el verificador espera el establecimiento de un canal protegido autenticado y verifica la
clave de identificación del autenticador. El verificador NO DEBERÁ almacenar la clave de identificación por sí mismo, pero DEBERÁ utilizar un
método de verificación (por ejemplo, una función hash aprobada o prueba de posesión de la clave de identificación) para identificar de forma
única al autenticador. Una vez autenticado, el verificador transmite el secreto de autenticación al autenticador.
Según el tipo de autenticador fuera de banda, se DEBE llevar a cabo una de las siguientes situaciones:
• Transferencia del secreto al canal primario: El verificador PUEDE señalar al dispositivo que contiene el autenticador del
suscriptor para indicar que está listo para autenticarse. Luego DEBE transmitir un secreto aleatorio al autenticador fuera de
banda. El verificador DEBE esperar entonces a que se devuelva el secreto en el canal de comunicación principal.
• Transferencia de secreto al canal secundario: El verificador DEBE mostrar un secreto de autenticación aleatorio al
reclamante a través del canal primario. A continuación, DEBE esperar a que se devuelva el secreto en el canal secundario
del autenticador fuera de banda del reclamante.
• Verificación de secretos por parte del reclamante: El verificador DEBERÁ mostrar un secreto de autenticación aleatorio al
reclamante a través del canal primario, y DEBERÁ enviar el mismo secreto al autenticador fuera de banda a través del canal
secundario para presentarlo al reclamante. Luego DEBE esperar un mensaje de aprobación (o desaprobación) a través del
canal secundario.
En todos los casos, la autenticación DEBE considerarse inválida si no se completa dentro de los 10 minutos. Para proporcionar resistencia a la
repetición como se describe en Sección 5.2.8 , los verificadores DEBEN aceptar un secreto de autenticación determinado solo una vez durante el
período de validez.
El verificador DEBE generar secretos de autenticación aleatorios con al menos 20 bits de entropía utilizando un generador de bits aleatorios
aprobado [ SP 800-90Ar1 ]. Si el secreto de autenticación tiene menos de 64 bits de entropía, el verificador DEBERÁ implementar un
mecanismo de limitación de velocidad que limite efectivamente el número de intentos de autenticación fallidos que se pueden realizar en la
cuenta del suscriptor como se describe en Sección 5.2.2 .
18
5.1.3.3 Autenticación mediante la red telefónica pública conmutada
El uso de la PSTN para la verificación fuera de banda está RESTRINGIDO como se describe en esta sección y en Sección 5.2.10 . Si
se va a realizar una verificación fuera de banda utilizando la PSTN, el verificador DEBE verificar que el número de teléfono
prerregistrado que se esté utilizando esté asociado con un dispositivo físico específico. El cambio del número de teléfono
prerregistrado se considera la vinculación de un nuevo autenticador y solo DEBE ocurrir como se describe en Sección 6.1.2 .
Los verificadores DEBEN considerar los indicadores de riesgo, como el cambio de dispositivo, el cambio de SIM, la transferencia de números u
otro comportamiento anormal antes de usar la PSTN para entregar un secreto de autenticación fuera de banda.
Nota: De acuerdo con la restricción de autenticadores en Sección 5.2.10 , NIST puede ajustar el estado
RESTRINGIDO de la PSTN con el tiempo en función de la evolución del panorama de amenazas y la
operación técnica de la PSTN.
5.1.4 Dispositivo OTP de factor único
Un dispositivo OTP de un solo factor genera OTP. Esta categoría incluye dispositivos de hardware y generadores
de OTP basados en software instalados en dispositivos como teléfonos móviles. Estos dispositivos tienen un
secreto incrustado que se utiliza como semilla para la generación de OTP y no requiere activación a través de un
segundo factor. La OTP se muestra en el dispositivo y se ingresa manualmente para su transmisión al verificador,
lo que demuestra la posesión y el control del dispositivo. Un dispositivo OTP
puede, por ejemplo, mostrar 6 caracteres a la vez. Un dispositivo OTP de factor único es algo que tienes.
Los dispositivos OTP de factor único son similares a los autenticadores secretos de búsqueda, con la excepción de que los secretos son
generados criptográficamente e independientemente por el autenticador y el verificador y comparados por el verificador. El secreto se calcula
en función de un nonce que puede estar basado en el tiempo o de un contador en el autenticador y verificador.
5.1.4.1 Autenticadores OTP de factor único
Los autenticadores OTP de factor único contienen dos valores persistentes. La primera es una clave simétrica que persiste durante la
vida útil del dispositivo. El segundo es un nonce que se cambia cada vez que se usa el autenticador o se basa en un reloj en tiempo
real.
La clave secreta y su algoritmo DEBERÁN proporcionar al menos la seguridad mínima especificada en la última revisión de SP
800-131A (112 bits a la fecha de esta publicación). El nonce DEBERÁ tener una longitud suficiente para garantizar que sea
único para cada operación del dispositivo durante su vida útil. Los autenticadores de OTP, en particular los generadores de OTP
basados en software, DEBEN desalentar y NO DEBEN facilitar la clonación de la clave secreta en varios dispositivos.
19
La salida del autenticador se obtiene mediante el uso de un cifrado de bloque aprobado o una función hash para combinar la clave y el
nonce de manera segura. La salida del autenticador PUEDE ser truncada a tan solo 6 dígitos decimales (aproximadamente 20 bits de
entropía).
Si el nonce utilizado para generar la salida del autenticador se basa en un reloj en tiempo real, el nonce DEBE cambiarse al menos
una vez cada 2 minutos. El valor de OTP asociado con un nonce dado DEBERÁ ser aceptado solo una vez.
5.1.4.2 Verificadores OTP de factor único
Los verificadores de OTP de un solo factor duplican efectivamente el proceso de generación de la OTP utilizada por el autenticador. Como tal, las
claves simétricas utilizadas por los autenticadores también están presentes en el verificador y DEBEN estar fuertemente protegidas contra el
compromiso.
Cuando se asocia un autenticador OTP de un solo factor con una cuenta de suscriptor, el verificador o el CSP asociado
DEBERÁ utilizar criptografía aprobada para generar e intercambiar u obtener los secretos necesarios para duplicar la
salida del autenticador.
El verificador DEBE utilizar encriptación aprobada y un canal protegido autenticado al recolectar la OTP para brindar resistencia a
escuchas y ataques MitM. OTP basadas en el tiempo [ RFC 6238 ] DEBERÁ tener una vida útil definida determinada por la desviación
esperada del reloj, en cualquier dirección, del autenticador a lo largo de su vida, más la tolerancia para el retraso de la red y la
entrada del usuario de la OTP. Para proporcionar resistencia a la repetición como se describe en Sección 5.2.8 , los verificadores
DEBEN aceptar una OTP basada en el tiempo determinada solo una vez durante el período de validez.
Si la salida del autenticador tiene menos de 64 bits de entropía, el verificador DEBERÁ implementar un mecanismo de limitación de velocidad
que limite efectivamente el número de intentos fallidos de autenticación que se pueden realizar en la cuenta del suscriptor como se describe
en Sección 5.2.2 .
5.1.5 Dispositivos OTP multifactor
Un dispositivo OTP de múltiples factores genera OTP para su uso en la autenticación después de la activación a través
de un factor de autenticación adicional. Esto incluye dispositivos de hardware y generadores de OTP basados en
software instalados en dispositivos como teléfonos móviles. El segundo factor de autenticación puede lograrse mediante
algún tipo de teclado de entrada integral, un lector biométrico integral (por ejemplo, de huellas dactilares) o una interfaz
de computadora directa (por ejemplo, un puerto USB). La OTP se muestra en el dispositivo y
entrada manual para su transmisión al verificador. Por ejemplo, un dispositivo OTP puede mostrar 6 caracteres a la
vez, lo que demuestra la posesión y el control del dispositivo. El dispositivo OTP multifactor es algo que tienes y
DEBE ser activado por algo que sabes o algo que eres.
5.1.5.1 Autenticadores OTP multifactor
Los autenticadores OTP multifactor funcionan de manera similar a los autenticadores OTP de un solo factor (consulte Sección
5.1.4.1 ), excepto que requieren la entrada de un secreto memorizado o el uso de
20
un biométrico para obtener la OTP del autenticador. Cada uso del autenticador DEBE requerir la entrada del
factor adicional.
Además de la información de activación, los autenticadores OTP multifactor contienen dos valores persistentes. La primera es una
clave simétrica que persiste durante la vida útil del dispositivo. El segundo es un nonce que se cambia cada vez que se usa el
autenticador o se basa en un reloj en tiempo real.
La clave secreta y su algoritmo DEBERÁN proporcionar al menos la seguridad mínima especificada en la última revisión de SP
800-131A (112 bits a la fecha de esta publicación). El nonce DEBERÁ tener una longitud suficiente para garantizar que sea
único para cada operación del dispositivo durante su vida útil. Los autenticadores de OTP, en particular los generadores de OTP
basados en software, DEBEN desalentar y NO DEBEN facilitar la clonación de la clave secreta en varios dispositivos.
La salida del autenticador se obtiene mediante el uso de un cifrado de bloque aprobado o una función hash para combinar la clave y el
nonce de manera segura. La salida del autenticador PUEDE ser truncada a tan solo 6 dígitos decimales (aproximadamente 20 bits de
entropía).
Si el nonce utilizado para generar la salida del autenticador se basa en un reloj en tiempo real, el nonce DEBE cambiarse al menos
una vez cada 2 minutos. El valor de OTP asociado con un nonce dado DEBERÁ ser aceptado solo una vez.
Cualquier secreto memorizado utilizado por el autenticador para la activación DEBE ser un secreto numérico elegido al azar de al menos
6 dígitos decimales de longitud u otro secreto memorizado que cumpla con los requisitos de Sección 5.1.1.2 y DEBERÁ tener una tarifa
limitada según se especifica en Sección 5.2.2 . Un factor de activación biométrica DEBE cumplir con los requisitos de Sección 5.2.3 ,
incluidos los límites en el número de errores de autenticación consecutivos.
La clave sin cifrar y el secreto de activación o la muestra biométrica, y cualquier dato biométrico derivado de la muestra biométrica,
como una sonda producida mediante el procesamiento de señales, DEBERÁN ponerse a cero inmediatamente después de que se
haya generado una OTP.
5.1.5.2 Verificadores de OTP de factores múltiples
Los verificadores de OTP de múltiples factores duplican efectivamente el proceso de generar la OTP utilizada por el autenticador, pero
sin el requisito de que se proporcione un segundo factor. Como tal, las claves simétricas utilizadas por los autenticadores DEBEN estar
fuertemente protegidas contra el compromiso.
Cuando un autenticador OTP de múltiples factores se asocia con una cuenta de suscriptor, el verificador o el CSP asociado DEBERÁ
utilizar criptografía aprobada para generar e intercambiar u obtener los secretos necesarios para duplicar la salida del autenticador. El
verificador o CSP DEBE establecer también, a través de la fuente del autenticador, que el autenticador es un dispositivo multifactor. En
ausencia de una declaración confiable de que se trata de un dispositivo de múltiples factores, el verificador DEBE tratar al autenticador
como de un solo factor, de acuerdo con Sección 5.1.4 .
El verificador DEBE utilizar encriptación aprobada y un canal protegido autenticado al recolectar la OTP
para brindar resistencia a escuchas y ataques MitM. OTP basadas en el tiempo [ RFC 6238 ] DEBERÁ
tener una vida útil definida determinada por el
21
Desviación del reloj, en cualquier dirección, del autenticador durante su vida útil, además de la tolerancia para el retraso de la red y la entrada del
usuario de la OTP. Para proporcionar resistencia a la repetición como se describe en Sección 5.2.8 , los verificadores DEBEN aceptar una OTP
basada en el tiempo determinada solo una vez durante el período de validez. En el caso de que se deniegue la autenticación de un reclamante
debido al uso duplicado de una OTP, los verificadores PUEDEN advertir al reclamante en caso de que un atacante haya podido autenticarse por
adelantado. Los verificadores también PUEDEN advertir a un suscriptor en una sesión existente del intento de uso duplicado de una OTP.
Si la salida del autenticador o el secreto de activación tienen menos de 64 bits de entropía, el verificador DEBERÁ implementar un
mecanismo de limitación de velocidad que limite efectivamente el número de intentos fallidos de autenticación que se pueden realizar en
la cuenta del suscriptor como se describe en Sección
5.2.2 . Un factor de activación biométrica DEBE cumplir con los requisitos de Sección 5.2.3 , incluidos los límites en el número de
errores de autenticación consecutivos.
5.1.6 Software criptográfico de factor único
Un autenticador criptográfico de software de factor único es una clave criptográfica almacenada en un

disco o en algún otro medio "blando". La autenticación se logra probando la posesión y el control de la
clave. La salida del autenticador depende en gran medida del protocolo criptográfico específico, pero
generalmente es algún tipo de mensaje firmado. El autenticador criptográfico de software de factor único
es algo que tienes.
5.1.6.1 Autenticadores de software criptográfico de factor único
Los autenticadores criptográficos de software de un solo factor encapsulan una o más claves secretas
único para el autenticador. La clave DEBE almacenarse en un almacenamiento seguro y adecuado disponible para la aplicación del
autenticador (por ejemplo, almacenamiento de llavero, TPM o TEE si está disponible). La clave DEBE estar fuertemente protegida contra la
divulgación no autorizada mediante el uso de controles de acceso que limitan el acceso a la clave solo a aquellos componentes de software en
el dispositivo que requieren acceso. Los autenticadores de software criptográfico de factor único DEBEN desalentar y NO DEBERÍAN facilitar la
clonación de la clave secreta en múltiples dispositivos.
5.1.6.2 Verificadores de software criptográfico de factor único
Los requisitos para un verificador de software criptográfico de factor único son idénticos a los de un verificador de dispositivo
criptográfico de factor único, descritos en Sección 5.1.7.2 .
5.1.7 Dispositivos criptográficos de factor único
Un dispositivo criptográfico de factor único es un dispositivo de hardware que realiza operaciones

criptográficas utilizando claves criptográficas protegidas y proporciona la salida del autenticador a través de
una conexión directa al punto final del usuario. El dispositivo utiliza claves criptográficas simétricas o
asimétricas integradas y no requiere activación a través de un segundo factor de autenticación. La
autenticación se logra probando la posesión del dispositivo a través de la autenticación
protocolo. La salida del autenticador se proporciona mediante una conexión directa al punto final del usuario y se
22
depende en gran medida del protocolo y dispositivo criptográfico específico, pero normalmente es algún tipo de mensaje firmado.
Un dispositivo criptográfico de factor único es algo que tienes.
5.1.7.1 Autenticadores de dispositivos criptográficos de factor único
Los autenticadores de dispositivos criptográficos de factor único encapsulan una o más claves secretas únicas para el dispositivo que NO
DEBEN ser exportables (es decir, no se pueden quitar del dispositivo). El autenticador opera firmando un mensaje de desafío presentado
a través de una interfaz de computadora directa (por ejemplo, un puerto USB). Alternativamente, el autenticador podría ser un procesador
adecuadamente seguro integrado con el propio punto final del usuario (por ejemplo, un TPM de hardware). Aunque los dispositivos
criptográficos contienen software, se diferencian de los autenticadores de software criptográfico en que todo el software integrado está
bajo el control del CSP o del emisor y que todo el autenticador está sujeto a todos los requisitos FIPS 140 aplicables en la AAL que se
autentica.
La clave secreta y su algoritmo DEBERÁN proporcionar al menos la longitud mínima de seguridad especificada en la última
revisión de SP 800-131A (112 bits a la fecha de esta publicación). El desafío nonce DEBE tener al menos 64 bits de longitud.
Se DEBE utilizar criptografía aprobada.
Los autenticadores de dispositivos criptográficos de factor único DEBERÍAN requerir una entrada física (por ejemplo, presionar un
botón) para operar. Esto proporciona una defensa contra el funcionamiento involuntario del dispositivo, que podría ocurrir si el punto
final al que está conectado se ve comprometido.
5.1.7.2 Verificadores de dispositivos criptográficos de factor único
Los verificadores de dispositivos criptográficos de factor único generan un nonce de desafío, lo envían al autenticador correspondiente
y usan la salida del autenticador para verificar la posesión del dispositivo. La salida del autenticador depende en gran medida del
protocolo y dispositivo criptográfico específico, pero generalmente es algún tipo de mensaje firmado.
El verificador tiene claves criptográficas simétricas o asimétricas correspondientes a cada autenticador. Si bien ambos
tipos de claves DEBEN estar protegidas contra modificaciones, las claves simétricas DEBEN protegerse además contra la
divulgación no autorizada.
El desafío nonce DEBERÁ tener al menos 64 bits de longitud y DEBERÁ ser único durante la vida útil del autenticador o
estadísticamente único (es decir, generado utilizando un generador de bits aleatorios aprobado [ SP 800-90Ar1 ]). La operación
de verificación DEBE utilizar criptografía aprobada.
5.1.8 Software criptográfico multifactor
Un autenticador criptográfico de software de múltiples factores es una clave criptográfica almacenada en un

disco o algún otro medio "suave" que requiere activación a través de un segundo factor de autenticación.
La autenticación se logra probando la posesión y el control de la clave. La salida del autenticador depende
en gran medida del protocolo criptográfico específico, pero generalmente es algún tipo de mensaje firmado.
El autenticador criptográfico de software multifactor es alguna cosa
tienes, y DEBE ser activado por algo que sabes o algo que eres.
23
5.1.8.1 Autenticadores de software criptográfico multifactor
Los autenticadores criptográficos de software de múltiples factores encapsulan una o más claves secretas exclusivas del autenticador y son
accesibles solo mediante la entrada de un factor adicional, ya sea un secreto memorizado o un biométrico. La clave DEBE almacenarse en un
almacenamiento convenientemente seguro disponible para la aplicación de autenticación (por ejemplo, almacenamiento de llavero, TPM, TEE).
La clave DEBE estar fuertemente protegida contra la divulgación no autorizada mediante el uso de controles de acceso que limitan el acceso a
la clave solo a aquellos componentes de software en el dispositivo que requieren acceso. Los autenticadores de software criptográfico de
múltiples factores DEBEN desalentar y NO DEBEN facilitar la clonación de la clave secreta en múltiples dispositivos.
Cada operación de autenticación que utilice el autenticador DEBE requerir la entrada de ambos factores.
Cualquier secreto memorizado utilizado por el autenticador para la activación DEBE ser un valor numérico elegido al azar de al menos 6
dígitos decimales de longitud u otro secreto memorizado que cumpla con los requisitos de Sección 5.1.1.2 y DEBERÁ tener una tarifa
La clave no cifrada y el secreto de activación o la muestra biométrica, y cualquier dato biométrico derivado de la muestra biométrica,
haya realizado una transacción de autenticación.
5.1.8.2 Verificadores de software criptográfico de múltiples factores
Los requisitos para un verificador de software criptográfico multifactor son idénticos a los de un verificador de dispositivo
criptográfico de factor único, descritos en Sección 5.1.7.2 . La verificación de la salida de un autenticador de software
criptográfico multifactor demuestra el uso del factor de activación.
5.1.9 Dispositivos criptográficos multifactor
Un dispositivo criptográfico multifactor es un dispositivo de hardware que realiza operaciones criptográficas

utilizando una o más claves criptográficas protegidas y requiere activación a través de un segundo factor de
autenticación. La autenticación se logra probando la posesión del dispositivo y el control de la clave. La
salida del autenticador se proporciona mediante una conexión directa al punto final del usuario y depende en
gran medida del protocolo y dispositivo criptográfico específico, pero es
normalmente algún tipo de mensaje firmado. El dispositivo criptográfico multifactor es algo que tienes y
DEBE ser activado por algo que sabes o algo que eres.
5.1.9.1 Autenticadores de dispositivos criptográficos multifactor
Los autenticadores de dispositivos criptográficos de múltiples factores utilizan hardware a prueba de manipulaciones para encapsular una o más
claves secretas exclusivas del autenticador y accesibles solo mediante la entrada de un factor adicional, ya sea un secreto memorizado o
biométrico. El autenticador opera mediante el uso de una clave privada que fue desbloqueada por el factor adicional para firmar un nonce de
desafío presentado a través de una interfaz de computadora directa (por ejemplo, un puerto USB). Alternativamente, el autenticador podría ser un
24
Procesador adecuadamente seguro integrado con el propio punto final del usuario (por ejemplo, un TPM de hardware). Aunque los
dispositivos criptográficos contienen software, se diferencian de los autenticadores de software criptográfico en que todo el software
integrado está bajo el control del CSP o del emisor, y que todo el autenticador está sujeto a los requisitos de FIPS 140 aplicables en la
AAL seleccionada.
La clave secreta y su algoritmo DEBERÁN proporcionar al menos la longitud mínima de seguridad especificada en la última
revisión de SP 800-131A (112 bits a la fecha de esta publicación). El desafío nonce DEBE tener al menos 64 bits de longitud.
Se DEBE utilizar criptografía aprobada.
Cada operación de autenticación que utiliza el autenticador DEBE requerir la entrada del factor adicional. La entrada del factor
adicional PUEDE realizarse mediante una entrada directa en el dispositivo o mediante una conexión de hardware (por ejemplo, USB,
tarjeta inteligente).
Cualquier secreto memorizado utilizado por el autenticador para la activación DEBE ser un valor numérico elegido al azar de al menos 6
dígitos decimales de longitud u otro secreto memorizado que cumpla con los requisitos de Sección 5.1.1.2 y DEBERÁ tener una tarifa
La clave no cifrada y el secreto de activación o la muestra biométrica, y cualquier dato biométrico derivado de la muestra biométrica,
haya realizado una transacción de autenticación.
5.1.9.2 Verificadores de dispositivos criptográficos multifactoriales
Los requisitos para un verificador de dispositivo criptográfico de factor múltiple son idénticos a los de un verificador de dispositivo
criptográfico de factor único, descritos en Sección 5.1.7.2 . La verificación de la salida del autenticador de un dispositivo criptográfico
multifactor prueba el uso del factor de activación.
Requisitos generales del autenticador
Las siguientes subsecciones describen los requisitos generales para los autenticadores.
5.2.1 Autenticadores físicos
Los CSP DEBERÁN proporcionar instrucciones al suscriptor sobre cómo proteger adecuadamente al autenticador contra robo o pérdida. El
CSP DEBE proporcionar un mecanismo para revocar o suspender el autenticador inmediatamente después de la notificación del suscriptor
de que se sospecha la pérdida o el robo del autenticador.
5.2.2 Limitación de velocidad (estrangulamiento)
Cuando lo requieran las descripciones del tipo de autenticador en Sección 5.1 , el verificador DEBE implementar controles para
protegerse contra ataques de adivinanzas en línea. A menos que se especifique lo contrario en la descripción de un autenticador dado, el
verificador DEBE limitar los intentos de autenticación fallidos consecutivos en una sola cuenta a no más de 100.
25
PUEDEN utilizarse técnicas adicionales para reducir la probabilidad de que un atacante bloquee al reclamante legítimo como
resultado de la limitación de la tasa. Éstos incluyen:
• Exigir que el reclamante complete un CAPTCHA antes de intentar la autenticación.

• Exigir al reclamante que espere después de un intento fallido durante un período de tiempo que aumenta a medida que
la cuenta se acerca a su límite máximo para intentos fallidos consecutivos (por ejemplo, 30 segundos hasta una hora).
• Aceptando solo solicitudes de autenticación que provienen de una lista blanca de direcciones IP desde las cuales el
suscriptor ha sido autenticado exitosamente antes.
• Aprovechar otras técnicas de autenticación adaptativas o basadas en el riesgo para identificar el comportamiento del usuario que se
encuentra dentro o fuera de las normas típicas. Estos pueden incluir, por ejemplo, el uso de la dirección IP, la ubicación geográfica, el
tiempo de los patrones de solicitud o los metadatos del navegador.
Cuando el suscriptor se autentica con éxito, el verificador DEBE ignorar cualquier intento fallido anterior de ese
usuario desde la misma dirección IP.
5.2.3 Uso de datos biométricos
El uso de biometría ( algo que eres) en la autenticación incluye tanto la medición de características físicas (por ejemplo, huellas dactilares,
iris, características faciales) como características de comportamiento (por ejemplo, cadencia de mecanografía). Ambas clases se consideran
modalidades biométricas, aunque diferentes modalidades pueden diferir en la medida en que establecen la intención de autenticación como
se describe en Sección 5.2.9 .
Por diversas razones, este documento solo admite un uso limitado de datos biométricos para la autenticación.
Estas razones incluyen:
• La tasa de coincidencia falsa biométrica (FMR) no proporciona confianza en la autenticación del suscriptor por sí misma.
Además, FMR no tiene en cuenta los ataques de suplantación de identidad.
• La comparación biométrica es probabilística, mientras que los otros factores de autenticación son deterministas.
• Los esquemas de protección de plantillas biométricas proporcionan un método para revocar credenciales biométricas que es
comparable a otros factores de autenticación (por ejemplo, certificados PKI y contraseñas). Sin embargo, la disponibilidad de
tales soluciones es limitada y se están desarrollando estándares para probar estos métodos.
• Las características biométricas no constituyen secretos. Se pueden obtener en línea o tomando una foto de alguien con un teléfono
con cámara (por ejemplo, imágenes faciales) con o sin su conocimiento, levantadas de objetos que alguien toca (por ejemplo,
huellas dactilares latentes) o capturadas con imágenes de alta resolución (por ejemplo, iris patrones). Si bien las tecnologías de
detección de ataques de presentación (PAD) (por ejemplo, detección de actividad) pueden mitigar el riesgo de estos tipos de
ataques, se requiere una confianza adicional en el sensor o el procesamiento biométrico para garantizar que PAD esté funcionando
de acuerdo con las necesidades del CSP y el abonado.
Por lo tanto, el uso limitado de datos biométricos para la autenticación está respaldado por los siguientes requisitos y
pautas:
26
La biometría DEBE usarse solo como parte de la autenticación multifactor con un autenticador físico ( algo
que tienes).
Se DEBE establecer un canal protegido autenticado entre el sensor (o un punto final que contenga un sensor que
resiste el reemplazo del sensor) y el verificador y el sensor o punto final DEBERÁ autenticarse antes de capturar la
muestra biométrica del reclamante.
El sistema biométrico DEBE funcionar con un FMR [ ISO / IEC 2382-37 ] de 1 en 1000 o mejor. Este RMF DEBERÁ lograrse
en condiciones de un ataque conforme (es decir, intento de impostor sin esfuerzo) como se define en ISO / IEC 30107-1 .
El sistema biométrico DEBE implementar PAD. Las pruebas del sistema biométrico a desplegar DEBERÍAN demostrar al menos un 90% de
resistencia a los ataques de presentación para cada tipo de ataque relevante (es decir, especie), donde la resistencia se define como el
número de ataques de presentación frustrados dividido por el número de ataques de presentación de prueba. La prueba de resistencia al
ataque de presentación DEBERÁ realizarse de acuerdo con la Cláusula 12 de ISO / IEC 30107-3 . La decisión de PAD PUEDE tomarse
localmente en el dispositivo del reclamante o por un verificador central.
Nota: PAD se considera un requisito obligatorio en futuras ediciones de esta guía.
El sistema biométrico DEBE permitir no más de 5 intentos de autenticación fallidos consecutivos o 10 intentos fallidos
consecutivos si se implementa un PAD que cumple con los requisitos anteriores. Una vez que se haya alcanzado ese límite, el
autenticador biométrico DEBE:
• Imponer un retraso de al menos 30 segundos antes del siguiente intento, aumentando exponencialmente con cada
intento sucesivo (por ejemplo, 1 minuto antes del siguiente intento fallido, 2 minutos antes del segundo intento
siguiente), o
• Desactive la autenticación de usuario biométrica y ofrezca otro factor (por ejemplo, una modalidad biométrica
diferente o un PIN / Código de acceso si aún no es un factor obligatorio) si dicho método alternativo ya está
disponible.
El verificador DEBE determinar el rendimiento, la integridad y la autenticidad del sensor y del punto final. Los métodos
aceptables para tomar esta determinación incluyen, pero no se limitan a:
• Autenticación del sensor o endpoint.

• Certificación por una autoridad de acreditación aprobada.
• Interrogación en tiempo de ejecución de metadatos firmados (p. Ej., Atestación) como se describe en Sección 5.2.4 .
La comparación biométrica se puede realizar localmente en el dispositivo del reclamante o en un verificador central. Dado que el potencial de
ataques a mayor escala es mayor en los verificadores centrales, se prefiere la comparación local.
Si la comparación se realiza de forma centralizada:
• El uso de datos biométricos como factor de autenticación DEBERÁ limitarse a uno o más dispositivos específicos que se
identifican mediante criptografía aprobada. Dado que la biométrica tiene
27
aún no desbloqueada la clave de autenticación principal, se DEBE utilizar una clave separada para identificar el
dispositivo.
• Revocación biométrica, conocida como protección de plantilla biométrica en ISO / IEC 24745 , DEBERÁ
implementarse.
• Toda la transmisión de datos biométricos DEBERÁ realizarse a través del canal protegido autenticado.
Las muestras biométricas recolectadas en el proceso de autenticación PUEDEN usarse para entrenar algoritmos de comparación o, con el
consentimiento del usuario, para otros fines de investigación. Las muestras biométricas y cualquier dato biométrico derivado de la muestra
biométrica, como una sonda producida a través del procesamiento de señales, DEBERÁN ponerse a cero inmediatamente después de que se
hayan obtenido los datos de capacitación o investigación.
La biometría también se utiliza en algunos casos para evitar el repudio de la inscripción y para verificar que la misma persona participe
en todas las fases del proceso de inscripción como se describe en SP 800-63A .
5.2.4 Atestación
Una atestación es información que se transmite al verificador con respecto a un autenticador conectado directamente o al punto final
involucrado en una operación de autenticación. La información transmitida por la atestación PUEDE incluir, pero no se limita a:
• La procedencia (p. Ej., Certificación del fabricante o proveedor), estado e integridad del autenticador y del punto
final.
• Funciones de seguridad del autenticador.
• Características de seguridad y rendimiento de los sensores biométricos.
• Modalidad sensor.
Si esta atestación está firmada, DEBE estar firmada utilizando una firma digital que proporcione al menos la seguridad
mínima especificada en la última revisión de SP 800-131A (112 bits a la fecha de esta publicación).
La información de atestación PUEDE utilizarse como parte de la decisión de autenticación basada en riesgos de un verificador.
5.2.5 Resistencia a la suplantación de identidad del verificador
Los ataques de suplantación de identidad de verificadores, a veces denominados "ataques de phishing", son intentos de verificadores fraudulentos
y RP para engañar a un reclamante incauto para que se autentique en un sitio web impostor. En versiones anteriores de SP 800-63, los protocolos
resistentes a los ataques de suplantación de verificadores también se denominaban "fuertemente resistentes a MitM".
Un protocolo de autenticación resistente a la suplantación del verificador DEBE establecer un canal protegido autenticado con el
verificador. Luego, DEBERÁ vincular fuerte e irreversiblemente un identificador de canal que se negoció al establecer el canal
protegido autenticado a la salida del autenticador (p. Ej., Firmando los dos valores juntos usando una clave privada controlada por
el reclamante para la cual el verificador conoce la clave pública ). El verificador DEBE validar la firma u otra información utilizada
para demostrar la resistencia a la suplantación de identidad del verificador. Esto evita que un verificador impostor, incluso uno que
haya obtenido un certificado que represente al verificador real, reproduzca esa autenticación en un canal protegido autenticado
diferente.
28
Se DEBERÁN utilizar algoritmos criptográficos aprobados para establecer la resistencia a la suplantación de identidad del verificador cuando sea
necesario. Las claves utilizadas para este propósito DEBEN proporcionar al menos la fuerza de seguridad mínima especificada en la última
revisión de SP 800-131A (112 bits a la fecha de esta publicación).
Un ejemplo de un protocolo de autenticación resistente a la suplantación del verificador es TLS autenticado por el cliente, porque el
cliente firma la salida del autenticador junto con los mensajes anteriores del protocolo que son únicos para la conexión TLS particular
que se está negociando.
Los autenticadores que implican la entrada manual de una salida del autenticador, como los autenticadores fuera de banda y
OTP, NO DEBEN considerarse resistentes a la suplantación del verificador porque la entrada manual no vincula la salida del
autenticador a la sesión específica que se está autenticando. En un ataque MitM, un verificador impostor podría reproducir la
salida del autenticador OTP al verificador y autenticarse con éxito.
5.2.6 Comunicaciones Verificador-CSP
En situaciones donde el verificador y el CSP son entidades separadas (como se muestra con la línea de puntos en SP 800-63-3 Figura
4-1), las comunicaciones entre el verificador y el CSP DEBERÁN ocurrir a través de un canal seguro autenticado mutuamente (como
una conexión TLS autenticada por el cliente) utilizando criptografía aprobada.
5.2.7 Resistencia al compromiso del verificador
El uso de algunos tipos de autenticadores requiere que el verificador almacene una copia del secreto del autenticador. Por ejemplo, un
autenticador OTP (descrito en Sección 5.1.4 ) requiere que el verificador genere de forma independiente la salida del autenticador para
compararla con el valor enviado por el reclamante. Debido a la posibilidad de que el verificador se vea comprometido y los secretos
almacenados sean robados, los protocolos de autenticación que no requieren que el verificador almacene de manera persistente secretos que
podrían usarse para la autenticación se consideran más fuertes y se describen en este documento como verificador resistente al compromiso. Tenga
en cuenta que estos verificadores no son resistentes a todos los ataques. Un verificador podría verse comprometido de una manera diferente,
como ser manipulado para que siempre acepte una salida de autenticador en particular.
La resistencia al compromiso del verificador se puede lograr de diferentes maneras, por ejemplo:
• Utilice un autenticador criptográfico que requiera que el verificador almacene una clave pública correspondiente a
una clave privada en poder del autenticador.
• Almacene la salida esperada del autenticador en formato hash. Este método se puede utilizar con algunos autenticadores
secretos de búsqueda (descritos en Sección 5.1.2 ), por ejemplo.
Para que el verificador se considere resistente al compromiso, las claves públicas almacenadas por el verificador DEBERÁN estar
asociadas con el uso de algoritmos criptográficos aprobados y DEBERÁN proporcionar al menos la seguridad mínima especificada
en la última revisión de SP 800-131A (112 bits a la fecha de esta publicación).
Otros secretos resistentes al compromiso de los verificadores DEBERÁN utilizar algoritmos hash aprobados y los secretos subyacentes
DEBERÁN tener al menos la fuerza de seguridad mínima especificada en la última versión.
29
revisión de SP 800-131A (112 bits a la fecha de esta publicación). Los secretos (p. Ej., Secretos memorizados) que tienen menor complejidad
NO DEBEN considerarse resistentes al compromiso del verificador cuando se procesan con hash debido a la posibilidad de anular el proceso de
hash mediante la búsqueda en el diccionario o la búsqueda exhaustiva.
5.2.8 Resistencia a la repetición
Un proceso de autenticación resiste los ataques de reproducción si no es práctico lograr una autenticación exitosa grabando y reproduciendo
un mensaje de autenticación anterior. La resistencia a la reproducción se suma a la naturaleza resistente a la reproducción de los protocolos
de canales protegidos autenticados, ya que la salida podría ser robada antes de ingresar al canal protegido. Los protocolos que utilizan
nonces o desafíos para probar la "frescura" de la transacción son resistentes a los ataques de repetición, ya que el verificador detectará
fácilmente cuándo se reproducen los mensajes del protocolo antiguo, ya que no contendrán los nonces apropiados o los datos de
puntualidad.
Ejemplos de autenticadores resistentes a la reproducción son los dispositivos OTP, los autenticadores criptográficos y los secretos de
búsqueda.
Por el contrario, los secretos memorizados no se consideran resistentes a la reproducción porque la salida del autenticador, el
secreto en sí, se proporciona para cada autenticación.
5.2.9 Intención de autenticación
Un proceso de autenticación demuestra la intención si requiere que el sujeto responda explícitamente a cada solicitud de autenticación
o reautenticación. El objetivo de la intención de autenticación es dificultar el uso de autenticadores físicos conectados directamente
(por ejemplo, dispositivos criptográficos de múltiples factores) sin el conocimiento del sujeto, como por ejemplo, mediante malware en
el punto final. La intención de autenticación DEBE ser establecida por el propio autenticador, aunque los dispositivos criptográficos
multifactor PUEDEN establecer la intención mediante la reentrada del otro factor de autenticación en el punto final con el que se utiliza
el autenticador.
La intención de autenticación PUEDE establecerse de varias formas. Los procesos de autenticación que requieren la intervención del sujeto (por
ejemplo, un reclamante que ingresa una salida del autenticador desde un dispositivo OTP) establecen la intención. Los dispositivos
criptográficos que requieren la acción del usuario (por ejemplo, presionar un botón o reinserción) para cada operación de autenticación o
reautenticación también se establecen como intención.
Dependiendo de la modalidad, la presentación de un biométrico puede o no establecer la intención de autenticación. La presentación de una
huella dactilar normalmente establecería la intención, mientras que la observación del rostro del demandante con una cámara normalmente no lo
haría por sí sola. De manera similar, es menos probable que la biometría del comportamiento establezca la intención de autenticación porque no
siempre requieren una acción específica por parte del reclamante.
5.2.10 Autenticadores restringidos
A medida que evolucionan las amenazas, la capacidad de los autenticadores para resistir ataques suele degradarse. Por el contrario, el
rendimiento de algunos autenticadores puede mejorar, por ejemplo, cuando los cambios en sus estándares subyacentes aumentan su
capacidad para resistir ataques particulares.
30
Para tener en cuenta estos cambios en el rendimiento del autenticador, el NIST impone restricciones adicionales sobre los tipos de
autenticadores o clases específicas o instanciaciones de un tipo de autenticador.
El uso de un autenticador RESTRINGIDO requiere que la organización implementadora evalúe, comprenda y acepte los riesgos
asociados con ese autenticador RESTRINGIDO y reconozca que el riesgo probablemente aumentará con el tiempo. Es
responsabilidad de la organización determinar el nivel de riesgo aceptable para su (s) sistema (s) y datos asociados y definir
cualquier método para mitigar los riesgos excesivos. Si en algún momento la organización determina que el riesgo para alguna
de las partes es inaceptable, ese autenticador NO SE DEBE utilizar.
Además, el riesgo de un error de autenticación generalmente lo asumen varias partes, incluida la organización implementadora,
las organizaciones que dependen de la decisión de autenticación y el suscriptor. Debido a que el suscriptor puede estar expuesto
a un riesgo adicional cuando una organización acepta un autenticador RESTRINGIDO y que el suscriptor puede tener una
comprensión limitada y una capacidad para controlar ese riesgo, el CSP DEBE:
1. Ofrezca a los suscriptores al menos un autenticador alternativo que no esté RESTRINGIDO y que pueda usarse para
autenticarse en la AAL requerida.
2. Proporcionar un aviso significativo a los suscriptores sobre los riesgos de seguridad del autenticador
RESTRINGIDO y la disponibilidad de alternativas que no están RESTRINGIDAS.
3. Abordar cualquier riesgo adicional para los suscriptores en su evaluación de riesgos.

4. Desarrolle un plan de migración para la posibilidad de que el autenticador RESTRINGIDO ya no sea aceptable en
algún momento en el futuro e incluya este plan de migración en su declaración de aceptación de identidad digital.
31
6 Gestión del ciclo de vida del autenticador
Pueden ocurrir varios eventos durante el ciclo de vida del autenticador de un suscriptor que afectan el uso de ese autenticador.
Estos eventos incluyen vinculación, pérdida, robo, duplicación no autorizada, vencimiento y revocación. Esta sección describe las
acciones que se deben tomar en respuesta a esos eventos.
Enlace de autenticador
Enlace de autenticador se refiere al establecimiento de una asociación entre un autenticador específico y la cuenta de
un suscriptor, lo que permite que el autenticador sea utilizado, posiblemente junto con otros autenticadores, para
autenticar esa cuenta.
Los autenticadores DEBEN estar vinculados a las cuentas de los suscriptores por:
• Emisión por el CSP como parte de la inscripción; o

• Asociar un autenticador proporcionado por el suscriptor que sea aceptable para el CSP.
Estas pautas se refieren a Unión en lugar de la emisión de un autenticador para dar cabida a ambas
opciones.
A lo largo del ciclo de vida de la identidad digital, los CSP DEBEN mantener un registro de todos los autenticadores que están o han estado
asociados con cada identidad. El CSP o el verificador DEBE mantener la información requerida para limitar los intentos de autenticación
cuando sea necesario, como se describe en Sección
5.2.2 . El CSP también DEBE verificar el tipo de autenticador proporcionado por el usuario (por ejemplo, dispositivo criptográfico de factor
único frente a dispositivo criptográfico de factor múltiple) para que los verificadores puedan determinar el cumplimiento de los requisitos en
cada AAL.
El registro creado por el CSP DEBE contener la fecha y hora en que el autenticador estuvo vinculado a la cuenta. El registro
DEBE incluir información sobre el origen de la vinculación (por ejemplo, dirección IP, identificador de dispositivo) de cualquier
dispositivo asociado con la inscripción. Si está disponible, el registro DEBE también contener información sobre el origen de las
autenticaciones fallidas intentadas con el autenticador.
Cuando un nuevo autenticador está vinculado a una cuenta de abonado, el CSP DEBERÁ garantizar que el protocolo de
vinculación y el protocolo para el aprovisionamiento de las claves asociadas se realicen a un nivel de seguridad acorde con la
AAL en la que se utilizará el autenticador. Por ejemplo, los protocolos para el aprovisionamiento de claves DEBEN utilizar
canales protegidos autenticados o se realizarán en persona para protegerse contra ataques de intermediario. La vinculación de
autenticadores multifactor DEBE requerir autenticación multifactor o equivalente (por ejemplo, asociación con la sesión en la que
se acaba de completar la prueba de identidad) para vincular el autenticador. Se aplican las mismas condiciones cuando el
autenticador genera un par de claves y la clave pública se envía al CSP.
32
6.1.1 Vinculante al momento de la inscripción
Los siguientes requisitos se aplican cuando un autenticador está vinculado a una identidad como resultado de una transacción exitosa de
verificación de identidad, como se describe en SP 800-63A . Desde la Orden Ejecutiva 13681 [ EO 13681 ] requiere el uso de autenticación
multifactor para la divulgación de cualquier dato personal, es importante que los autenticadores estén vinculados a las cuentas de los
suscriptores en el momento de la inscripción, lo que permite el acceso a los datos personales, incluidos los establecidos mediante pruebas de
identidad.
El CSP DEBE unir al menos uno, y DEBE unir al menos dos, físicos ( algo que tienes) autenticadores de la identidad en
línea del suscriptor, además de un secreto memorizado o uno o más datos biométricos. Se prefiere la vinculación de
múltiples autenticadores para recuperarse de la pérdida o robo del autenticador principal del abonado.
Si bien toda la información de identificación se autoafirma en IAL1, la preservación de material en línea o una reputación en línea
hace que sea indeseable perder el control de una cuenta debido a la pérdida de un autenticador. El segundo autenticador permite
recuperarse de forma segura de una pérdida de autenticador. Por esta razón, un CSP DEBE vincular al menos dos autenticadores
físicos a la credencial del suscriptor en IAL1 también.
En IAL2 y superior, la información de identificación está asociada con la identidad digital y el suscriptor se ha sometido a un proceso
de verificación de identidad como se describe en SP 800-63A . Como resultado, los autenticadores de la misma AAL que la IAL
deseada DEBEN estar vinculados a la cuenta. Por ejemplo, si el suscriptor ha completado con éxito la verificación en IAL2,
entonces los autenticadores AAL2 o AAL3 son apropiados para vincularse a la identidad IAL2. Mientras que un CSP PUEDE
vincular un autenticador AAL1 a una identidad IAL2, si el suscriptor está autenticado en AAL1, el CSP NO DEBE exponer
información personal, incluso si es autoafirmado, al suscriptor. Como se indicó en el párrafo anterior, la disponibilidad de
autenticadores adicionales proporciona métodos de respaldo para la autenticación si un autenticador se daña, se pierde o es
robado.
Si la inscripción y la vinculación no se pueden completar en un solo encuentro físico o transacción electrónica (es decir, dentro de
una sola sesión protegida), se DEBEN utilizar los siguientes métodos para garantizar que la misma parte actúe como solicitante a
lo largo de los procesos:
Para transacciones remotas:
1. El solicitante DEBE identificarse en cada nueva transacción vinculante presentando un secreto temporal que se
estableció durante una transacción anterior o se envió al número de teléfono, dirección de correo electrónico o
dirección postal registrada del solicitante.
2. Los secretos del autenticador a largo plazo solo DEBEN ser entregados al solicitante dentro de una sesión protegida.
Para transacciones en persona:
1. El solicitante DEBE identificarse en persona ya sea utilizando un secreto como se describe en la transacción
remota (1) anterior, o mediante el uso de un biométrico que se registró durante un encuentro anterior.
2. Los secretos temporales NO DEBEN reutilizarse.
33
3. Si el CSP emite secretos de autenticador a largo plazo durante una transacción física, entonces DEBERÁN
cargarse localmente en un dispositivo físico que se emite en persona al solicitante o se entrega de manera
que confirme la dirección registrada.
6.1.2 Vinculación posterior a la inscripción
Las siguientes subsecciones describen la vinculación de un autenticador a la cuenta de un suscriptor.
6.1.2.1 Enlace de un autenticador adicional en AAL existente
Con la excepción de los secretos memorizados, los CSP y los verificadores DEBEN alentar a los suscriptores a mantener al menos dos
autenticadores válidos de cada factor que utilizarán. Por ejemplo, un suscriptor que generalmente usa un dispositivo OTP como
autenticador físico también PUEDE recibir una serie de autenticadores secretos de búsqueda, o registrar un dispositivo para autenticación
fuera de banda, en caso de que el autenticador físico se pierda, sea robado, o dañado. Ver Sección 6.1.2.3 para obtener más información
sobre la sustitución de autenticadores secretos memorizados.
En consecuencia, los CSP DEBERÍAN permitir la vinculación de autenticadores adicionales a la cuenta de un suscriptor. Antes de
agregar el nuevo autenticador, el CSP DEBE primero requerir que el suscriptor se autentique en el AAL (o un AAL superior) en el que se
utilizará el nuevo autenticador. Cuando se agrega un autenticador, el CSP DEBE enviar una notificación al suscriptor a través de un
mecanismo que es independiente de la transacción que vincula al nuevo autenticador (por ejemplo, correo electrónico a una dirección
previamente asociada con el suscriptor). El CSP PUEDE limitar el número de autenticadores que pueden estar vinculados de esta
manera.
6.1.2.2 Agregar un factor adicional a una cuenta de un solo factor
Si la cuenta del suscriptor tiene solo un factor de autenticación vinculado a ella (es decir, en IAL1 / AAL1) y se debe
agregar un autenticador adicional de un factor de autenticación diferente, el suscriptor PUEDE solicitar que la cuenta se
actualice a AAL2. El IAL permanecería en IAL1.
Antes de vincular el nuevo autenticador, el CSP DEBE requerir que el suscriptor se autentique en AAL1. El CSP DEBE enviar una
notificación del evento al suscriptor a través de un mecanismo independiente de la transacción que vincula al nuevo autenticador (por
ejemplo, correo electrónico a una dirección previamente asociada con el suscriptor).
6.1.2.3 Reemplazo de un factor de autenticación perdido
Si un suscriptor pierde todos los autenticadores de un factor necesario para completar la autenticación multifactor y se le ha verificado la
identidad en IAL2 o IAL3, ese suscriptor DEBE repetir el proceso de verificación de identidad descrito en SP 800-63A . Se PUEDE utilizar
un proceso de prueba abreviado, que confirma la vinculación del reclamante a la evidencia suministrada previamente, si el CSP ha
retenido la evidencia del proceso de prueba original de conformidad con una evaluación de riesgo de privacidad como se describe en SP
800-63A Sección 4.2. El CSP DEBE requerir que el reclamante se autentique utilizando un autenticador del factor restante, si lo hubiera,
para confirmar la vinculación a la identidad existente. El restablecimiento de los factores de autenticación en IAL3 DEBERÁ realizarse en
persona o mediante un proceso remoto supervisado como se describe en SP 800-63A Sección 5.3.3.2, y DEBERÁ verificar los datos
biométricos recopilados durante el proceso de prueba original.
34
El CSP DEBE enviar una notificación del evento al suscriptor. Este PUEDE ser el mismo aviso que se requiere como
parte del proceso de revisión.
El reemplazo de un secreto memorizado perdido (es decir, olvidado) es problemático porque es muy común. Los secretos
memorizados de “respaldo” adicionales no mitigan esto porque es muy probable que también se hayan olvidado. Si un
biométrico está vinculado a la cuenta, el autenticador biométrico y físico asociado DEBE usarse para establecer un nuevo
secreto memorizado.
Como alternativa al proceso de revisión anterior cuando no hay un enlace biométrico a la cuenta, el CSP PUEDE vincular un nuevo
secreto memorizado con autenticación utilizando dos autenticadores físicos, junto con un código de confirmación que se ha enviado
a una de las direcciones del suscriptor. de registro. El código de confirmación DEBE constar de al menos 6 caracteres
alfanuméricos aleatorios generados por un generador de bits aleatorios aprobado [ SP 800-90Ar1 ]. Los enviados a una dirección
postal registrada DEBERÁN ser válidos por un máximo de 7 días, pero PUEDEN ser válidos hasta por 21 días a través de un
proceso de excepción para acomodar direcciones fuera del alcance directo del
Servicio Postal de EE. UU. Los códigos de confirmación enviados por medios distintos al correo físico SERÁN válidos por un máximo de 10
minutos.
6.1.3 Vinculación a un autenticador proporcionado por el suscriptor
Un suscriptor ya puede poseer autenticadores adecuados para la autenticación en una AAL particular. Por ejemplo, pueden
tener un autenticador de dos factores de un proveedor de red social, considerado AAL2 e IAL1, y les gustaría usar esas
credenciales en un RP que requiera IAL2.
Los CSP DEBERÍAN, cuando sea práctico, acomodar el uso de autenticadores proporcionados por el suscriptor para aliviar la
carga al suscriptor de administrar un gran número de autenticadores. La vinculación de estos autenticadores DEBERÁ
realizarse como se describe en Sección 6.1.2.1 . En situaciones donde la fuerza del autenticador no es evidente (por ejemplo,
entre autenticadores de un solo factor y multifactor de un tipo dado), el CSP DEBE asumir el uso del autenticador más débil a
menos que pueda establecer que el autenticador más fuerte es de hecho se utiliza (por ejemplo, mediante verificación con el
emisor o fabricante del autenticador).
6.1.4 Renovación
El CSP DEBE vincular un autenticador actualizado una cantidad de tiempo adecuada antes de la expiración de un autenticador
existente. El proceso para esto DEBE ajustarse estrechamente al proceso inicial de vinculación del autenticador (por ejemplo,
confirmar la dirección del registro). Luego del uso exitoso del nuevo autenticador, el CSP PUEDE revocar el autenticador que está
reemplazando.
Pérdida, robo, daño y duplicación no autorizada
Los autenticadores comprometidos incluyen aquellos que se han perdido, robados o sujetos a duplicación no autorizada.
Generalmente, se debe suponer que un autenticador perdido ha sido robado o comprometido por alguien que no es el
suscriptor legítimo del autenticador. Los autenticadores dañados o que funcionan mal también se consideran comprometidos
para protegerse contra cualquier posibilidad de extracción del secreto del autenticador. Una excepción notable es un secreto
memorizado que se ha olvidado sin otros indicios de haber sido comprometido, como haber sido obtenido por un atacante.
35
La suspensión, revocación o destrucción de los autenticadores comprometidos DEBERÍA ocurrir tan pronto como sea posible
después de la detección. Las agencias DEBEN establecer límites de tiempo para este proceso.
Para facilitar la notificación segura de la pérdida, robo o daño a un autenticador, el CSP DEBE proporcionar al suscriptor un método
para autenticarse en el CSP utilizando un autenticador alternativo o de respaldo. Este autenticador de respaldo DEBE ser un secreto
memorizado o un autenticador físico. Se PUEDE utilizar cualquiera de las dos, pero solo se requiere un factor de autenticación para
realizar este informe. Alternativamente, el suscriptor PUEDE establecer un canal protegido autenticado al CSP y verificar la
información recopilada durante el proceso de verificación. El CSP PUEDE optar por verificar una dirección de registro (es decir, correo
electrónico, teléfono, postal) y suspender los autenticadores que se informa que han sido comprometidos. La suspensión DEBERÁ ser
reversible si el suscriptor se autentica con éxito en el CSP utilizando un código válido (es decir, no suspendido) autenticador y solicita
la reactivación de un autenticador suspendido de esta manera. El CSP PUEDE establecer un límite de tiempo después del cual un
autenticador suspendido ya no se puede reactivar.
Vencimiento
Los CSP PUEDEN emitir autenticadores que caducan. Si un autenticador expira y cuando expire, NO SE PUEDE
utilizar para la autenticación. Cuando se intenta una autenticación utilizando un autenticador caducado, el CSP DEBE
dar una indicación al suscriptor de que la falla de autenticación se debe a la caducidad y no a otra causa.
El CSP DEBE exigir a los suscriptores que entreguen o demuestren la destrucción de cualquier autenticador físico que contenga
certificados de atributos firmados por el CSP tan pronto como sea posible después de la expiración o la recepción de un autenticador
renovado.
Revocación y rescisión
La revocación de un autenticador, a veces denominada terminación, especialmente en el contexto de los autenticadores PIV,
se refiere a la eliminación del vínculo entre un autenticador y una credencial que mantiene el CSP.
Los CSP revocarán la vinculación de los autenticadores inmediatamente cuando una identidad en línea deje de existir (por ejemplo, la
muerte del suscriptor, el descubrimiento de un suscriptor fraudulento), cuando lo solicite el suscriptor, o cuando el CSP determine que
el suscriptor ya no cumple con sus requisitos de elegibilidad.
El CSP DEBE exigir a los suscriptores que entreguen o certifiquen la destrucción de cualquier autenticador físico que contenga atributos
certificados firmados por el CSP tan pronto como sea posible después de que se lleve a cabo la revocación o terminación. Esto es
necesario para bloquear el uso de los atributos certificados del autenticador en situaciones fuera de línea entre la revocación / terminación
y el vencimiento de la certificación.
Más requisitos sobre la terminación de los autenticadores PIV se encuentran en FIPS 201 .
36
7 Gestión de sesiones
Una vez que ha tenido lugar un evento de autenticación, a menudo es deseable permitir que el suscriptor continúe usando la
aplicación en múltiples interacciones posteriores sin requerir que repita el evento de autenticación. Este requisito es
particularmente cierto para los escenarios de federación, que se describen en SP 800-63C - donde el evento de autenticación
involucra necesariamente a varios componentes y partes que se coordinan a través de una red.
Para facilitar este comportamiento, un sesión PUEDE iniciarse en respuesta a un evento de autenticación y continuar la sesión
hasta el momento en que finalice. La sesión PUEDE terminarse por varias razones, que incluyen, entre otras, un tiempo de
espera de inactividad, un evento de cierre de sesión explícito u otros medios. La sesión PUEDE continuar a través de un evento
de reautenticación, descrito en Sección 7.2 - en el que el usuario repite parte o la totalidad del evento de autenticación inicial,
restableciendo así la sesión.
La administración de sesiones es preferible a la presentación continua de credenciales, ya que la mala usabilidad de la presentación continua
a menudo crea incentivos para soluciones alternativas, como credenciales de desbloqueo en caché, lo que anula la frescura del evento de
autenticación.
Enlaces de sesión
Se produce una sesión entre el software que está ejecutando un suscriptor, como un navegador, una aplicación o un sistema
operativo (es decir, el tema de la sesión) y el RP o CSP al que accede el suscriptor (es decir, el host de la sesión). Se DEBE
compartir un secreto de sesión entre el software del suscriptor y el servicio al que se accede. Este secreto une los dos
extremos de la sesión, lo que permite al suscriptor continuar usando el servicio a lo largo del tiempo. El secreto DEBE ser
presentado directamente por el software del suscriptor o la posesión del secreto DEBE probarse mediante un mecanismo
criptográfico.
El secreto utilizado para la vinculación de la sesión DEBE ser generado por el anfitrión de la sesión en respuesta directa a un evento de
autenticación. Una sesión DEBE heredar las propiedades AAL del evento de autenticación que desencadenó su creación. Una sesión
PUEDE ser considerada en una AAL más baja que el evento de autenticación, pero NO DEBE ser considerada en una AAL más alta que el
evento de autenticación.
Secretos utilizados para la vinculación de sesiones:
1. DEBE ser generado por el host de la sesión durante una interacción, generalmente inmediatamente después de la
autenticación.
2. DEBERÁ ser generado por un generador de bits aleatorios aprobado [ SP 800-90Ar1 ] y
contienen al menos 64 bits de entropía.
3. DEBERÁ ser borrado o invalidado por el sujeto de la sesión cuando el suscriptor cierre la sesión.
4. DEBE borrarse en el punto final del suscriptor cuando el usuario cierra sesión o cuando se considera que el secreto
ha expirado.
37
5. NO DEBE colocarse en ubicaciones inseguras como el almacenamiento local HTML5 debido a la posible exposición del
almacenamiento local a ataques de secuencias de comandos entre sitios (XSS).
6. SE DEBE enviar y recibir del dispositivo mediante un canal protegido autenticado.
7. DEBERÁ tiempo de espera y no será aceptado después de los tiempos especificados en Secciones 4.1.4 , 4.2.4 y 4.3.4 , según
corresponda a la AAL.
8. NO DEBERÁ estar disponible para comunicaciones inseguras entre el host y el punto final del suscriptor. Las
sesiones autenticadas NO DEBEN recurrir a un transporte inseguro, como de https a http, después de la
autenticación.
Las URL o el contenido POST DEBERÁN contener un identificador de sesión que el RP DEBERÁ verificar para garantizar que las
acciones tomadas fuera de la sesión no afecten a la sesión protegida.
Existen varios mecanismos para administrar una sesión a lo largo del tiempo. Las siguientes secciones ofrecen diferentes
ejemplos junto con requisitos y consideraciones adicionales particulares para cada tecnología de ejemplo. Orientación informativa
adicional está disponible en el OWASP Hoja de referencia para la gestión de sesiones [ Sesión OWASP ].
7.1.1 Cookies del navegador
Las cookies del navegador son el mecanismo predominante mediante el cual se creará y rastreará una sesión para un suscriptor que accede
a un servicio.
Galletas:
1. DEBERÁ estar etiquetado para ser accesible solo en sesiones seguras (HTTPS).
2. DEBERÁ ser accesible al conjunto mínimo práctico de nombres de host y rutas.
3. DEBERÍA etiquetarse como inaccesible a través de JavaScript (HttpOnly).
4. SE DEBE etiquetar para que expire en el período de validez de la sesión o poco después. Este requisito tiene como objetivo
limitar la acumulación de cookies, pero NO DEBE depender de él para hacer cumplir los tiempos de espera de la sesión.
7.1.2 Tokens de acceso
Un token de acceso, como el que se encuentra en OAuth, se utiliza para permitir que una aplicación acceda a un conjunto de servicios en
nombre de un suscriptor después de un evento de autenticación. El RP NO DEBERÁ interpretar la presencia de un testigo de acceso OAuth
como presencia del abonado, en ausencia de otras señales. El token de acceso de OAuth y cualquier token de actualización asociado
PUEDEN ser válidos mucho después de que finalice la sesión de autenticación y el suscriptor haya abandonado la aplicación.
7.1.3 Identificación del dispositivo
Otros métodos de identificación segura de dispositivos, incluidos, entre otros, TLS mutuos, vinculación de tokens u otros
mecanismos, SE PUEDEN utilizar para establecer una sesión entre un suscriptor y un servicio.
38
Reautenticación
La continuidad de las sesiones autenticadas DEBE basarse en la posesión de un secreto de sesión emitido por el verificador en el
momento de la autenticación y, opcionalmente, actualizado durante la sesión. La naturaleza de una sesión depende de la
aplicación, que incluye:
1. Una sesión de navegador web con una cookie de "sesión", o

2. Una instancia de una aplicación móvil que conserva un secreto de sesión.
Los secretos de la sesión DEBEN ser no persistentes. Es decir, NO SE DEBEN retener al reiniciar la aplicación
asociada o al reiniciar el dispositivo host.
Se DEBE realizar una reautenticación periódica de las sesiones para confirmar la presencia continua del abonado en una
sesión autenticada (es decir, que el abonado no se ha marchado sin cerrar la sesión).
Una sesión NO DEBE extenderse más allá de las pautas en Secciones 4.1.3 , 4.2.3 y 4.3.3
(dependiendo de AAL) basado únicamente en la presentación del secreto de la sesión. Antes de la expiración de la sesión, el límite de
tiempo de reautenticación DEBERÁ extenderse solicitando al suscriptor los factores de autenticación especificados en la Tabla 7-1.
Cuando una sesión ha finalizado, debido a un tiempo de espera u otra acción, el usuario DEBE ser requerido para establecer una
nueva sesión autenticándose nuevamente.
Tabla 7-1 - Requisitos de reautenticación de AAL
AAL Requisito
1 Presentación de cualquier factor
2 Presentación de un secreto memorizado o presentación biométrica de
3 todos los factores
Nota: En AAL2, se requiere un secreto o biométrico memorizado, y no un autenticador físico, porque el

secreto de sesión es algo que tienes y se requiere un factor de autenticación adicional para continuar la
sesión.
7.2.1 Reautenticación de una federación o afirmación
Cuando se utiliza un protocolo de federación como se describe en SP 800-63C , Sección 5 para conectar el CSP y el RP, se
aplican consideraciones especiales a la gestión de sesiones y la reautenticación. El protocolo de federación comunica un evento
de autenticación entre el CSP y el RP pero no establece ninguna sesión entre ellos. Dado que el CSP y el RP a menudo emplean
tecnologías de gestión de sesiones independientes, NO se supondrá ninguna correlación entre estas sesiones. En consecuencia,
cuando una sesión de RP expira y el RP requiere una reautenticación, es completamente
39
Es posible que la sesión en el CSP no haya expirado y que se pueda generar una nueva aserción a partir de esta sesión en
el CSP sin volver a autenticar al usuario.
Un RP que requiera reautenticación a través de un protocolo de federación DEBE, si es posible dentro del protocolo,
especificar la edad de autenticación máxima aceptable para el CSP, y el CSP DEBERÁ reautenticar al suscriptor si no se ha
autenticado dentro de ese período de tiempo. El CSP DEBE comunicar el tiempo del evento de autenticación al RP para
permitirle al RP decidir si la aserción es suficiente para la reautenticación y para determinar el tiempo para el próximo evento
de reautenticación.
40
8 Consideraciones de seguridad y amenazas
Amenazas del autenticador
Un atacante que puede obtener el control de un autenticador a menudo podrá hacerse pasar por el propietario del autenticador. Las
amenazas a los autenticadores se pueden clasificar en función de los ataques a los tipos de factores de autenticación que componen el
autenticador:
• Algo que usted sabe puede ser revelado a un atacante. El atacante podría adivinar un secreto memorizado. Cuando el autenticador
es un secreto compartido, el atacante podría obtener acceso al CSP o al verificador y obtener el valor secreto o realizar un ataque
de diccionario en un hash de ese valor. Un atacante puede observar la entrada de un PIN o contraseña, encontrar un registro escrito
o una entrada en el diario de un PIN o contraseña, o puede instalar software malintencionado (por ejemplo, un registrador de
teclado) para capturar el secreto. Además, un atacante puede determinar el secreto a través de ataques fuera de línea a una base
de datos de contraseñas mantenida por el verificador.
• Algo que tienes puede perderse, dañarse, robarse al propietario o clonarse por un atacante. Por ejemplo, un atacante que
obtiene acceso a la computadora del propietario puede copiar un autenticador de software. Un autenticador de hardware
puede ser robado, manipulado o duplicado. Los secretos fuera de banda pueden ser interceptados por un atacante y
utilizados para autenticar su propia sesión.
• Algo que eres puede ser replicado. Por ejemplo, un atacante puede obtener una copia de la huella digital del
suscriptor y construir una réplica.
Este documento asume que el suscriptor no está en connivencia con un atacante que intenta autenticarse falsamente con el
verificador. Teniendo en cuenta esta suposición, las amenazas a los autenticadores utilizados para la autenticación digital se
enumeran en la Tabla 8-1, junto con algunos ejemplos.
Tabla 8-1 Amenazas del autenticador
Autenticador Descripción Ejemplo

Amenaza / Ataque
CSP comprometido afirma

El atacante genera una afirmación
identidad de un reclamante que no ha autenticado
falsa
adecuadamente
Afirmación
Fabricación o
Modificación
Proxy comprometido que cambia AAL de
El atacante modifica una
una autenticación
afirmación existente.
afirmación
Un atacante roba un Se roba un dispositivo criptográfico de hardware.

Robo
autenticador físico.
41

Amenaza / Ataque
Se roba un dispositivo OTP.
Se roba un autenticador secreto de búsqueda.
Roban un teléfono celular.

Se divulgan las contraseñas escritas en

papel.
Se copian las contraseñas almacenadas en un

archivo electrónico.
El autenticador del suscriptor

Autenticador de software PKI
Duplicación ha sido copiado con o sin su
(clave privada) copiada.
conocimiento.
Autenticador secreto de búsqueda

copiado.
Biométrico falsificado
autenticador fabricado.
Los secretos memorizados se obtienen

observando la entrada del teclado.
Secretos memorizados o
las salidas del autenticador son
El secreto del autenticador o la salida
Escuchando a escondidas interceptado por el software de registro de
del autenticador es
pulsaciones de teclas.
revelado al atacante cuando el suscriptor
se está autenticando.
Un PIN se captura desde un dispositivo de teclado

de PIN.
Un atacante obtiene y utiliza una

contraseña hash para
42

Amenaza / Ataque
otra autenticación (pasar el

ataque hash).
El atacante intercepta un secreto

Un secreto fuera de banda es
fuera de banda comprometiendo el
transmitido a través de Wi-Fi no cifrado y
recibido por el atacante.
canal de comunicación.
El autenticador se expone mediante Un autenticador de PKI de software está sujeto

métodos analíticos. a un ataque de diccionario para identificar la
Craqueo sin conexión
fuera de la autenticación contraseña correcta que se utilizará para
mecanismo. descifrar la clave privada.
Una clave se extrae mediante análisis de

potencia diferencial en un autenticador
criptográfico de hardware.
El secreto del autenticador se
Canal lateral expone mediante
Ataque características de la Un autenticador criptográfico
autenticador. El secreto se extrae mediante el análisis del
tiempo de respuesta del
autenticador en varios intentos.
La contraseña la revela el suscriptor de

un sitio web que se hace pasar por el
verificador.
Un suscriptor del banco revela un secreto

La salida del autenticador se captura memorizado en respuesta a una consulta por
Phishing o engañando al suscriptor haciéndole correo electrónico de un phisher que pretende
Pharming creer que el atacante es un verificador representar al banco.
o RP.
El suscriptor revela un secreto memorizado en

un sitio web de verificador falso al que se accede
mediante la suplantación de DNS.
43

Amenaza / Ataque
El suscriptor revela un secreto memorizado a

un compañero de oficina que solicita la
contraseña en nombre del jefe del suscriptor.
El atacante establece un nivel Un secreto memorizado se revela de confianza con un

suscriptor en por un suscriptor en un teléfono
Social para convencer al consulta de un atacante
Ingenieria suscriptor para revelar su disfrazado de sistema

secreto del autenticador o administrador.
salida del autenticador.
Un atacante recibe un secreto fuera de

banda enviado a través de SMS y ha
convencido al operador de que redirija el
teléfono móvil de la víctima al atacante.
Los ataques de diccionario en línea se utilizan para

adivinar secretos memorizados.
El atacante se conecta al verificador en
línea e intenta adivinar una salida de
Adivinar en línea autenticador válida en el contexto de ese
La adivinación en línea se utiliza para adivinar los
verificador.
resultados del autenticador para un dispositivo
OTP registrado a nombre de un reclamante
legítimo.
Código malicioso en el
Proxies de punto final acceso remoto Un autenticador criptográfico a un
autenticador conectado conectado al punto final se utiliza
sin el suscriptor para autenticar atacantes remotos.
consentimiento.
Punto final
Compromiso
La autenticación se realiza en nombre de
Código malicioso en el un atacante en lugar de
el punto final provoca la autenticación del suscriptor.
a otro que el previsto
verificador.
Una aplicación maliciosa en el endpoint lee un
secreto fuera de banda enviado
44

Amenaza / Ataque
vía SMS y el atacante usa el secreto para

autenticarse.
Código malicioso en el Proxies de código malicioso

el punto final compromete un software de factor de exportación o autenticación
múltiple criptográfico claves de autenticador del
autenticador. punto final.
Un atacante puede provocar un

Un atacante intercepta un
No autorizado autenticador en su
autenticador o clave de aprovisionamiento
Unión control para estar vinculado a la
en ruta al suscriptor.
cuenta de un suscriptor.
Estrategias de mitigación de amenazas
Los mecanismos relacionados que ayudan a mitigar las amenazas identificadas anteriormente se resumen en la Tabla 8-2.
Tabla 8-2 Mitigación de las amenazas del autenticador
Autenticador
Mitigación de amenazas Referencias normativas)
Amenaza / Ataque
Utilice autenticadores de múltiples factores que deben activarse a

través de un secreto memorizado o biométrico. 4.2.1 , 4.3.1
Robo
Utilice una combinación de autenticadores que incluya un secreto

4.2.1 , 4.3.1
memorizado o biométrico.
Utilice autenticadores de los que sea difícil extraer y

Duplicación duplicar secretos de autenticación a largo plazo. 4.2.2 , 4.3.2 , 5.1.7.1
Garantice la seguridad del punto final, especialmente con respecto a

la ausencia de malware como los registradores de claves, antes de su 4.2.2
uso.
Escuchando a escondidas
Evite el uso de redes inalámbricas que no sean de confianza como autenticación
secundaria fuera de banda sin cifrar 5.1.3.1
canales.
45
Autenticador
Mitigación de amenazas Referencias normativas)
Amenaza / Ataque
Autenticarse a través de canales protegidos autenticados (por

ejemplo, observe el icono de candado en la ventana del 4.1.2 , 4.2.2 , 4.3.2
navegador).
Utilice protocolos de autenticación que sean resistentes a los ataques de

5.2.8
repetición, como pasar-el-hash.
Utilice puntos finales de autenticación que empleen entradas confiables y

5.1.6.1 , 5.1.8.1
capacidades de visualización confiables.
Utilice un autenticador con un secreto de autenticador de 5.1.2.1 , 5.1.4.1 , 5.1.5.1 ,

alta entropía. 5.1.7.1 , 5.1.9.1
Desconectado
Agrietamiento
Almacene los secretos memorizados en forma de hash con sal, incluido un
5.1.1.2 , 5.2.7
hash con clave.
Utilice algoritmos de autenticación diseñados para mantener un consumo de energía

Canal lateral
y una sincronización constantes 4.3.2
Ataque
independientemente de los valores secretos.
Phishing o Utilice autenticadores que ofrezcan resistencia a la

5.2.5
Pharming suplantación de verificadores.
Evite el uso de autenticadores que presenten un riesgo de

Social
ingeniería social de terceros, como agentes de atención al cliente. 6.1.2.1 , 6.1.2.3
Ingenieria
Utilice autenticadores que generen una salida de alta entropía.

5.1.2.1 , 5.1.7.1 , 5.1.9.1
En línea
Adivinación
Utilice un autenticador que se bloquee después de varios intentos
5.2.2
fallidos repetidos de activación.
Utilice autenticadores de hardware que requieran una acción física por

5.2.9
parte del suscriptor.
Punto final
Compromiso
Mantenga las claves basadas en software en el almacenamiento de
5.1.3.1 , 5.1.6.1 , 5.1.8.1
acceso restringido.
No autorizado Utilice protocolos resistentes a MitM para el aprovisionamiento de

6.1
Unión autenticadores y claves asociadas.
Se pueden aplicar varias otras estrategias para mitigar las amenazas descritas en la Tabla 8-1:
46
• Múltiples factores hacen que los ataques exitosos sean más difíciles de lograr. Si un atacante necesita robar un autenticador
criptográfico y adivinar un secreto memorizado, entonces el trabajo para descubrir ambos factores puede ser demasiado alto.
• Mecanismos de seguridad física puede emplearse para proteger un autenticador robado de la duplicación. Los mecanismos de
seguridad física pueden proporcionar pruebas, detección y respuesta de alteraciones.
• Requerir el uso de secretos largamente memorizados que no aparecen en diccionarios comunes pueden obligar a los atacantes a
probar todos los valores posibles.
• Controles de seguridad del sistema y la red pueden emplearse para evitar que un atacante obtenga acceso a
un sistema o instale software malicioso.
• Entrenamiento periódico se puede realizar para garantizar que los suscriptores comprendan cuándo y cómo informar un
compromiso, o sospecha de compromiso, o reconocer patrones de comportamiento que puedan significar que un atacante
está intentando comprometer el proceso de autenticación.
• Técnicas fuera de banda puede emplearse para verificar la prueba de posesión de dispositivos registrados (por ejemplo,
teléfonos celulares).
Recuperación del autenticador
El punto débil de muchos mecanismos de autenticación es el proceso que se sigue cuando un suscriptor pierde el control de uno o más
autenticadores y necesita reemplazarlos. En muchos casos, las opciones que quedan disponibles para autenticar al suscriptor son limitadas y las
preocupaciones económicas (por ejemplo, el costo de mantenimiento de los centros de llamadas) motivan el uso de métodos de autenticación de
respaldo económicos y, a menudo, menos seguros. En la medida en que la recuperación del autenticador sea asistida por humanos, también
existe el riesgo de ataques de ingeniería social.
Para mantener la integridad de los factores de autenticación, es esencial que no sea posible aprovechar una autenticación que
involucre un factor para obtener un autenticador de un factor diferente. Por ejemplo, un secreto memorizado no debe poder utilizarse
para obtener una nueva lista de secretos de búsqueda.
Ataques de sesión
La discusión anterior se centra en las amenazas al evento de autenticación en sí, pero los ataques de secuestro en la sesión después
de un evento de autenticación pueden tener impactos de seguridad similares. Las pautas de gestión de sesiones en Sección 7 son
esenciales para mantener la integridad de la sesión contra ataques, como XSS. Además, es importante desinfectar toda la información
que se mostrará [ OWASP- XSS-prevención ] para asegurarse de que no contenga contenido ejecutable. Estas pautas también
recomiendan que los secretos de sesión se hagan inaccesibles para el código móvil para proporcionar una protección adicional contra la
exfiltración de secretos de sesión.
Otra amenaza posterior a la autenticación, la falsificación de solicitudes entre sitios (CSRF), aprovecha la tendencia de los usuarios a
tener varias sesiones activas al mismo tiempo. Es importante incrustar y verificar un identificador de sesión en las solicitudes web para
evitar que una URL válida o una solicitud se active de forma no intencionada o maliciosa.
47
9 Consideraciones de privacidad
Estas consideraciones de privacidad complementan la orientación de la Sección 4. Esta sección es informativa.
Evaluación de riesgos de privacidad
Secciones 4.1.5 , 4.2.5 y 4.3.5 exigir que el CSP lleve a cabo una evaluación de riesgos de privacidad para la retención de registros. Tal
evaluación de riesgo de privacidad incluiría:
1. La probabilidad de que la retención de registros pueda crear un problema para el suscriptor, como
invasividad o acceso no autorizado a la información.
2. El impacto si ocurriera tal problema.
Los CSP deben poder justificar razonablemente cualquier respuesta que tomen a los riesgos de privacidad identificados, incluida la
aceptación del riesgo, mitigar el riesgo y compartir el riesgo. El uso del consentimiento del suscriptor es una forma de compartir el riesgo y,
por lo tanto, es apropiado para su uso solo cuando se pueda esperar razonablemente que un suscriptor tenga la capacidad de evaluar y
aceptar el riesgo compartido.
Controles de privacidad
Sección 4.4 requiere que los CSP empleen controles de privacidad personalizados. SP 800-53 proporciona un conjunto de controles de
privacidad para que los CSP los consideren al implementar mecanismos de autenticación. Estos controles cubren avisos, reparaciones y otras
consideraciones importantes para implementaciones exitosas y confiables.
Limitación de procesamiento
Sección 4.4 requiere que los CSP utilicen medidas para mantener los objetivos de previsibilidad (permitiendo suposiciones confiables
por parte de individuos, propietarios y operadores sobre la PII y su procesamiento por un sistema de información) y manejabilidad
(proporcionando la capacidad de administración granular de PII, incluida la alteración, eliminación y divulgación selectiva) acorde con
los riesgos de privacidad que pueden surgir del procesamiento de atributos para fines distintos de la prueba de identidad, autenticación,
autorización o afirmación de atributos, mitigación de fraude relacionado o para cumplir con la ley o el proceso legal [ NISTIR8062 ].
Los CSP pueden tener varios propósitos comerciales para procesar atributos, incluido el suministro de servicios sin identidad a los suscriptores.
Sin embargo, los atributos de procesamiento para fines distintos al servicio de identidad puede crear riesgos de privacidad cuando las personas no
esperan o no se sienten cómodos con el procesamiento adicional. Los CSP pueden determinar las medidas apropiadas acordes con el riesgo de
privacidad que surge del procesamiento adicional. Por ejemplo, en ausencia de una ley, regulación o política aplicable, puede que no sea
necesario obtener un consentimiento explícito al procesar atributos para proporcionar servicios sin identidad solicitados por los suscriptores,
aunque los avisos pueden ayudar a los suscriptores a mantener suposiciones confiables sobre el procesamiento. (previsibilidad) . Otro
procesamiento de atributos puede conllevar diferentes riesgos de privacidad que requieren obtener un consentimiento explícito o permitir a los
suscriptores un mayor control sobre el uso o la divulgación de atributos específicos. (manejabilidad) . El consentimiento del suscriptor debe ser
significativo; por lo tanto, cuando los CSP utilizan medidas de consentimiento, no pueden hacer que la aceptación por parte del suscriptor de usos
adicionales sea una condición para proporcionar el servicio de identidad.
48
Consulte a su SAOP si tiene dudas sobre si el procesamiento propuesto queda fuera del alcance del procesamiento
permitido o de las medidas apropiadas de mitigación de riesgos de privacidad.
Cumplimiento de privacidad específico de la agencia
Sección 4.4 cubre obligaciones de cumplimiento específicas para los CSP federales. Es fundamental involucrar al SAOP de su
agencia en las primeras etapas del desarrollo del sistema de autenticación digital para evaluar y mitigar los riesgos de privacidad y
asesorar a la agencia sobre los requisitos de cumplimiento, como si la recopilación de PII para emitir o mantener autenticadores
desencadena la Ley de Privacidad de 1974 [ Acto privado ] o el Ley de gobierno electrónico de 2002 [ E-Gov ] requisito para realizar una
PIA. Por ejemplo, con respecto al mantenimiento centralizado de datos biométricos, es probable que los requisitos de la Ley de
Privacidad se activen y requieran la cobertura de un sistema de registros de la Ley de Privacidad nuevo o existente debido a la
recopilación y mantenimiento de PII y cualquier otro atributo necesario para autenticación. La SAOP también puede ayudar a la
agencia a determinar si se requiere una PIA.
Estas consideraciones no deben interpretarse como un requisito para desarrollar una ley de privacidad SORN o PIA solo para la
autenticación. En muchos casos, tendrá más sentido redactar un PIA y un SORN que abarque todo el proceso de autenticación
digital o incluir el proceso de autenticación digital como parte de un PIA programático más amplio que analice el servicio o
beneficio al que la agencia está estableciendo en línea.
Debido a los muchos componentes de la autenticación digital, es importante que la SAOP conozca y comprenda cada componente
individual. Por ejemplo, otros artefactos de privacidad pueden ser aplicables a una agencia que ofrece o utiliza servicios de RP o
CSP federados (por ejemplo, acuerdos de uso de datos, acuerdos de emparejamiento de computadoras). La SAOP puede ayudar a
la agencia a determinar qué requisitos adicionales se aplican. Además, una comprensión profunda de los componentes individuales
de la autenticación digital permitirá a la SAOP evaluar y mitigar a fondo los riesgos de privacidad, ya sea a través de procesos de
cumplimiento o por otros medios.
49
10 Consideraciones de usabilidad
ISO / IEC 9241-11 define la usabilidad como la "medida en que usuarios específicos pueden usar un producto para lograr
objetivos específicos con efectividad, eficiencia y satisfacción en un contexto de uso específico". Esta definición se centra en los
usuarios, sus objetivos y el contexto de uso como elementos clave necesarios para lograr eficacia, eficiencia y satisfacción. Es
necesario un enfoque holístico que tenga en cuenta estos elementos clave para lograr la usabilidad.
El objetivo de un usuario para acceder a un sistema de información es realizar una tarea prevista. La autenticación es la función que
habilita este objetivo. Sin embargo, desde la perspectiva del usuario, la autenticación se interpone entre ellos y su tarea prevista. El
diseño y la implementación efectivos de la autenticación hacen que sea fácil hacer lo correcto, difícil hacer lo incorrecto y fácil de
recuperar cuando sucede algo incorrecto.
Las organizaciones deben ser conscientes de las implicaciones generales de todo el ecosistema de autenticación digital de sus partes
interesadas. Los usuarios a menudo emplean uno o más autenticadores, cada uno para un RP diferente. Luego, luchan por recordar las
contraseñas, recordar qué autenticador va con qué RP y para llevar varios dispositivos de autenticación física. La evaluación de la usabilidad de
la autenticación es fundamental, ya que la mala usabilidad a menudo resulta en mecanismos de afrontamiento y soluciones temporales no
deseadas que, en última instancia, pueden degradar la eficacia de los controles de seguridad.
La integración de la usabilidad en el proceso de desarrollo puede conducir a soluciones de autenticación que sean seguras y utilizables al
mismo tiempo que abordan las necesidades de autenticación de los usuarios y los objetivos comerciales de las organizaciones.
El impacto de la usabilidad en los sistemas digitales debe considerarse como parte de la evaluación de riesgos al momento de
decidir el AAL apropiado. Los autenticadores con un AAL más alto a veces ofrecen una mejor usabilidad y deberían permitirse
su uso para aplicaciones de AAL más bajo.
Aprovechar la federación para la autenticación puede aliviar muchos de los problemas de usabilidad, aunque tal enfoque tiene sus propias
compensaciones, como se analiza en SP 800-63C .
Esta sección proporciona consideraciones generales de usabilidad y posibles implementaciones, pero no recomienda soluciones
específicas. Las implementaciones mencionadas son ejemplos para fomentar enfoques tecnológicos innovadores para abordar
necesidades específicas de usabilidad. Además, las consideraciones de usabilidad y sus implementaciones son sensibles a muchos
factores que impiden una solución única para todos. Por ejemplo, un tamaño de fuente que funciona en el entorno informático de escritorio
puede obligar al texto a desplazarse fuera de la pantalla de un pequeño dispositivo OTP. Realizar una evaluación de usabilidad en el
autenticador seleccionado es un componente crítico de la implementación. Es importante realizar evaluaciones con usuarios
representativos, metas y tareas realistas y contextos de uso apropiados.
SUPUESTOS
En esta sección, el término "usuarios" significa "reclamantes" o "suscriptores". Las pautas y
consideraciones se describen desde la perspectiva de los usuarios.
50
La accesibilidad difiere de la usabilidad y está fuera del alcance de este documento. Sección 508 fue promulgada para eliminar las barreras
en la tecnología de la información y exigir a las agencias federales que hagan que su contenido público en línea sea accesible para las
personas con discapacidades. Consulte la ley y los estándares de la Sección 508 para obtener una guía de accesibilidad.
Consideraciones de usabilidad comunes a los autenticadores
Al seleccionar e implementar un sistema de autenticación, considere la usabilidad a lo largo de todo el ciclo de vida de los
autenticadores seleccionados (por ejemplo, uso típico y eventos intermitentes), teniendo en cuenta la combinación de usuarios, sus
objetivos y el contexto de uso.
Por lo general, un solo tipo de autenticador no es suficiente para toda la población de usuarios. Por lo tanto, siempre que sea
posible, según los requisitos de AAL, los CSP deben admitir tipos de autenticadores alternativos y permitir que los usuarios elijan en
función de sus necesidades. La inmediatez de la tarea, las compensaciones de costo-beneficio percibidas y la falta de familiaridad
con ciertos autenticadores a menudo afectan la elección. Los usuarios tienden a elegir opciones que generan la menor carga o
costo en ese momento. Por ejemplo, si una tarea requiere acceso inmediato a un sistema de información, un usuario puede preferir
crear una nueva cuenta y contraseña en lugar de seleccionar un autenticador que requiera más pasos. Alternativamente, los
usuarios pueden elegir una opción de identidad federada, aprobada en la AAL correspondiente, si ya tienen una cuenta con un
proveedor de identidad. Los usuarios pueden comprender algunos autenticadores mejor que otros,
Las experiencias positivas de autenticación de usuarios son parte integral del éxito de una organización que logre los resultados comerciales
deseados. Por lo tanto, deben esforzarse por considerar a los autenticadores desde la perspectiva de los usuarios. El objetivo general de la
usabilidad de la autenticación es minimizar la carga del usuario y la fricción de autenticación (por ejemplo, la cantidad de veces que un usuario
debe autenticarse, los pasos involucrados y la cantidad de información que debe rastrear). El inicio de sesión único ejemplifica una de estas
estrategias de minimización.
Las consideraciones de usabilidad aplicables a la mayoría de los autenticadores se describen a continuación. Las secciones siguientes
describen las consideraciones de usabilidad específicas de un autenticador en particular.
Las consideraciones de usabilidad para el uso típico de todos los autenticadores incluyen:
• Proporcione información sobre el uso y mantenimiento del autenticador (por ejemplo, qué hacer si el autenticador se
pierde o es robado, instrucciones de uso), especialmente si existen diferentes requisitos para el primer uso o la
inicialización.
• La disponibilidad del autenticador también debe tenerse en cuenta, ya que los usuarios deberán recordar tener su
autenticador disponible. Considere la necesidad de opciones de autenticación alternativas para proteger contra pérdidas,
daños u otros impactos negativos en el autenticador original.
• Siempre que sea posible, según los requisitos de AAL, los usuarios deben contar con opciones de autenticación alternativas. Esto
permite a los usuarios elegir un autenticador en función de su contexto, objetivos y tareas (por ejemplo, la frecuencia e inmediatez de
la tarea). Las opciones de autenticación alternativas también ayudan a abordar los problemas de disponibilidad que pueden ocurrir
con un autenticador en particular.
• Características del texto de cara al usuario:
51
o Escriba texto de cara al usuario (por ejemplo, instrucciones, avisos, notificaciones, mensajes de error)
en un lenguaje sencillo para la audiencia destinataria. Evite la jerga técnica y, por lo general, escriba para un nivel de
alfabetización de sexto a octavo grado.
o Tenga en cuenta la legibilidad del texto introducido y de cara al usuario, incluido el estilo de fuente,
tamaño, color y contraste con el fondo circundante. El texto ilegible contribuye a errores de entrada del usuario.
Para mejorar la legibilidad, considere el uso de:
• Alto contraste. El mayor contraste es el negro sobre blanco.
• Fuentes sans serif para pantallas electrónicas. Fuentes serif para materiales impresos.
• Fuentes que distinguen claramente entre caracteres fácilmente confundibles (por ejemplo, la letra
mayúscula "O" y el número "0").
• Un tamaño de fuente mínimo de 12 puntos, siempre que el texto se ajuste para mostrarse en el dispositivo.
• Experiencia del usuario durante la entrada del autenticador:

o Ofrezca la opción de mostrar texto durante la entrada, ya que la entrada de texto enmascarado es propensa a errores.
Una vez que un carácter determinado se muestra el tiempo suficiente para que el usuario lo vea, se puede ocultar.
Tenga en cuenta el dispositivo al determinar el tiempo de retardo de enmascaramiento, ya que se tarda más en
ingresar secretos memorizados en dispositivos móviles (por ejemplo, tabletas y teléfonos inteligentes) que en las
computadoras de escritorio tradicionales. Asegúrese de que la duración del retardo de enmascaramiento sea
coherente con las necesidades del usuario.
o Asegúrese de que el tiempo permitido para la entrada de texto sea adecuado (es decir, la pantalla de entrada no
tiempo de espera prematuramente). Asegúrese de que los tiempos de entrada de texto permitidos sean coherentes
con las necesidades del usuario.
o Proporcione comentarios claros, significativos y procesables sobre los errores de entrada para reducir
confusión y frustración. Las implicaciones de usabilidad importantes surgen cuando los usuarios no saben que han
ingresado texto incorrectamente.
o Permita al menos 10 intentos de entrada para los autenticadores que requieran la entrada del
salida del autenticador por parte del usuario. Cuanto más largo y complejo sea el texto de entrada, mayor será la
probabilidad de errores de entrada del usuario.
o Proporcione comentarios claros y significativos sobre el número de intentos permitidos restantes.
Para la limitación de la velocidad (es decir, la aceleración), informe a los usuarios cuánto tiempo deben esperar hasta
el próximo intento para reducir la confusión y la frustración.
• Minimice el impacto de las restricciones de factor de forma, como áreas táctiles y de visualización limitadas en dispositivos móviles:
o Las áreas táctiles más grandes mejoran la facilidad de uso para la entrada de texto desde que se escribe en dispositivos pequeños
es mucho más propenso a errores y requiere más tiempo que escribir en un teclado de tamaño completo. Cuanto más
pequeño sea el teclado en pantalla, más difícil será escribir, debido al tamaño del mecanismo de entrada (por ejemplo,
un dedo) en relación con el tamaño del objetivo en pantalla.
o Siga un buen diseño de información e interfaz de usuario para pantallas pequeñas.
Los eventos intermitentes incluyen eventos como la reautenticación, el bloqueo de la cuenta, el vencimiento, la revocación, el daño,
la pérdida, el robo y el software no funcional.
Las consideraciones de usabilidad para eventos intermitentes entre tipos de autenticadores incluyen:
52
• Para evitar que los usuarios necesiten volver a autenticarse debido a la inactividad del usuario, solicite a los usuarios que activen la
actividad justo antes (por ejemplo, 2 minutos) de que se agote el tiempo de inactividad.
• Indique a los usuarios con el tiempo adecuado (por ejemplo, 1 hora) para guardar su trabajo antes del evento de
reautenticación periódica fijo requerido independientemente de la actividad del usuario.
• Comunique claramente cómo y dónde adquirir asistencia técnica. Por ejemplo, proporcione a los usuarios información como un
enlace a una función de autoservicio en línea, sesiones de chat o un número de teléfono para el soporte de la mesa de ayuda.
Idealmente, se puede proporcionar suficiente información para permitir que los usuarios se recuperen de eventos intermitentes por sí
mismos sin intervención externa.
Consideraciones de usabilidad por tipo de autenticador

Además de las consideraciones generales de usabilidad descritas anteriormente, aplicables a la mayoría de los autenticadores ( Sección
10.1 ), las siguientes secciones describen otras consideraciones de usabilidad específicas de tipos de autenticadores particulares.
10.2.1 Secretos memorizados
Uso típico
Los usuarios ingresan manualmente el secreto memorizado (comúnmente conocido como contraseña o PIN). Las consideraciones de
usabilidad para el uso típico incluyen:
• Memorabilidad del secreto memorizado.

o La probabilidad de que se produzcan fallos en la recuperación aumenta a medida que hay más elementos para que los usuarios
recuerda. Con menos secretos memorizados, los usuarios pueden recordar más fácilmente el secreto
memorizado específico necesario para un RP en particular.
o La carga de memoria es mayor para una contraseña que se usa con menos frecuencia.
• Experiencia del usuario durante la entrada del secreto memorizado.

o Admite la funcionalidad de copiar y pegar en los campos para ingresar secretos memorizados,
incluyendo frases de contraseña.
Eventos intermitentes
Las consideraciones de usabilidad para eventos intermitentes incluyen:
• Cuando los usuarios crean y cambian secretos memorizados:

o Comunique claramente la información sobre cómo crear y cambiar la memoria
misterios.
o Comunique claramente los requisitos secretos memorizados, como se especifica en Sección
5.1.1 .
o Permita al menos 64 caracteres de longitud para admitir el uso de frases de contraseña.
Anime a los usuarios a hacer que los secretos memorizados sean tan extensos como quieran, utilizando los caracteres
que les gusten (incluidos los espacios), lo que ayuda a la memorización.
o No imponga otras reglas de composición (por ejemplo, mezclas de diferentes tipos de caracteres)
sobre secretos memorizados.
53
o No requiera que los secretos memorizados se cambien arbitrariamente (por ejemplo, periódicamente)
a menos que haya una solicitud de usuario o evidencia de compromiso del autenticador. (Ver Sección
5.1.1 para informacion adicional).
• Proporcione comentarios claros, significativos y procesables cuando se rechacen las contraseñas elegidas (por ejemplo, cuando
aparece en una "lista negra" de contraseñas inaceptables o se ha utilizado anteriormente).
10.2.2 Secretos de búsqueda
Uso típico
Los usuarios utilizan el autenticador, impreso o electrónico, para buscar los secretos apropiados necesarios para responder a la solicitud de un
verificador. Por ejemplo, se le puede pedir a un usuario que proporcione un subconjunto específico de cadenas numéricas o de caracteres
impresas en una tarjeta en formato de tabla.
Las consideraciones de usabilidad para el uso típico incluyen:
• Experiencia del usuario durante la entrada de secretos de búsqueda.

o Tenga en cuenta la complejidad y el tamaño de las indicaciones. Cuanto mayor sea el subconjunto de secretos
Se solicita al usuario que busque, mayores serán las implicaciones de usabilidad. Tanto la carga de trabajo cognitiva
como la dificultad física para la entrada deben tenerse en cuenta al seleccionar la cantidad y complejidad de los
secretos de búsqueda para la autenticación.
10.2.3 Fuera de banda
Uso típico
La autenticación fuera de banda requiere que los usuarios tengan acceso a un canal de comunicación primario y
secundario.
Consideraciones de usabilidad para uso típico:
• Notifique a los usuarios la recepción de un secreto en un dispositivo bloqueado. Sin embargo, si el dispositivo fuera de banda
está bloqueado, se debe requerir autenticación en el dispositivo para acceder al secreto.
• Dependiendo de la implementación, considere las restricciones de factor de forma, ya que son particularmente problemáticas
cuando los usuarios deben ingresar texto en dispositivos móviles. Proporcionar áreas táctiles más grandes mejorará la usabilidad
para ingresar secretos en dispositivos móviles.
• Una mejor opción de usabilidad es ofrecer funciones que no requieran la entrada de texto en dispositivos móviles (por ejemplo,
un solo toque en la pantalla o una función de copia para que los usuarios puedan copiar y pegar secretos fuera de banda).
Proporcionar a los usuarios estas funciones es particularmente útil cuando los canales primario y secundario están en el mismo
dispositivo. Por ejemplo, es difícil para los usuarios transferir el secreto de autenticación en un teléfono inteligente porque
deben alternar entre la aplicación fuera de banda y el canal principal, posiblemente varias veces.
10.2.4 Dispositivo OTP de factor único
Uso típico
54
Los usuarios acceden a la OTP generada por el dispositivo OTP de factor único. La salida del autenticador generalmente se muestra en
el dispositivo y el usuario la ingresa para el verificador.
• La salida del autenticador permite al menos un minuto entre cambios, pero idealmente permite a los usuarios los dos minutos
completos como se especifica en Sección 5.1.4.1 . Los usuarios necesitan tiempo suficiente para ingresar a la salida del autenticador
(incluido mirar hacia adelante y hacia atrás entre el dispositivo OTP de factor único y la pantalla de entrada).
• Dependiendo de la implementación, las siguientes son consideraciones de usabilidad adicionales para los implementadores:
o Si el dispositivo OTP de factor único proporciona su salida a través de una interfaz electrónica (por ejemplo,
USB) esto es preferible ya que los usuarios no tienen que ingresar manualmente la salida del autenticador. Sin embargo, si
se requiere una entrada física (por ejemplo, presionar un botón) para operar, la ubicación de los puertos USB podría
plantear dificultades de uso. Por ejemplo, los puertos USB de algunas computadoras están ubicados en la parte posterior
de la computadora y serán difíciles de alcanzar para los usuarios.
o La disponibilidad limitada de una interfaz de computadora directa, como un puerto USB, podría suponer
dificultades de usabilidad. Por ejemplo, la cantidad de puertos USB en las computadoras portátiles suele ser muy
limitada. Esto puede obligar a los usuarios a desconectar otros periféricos USB para utilizar el dispositivo OTP de factor
único.
10.2.5 Dispositivo OTP multifactor
Uso típico
Los usuarios acceden a la OTP generada por el dispositivo OTP multifactor a través de un segundo factor de autenticación. La OTP
generalmente se muestra en el dispositivo y el usuario la ingresa manualmente para el verificador. El segundo factor de autenticación puede
lograrse a través de algún tipo de teclado de entrada integral para ingresar un secreto memorizado, un lector biométrico integral (por ejemplo, de
huellas dactilares) o una interfaz de computadora directa (por ejemplo, puerto USB). También se aplican las consideraciones de usabilidad para
el factor adicional; consulte Sección 10.2.1 para los secretos memorizados y Sección 10.4 para datos biométricos utilizados en autenticadores de
múltiples factores.
• Experiencia del usuario durante la entrada manual de la salida del autenticador.

o Para la OTP basada en tiempo, proporcione un período de gracia además del tiempo durante el cual
se muestra la OTP. Los usuarios necesitan tiempo suficiente para ingresar a la salida del autenticador,
incluida la visualización entre el dispositivo OTP multifactor y la pantalla de entrada.
o Considere las restricciones de factor de forma si los usuarios deben desbloquear el dispositivo OTP de múltiples factores
a través de un panel de entrada integral o ingrese la salida del autenticador en dispositivos móviles. Escribir en
dispositivos pequeños es mucho más propenso a errores y requiere más tiempo que escribir en un teclado tradicional.
Cuanto más pequeños sean el teclado de entrada integral y el teclado en pantalla, más difícil será escribir.
Proporcionar áreas táctiles más grandes
55
mejora la usabilidad para desbloquear el dispositivo OTP multifactor o ingresar la salida del autenticador
en dispositivos móviles.
o La disponibilidad limitada de una interfaz de computadora directa como un puerto USB podría plantear
dificultades de usabilidad. Por ejemplo, las computadoras portátiles a menudo tienen un número limitado de puertos USB,
lo que puede obligar a los usuarios a desconectar otros periféricos USB para usar el dispositivo OTP de múltiples factores.
10.2.6 Software criptográfico de factor único
Uso típico
Los usuarios se autentican demostrando la posesión y el control de la clave de software criptográfico. Las consideraciones de
• Proporcione a las claves criptográficas nombres adecuadamente descriptivos que sean significativos para los usuarios, ya que los
usuarios deben reconocer y recordar qué clave criptográfica utilizar para qué tarea de autenticación. Esto evita que los usuarios
tengan que lidiar con múltiples claves criptográficas con nombres similares y ambiguos. La selección de varias claves criptográficas
en dispositivos móviles más pequeños puede ser particularmente problemático si los nombres de las claves criptográficas se
acortan debido al tamaño reducido de la pantalla.
10.2.7 Dispositivo criptográfico de factor único
Uso típico
Los usuarios se autentican probando la posesión del dispositivo criptográfico de factor único. Las consideraciones de
• Requerir una entrada física (por ejemplo, presionar un botón) para operar el dispositivo criptográfico de factor único podría plantear
dificultades de uso. Por ejemplo, algunos puertos USB se encuentran en la parte posterior de las computadoras, lo que dificulta el
acceso de los usuarios.
• La disponibilidad limitada de una interfaz de computadora directa como un puerto USB podría plantear dificultades de uso. Por
ejemplo, las computadoras portátiles a menudo tienen un número limitado de puertos USB, lo que puede obligar a los usuarios a
desconectar otros periféricos USB para usar el dispositivo criptográfico de factor único.
10.2.8 Software criptográfico multifactor
Uso típico
Para autenticarse, los usuarios prueban la posesión y el control de la clave criptográfica almacenada en el disco o algún otro medio
“blando” que requiera activación. La activación se realiza mediante la entrada de un segundo factor de autenticación, ya sea un secreto
memorizado o biométrico. También se aplican las consideraciones de usabilidad para el factor adicional; consulte Sección 10.2.1 para los
secretos memorizados y Sección
10,4 para datos biométricos utilizados en autenticadores multifactor.
56
usuarios deben reconocer y recordar qué clave criptográfica utilizar para qué tarea de autenticación. Esto evita que los usuarios
tengan que lidiar con múltiples claves criptográficas con nombres similares y ambiguos. La selección de varias claves criptográficas
en dispositivos móviles más pequeños puede ser particularmente problemático si los nombres de las claves criptográficas se
acortan debido al tamaño reducido de la pantalla.
10.2.9 Dispositivo criptográfico multifactor
Uso típico
Los usuarios se autentican probando la posesión del dispositivo criptográfico multifactor y el control de la clave criptográfica protegida. El
dispositivo se activa mediante un segundo factor de autenticación, ya sea un secreto memorizado o biométrico. También se aplican las
consideraciones de usabilidad para el factor adicional; consulte Sección 10.2.1 para los secretos memorizados y Sección 10.4 para datos
biométricos utilizados en autenticadores de múltiples factores.
• No exija a los usuarios que mantengan conectados los dispositivos criptográficos multifactor después de la autenticación. Los
usuarios pueden olvidar desconectar el dispositivo criptográfico multifactor cuando terminan de usarlo (por ejemplo, olvidando
una tarjeta inteligente en el lector de tarjetas inteligentes y alejándose de la computadora).
o Los usuarios deben estar informados sobre si el criptográfico multifactor

Se requiere el dispositivo para permanecer conectado o no.
usuarios deben reconocer y recordar qué clave criptográfica utilizar para qué tarea de autenticación. Esto evita que los usuarios se
enfrenten a múltiples claves criptográficas con nombres similares y ambiguos. La selección de varias claves criptográficas en
dispositivos móviles más pequeños (como teléfonos inteligentes) puede ser particularmente problemático si los nombres de las
claves criptográficas se acortan debido al tamaño reducido de la pantalla.
• La disponibilidad limitada de una interfaz de computadora directa como un puerto USB podría plantear dificultades de uso. Por
ejemplo, las computadoras portátiles a menudo tienen un número limitado de puertos USB, lo que puede obligar a los usuarios a
desconectar otros periféricos USB para usar el dispositivo criptográfico multifactor.
Resumen de consideraciones de usabilidad
La Tabla 10-1 resume las consideraciones de usabilidad para el uso típico y los eventos intermitentes para cada tipo de autenticador.
Muchas de las consideraciones de usabilidad para el uso típico se aplican a la mayoría de los tipos de autenticadores, como se muestra en
las filas. La tabla destaca características de usabilidad comunes y divergentes entre los tipos de autenticadores. Cada columna permite a los
lectores identificar fácilmente los atributos de usabilidad a abordar para cada autenticador. Dependiendo de los objetivos de los usuarios y el
contexto de uso, ciertos atributos pueden valorarse sobre otros. Siempre que sea posible, proporcione tipos de autenticadores alternativos y
permita que los usuarios elijan entre ellos.
57
Los autenticadores multifactor (por ejemplo, dispositivos OTP multifactor, software criptográfico multifactor y dispositivos criptográficos
multifactor) también heredan las consideraciones de usabilidad de su factor secundario. Como la biometría solo se permite como factor
de activación en las soluciones de autenticación multifactor, las consideraciones de usabilidad para la biometría no se incluyen en la
Tabla 10-1 y se analizan en Sección 10.4 .
Tabla 10-1 - Resumen de consideraciones de usabilidad por tipo de autenticador
Dispositivo OTP de factor único
Dispositivo OTP multifactor
Dispositivo criptográfico
Software criptográfico
Secretos memorizados
Secretos de búsqueda
Fuera de banda
Factor único
Factor único
Multifactor
Multifactor
Consideración de usabilidad
Uso típico
Disponibilidad del autenticador -

autenticadores fácilmente en posesión del • • • • • • • • •
usuario
Lenguaje sencillo para el texto de cara al usuario (por

ejemplo, instrucciones, avisos, notificaciones, mensajes de • • • • • • • • •
error)
Legibilidad del texto de cara al usuario o del texto

• • • • • • • • •
introducido por los usuarios
Entrada de texto sin máscara • • • •
Admite entrada de texto: longitud de 64

•
caracteres, copiar y pegar
Enmascaramiento retardado durante la entrada de texto •
Se permite tiempo suficiente para la entrada de texto • • • • •
Errores de entrada: se necesitan comentarios claros y

• • • • •
significativos
Mínimo de 10 intentos permitidos • • • • •
Intentos restantes permitidos: se necesitan

• • • • •
comentarios claros y significativos
Restricciones de factor de forma • • • • • • • • •
Ubicación y disponibilidad de una interfaz de

• • • •
computadora directa, como un puerto USB
58
Dispositivo OTP de factor único
Dispositivo OTP multifactor
Secretos memorizados
Secretos de búsqueda
Fuera de banda
Factor único
Factor único
Multifactor
Multifactor
Consideración de usabilidad
Se requiere entrada física (como presionar un botón)

• •
Las claves criptográficas necesitan nombres descriptivos

• • •
y significativos
Complejidad y tamaño de las indicaciones. •
Autenticación al dispositivo secundario para acceder al

•
secreto de autenticación
No se requiere conexión continua de hardware

•
Reautenticación debido a inactividad del usuario • • • • • • • • •
Reautenticación periódica fija • • • • • • • • •
Provisiones para asistencia técnica • • • • • • • • •
Disposiciones para crear y cambiar secretos

•
memorizados
Consideraciones de usabilidad biométrica
Esta sección proporciona una descripción general de alto nivel de las consideraciones generales de usabilidad para la biometría. Se puede
encontrar una discusión más detallada sobre la usabilidad biométrica en Usabilidad y biometría, asegurando sistemas biométricos exitosos Usabilidad
NIST .
Aunque existen otras modalidades biométricas, las siguientes tres modalidades biométricas se utilizan con más frecuencia para la
autenticación: huella dactilar, rostro e iris.
Uso típico
• Para todas las modalidades, la familiaridad del usuario y la práctica con el dispositivo mejoran el rendimiento.
• Las prestaciones del dispositivo (es decir, las propiedades de un dispositivo que permiten al usuario realizar una acción), la
retroalimentación y las instrucciones claras son fundamentales para el éxito del usuario con el dispositivo biométrico. Por ejemplo,
proporcione instrucciones claras sobre las acciones necesarias para la detección de actividad.
59
• Idealmente, los usuarios pueden seleccionar la modalidad con la que se sientan más cómodos para su segundo factor de
autenticación. La población de usuarios puede sentirse más cómoda y familiarizada con, y aceptar, algunas modalidades
biométricas que otras.
• Experiencia de usuario con la biometría como factor de activación.
o Proporcione comentarios claros y significativos sobre el número de intentos permitidos restantes.
Por ejemplo, para limitar la velocidad (es decir, estrangulamiento), informe a los usuarios del período de tiempo que
deben esperar hasta el próximo intento para reducir la confusión y la frustración del usuario.
• Consideraciones de usabilidad de huellas dactilares:

o Los usuarios deben recordar qué dedo (s) utilizaron para la inscripción inicial.
o La cantidad de humedad en los dedos afecta la capacidad del sensor para
capturar.
o Los factores adicionales que influyen en la calidad de la captura de huellas dactilares incluyen la edad, el género y
ocupación (por ejemplo, los usuarios que manipulan productos químicos o que trabajan mucho con las manos
pueden tener crestas de fricción degradadas).
• Consideraciones de usabilidad enfrentadas:

o Los usuarios deben recordar si usaron algún artefacto (por ejemplo, anteojos) durante
inscripción porque afecta la precisión del reconocimiento facial.
o Las diferencias en las condiciones de iluminación ambiental pueden afectar el reconocimiento facial
exactitud.
o Las expresiones faciales afectan la precisión del reconocimiento facial (p. Ej., Sonriendo versus neutral
expresión).
o Las poses faciales afectan la precisión del reconocimiento facial (p. Ej., Mirar hacia abajo o lejos de
la Cámara).
• Consideraciones de usabilidad de Iris:
o El uso de contactos de colores puede afectar la precisión del reconocimiento del iris.
o Es posible que los usuarios que se hayan sometido a una cirugía ocular deban volver a inscribirse después de la cirugía.
o Las diferencias en las condiciones de iluminación ambiental pueden afectar el reconocimiento del iris
precisión, especialmente para ciertos colores de iris.
Dado que la biometría solo se permite como un segundo factor para la autenticación multifactor, las consideraciones de usabilidad para
eventos intermitentes con el factor principal aún se aplican. Los eventos intermitentes con uso de datos biométricos incluyen, entre otros, los
siguientes, que pueden afectar la precisión del reconocimiento:
• Si los usuarios se lesionan los dedos registrados, es posible que el reconocimiento de huellas digitales no funcione. La autenticación
de huellas dactilares será difícil para los usuarios con huellas dactilares degradadas.
• El tiempo transcurrido entre el momento del reconocimiento facial para la autenticación y el momento de la inscripción inicial puede
afectar la precisión del reconocimiento, ya que el rostro del usuario cambia naturalmente con el tiempo. El cambio de peso de un
usuario también puede ser un factor.
• Es posible que el reconocimiento de iris no funcione para las personas que se sometieron a una cirugía ocular, a menos que
se vuelvan a inscribir. En todas las modalidades biométricas, las consideraciones de usabilidad para eventos intermitentes incluyen:
60
• Debe estar disponible y funcionando un método de autenticación alternativo. En los casos en que la biometría no funcione, permita
que los usuarios utilicen un secreto memorizado como un segundo factor alternativo.
• Provisiones para asistencia técnica:

o Comunique claramente la información sobre cómo y dónde adquirir
asistencia. Por ejemplo, proporcione a los usuarios información como un enlace a una función de autoservicio en línea y
un número de teléfono para el soporte de la mesa de ayuda. Idealmente, proporcione información suficiente para permitir
a los usuarios recuperarse de eventos intermitentes por sí mismos sin intervención externa.
o Informar a los usuarios de los factores que pueden afectar la sensibilidad del sensor biométrico (p. Ej.,
limpieza del sensor).
61
11 referencias
Referencias generales
[GLOBO] Boneh, Dan, Corrigan-Gibbs, Henry y Stuart Schechter. "Hashing de globos: una función de memoria que
proporciona una protección comprobable contra ataques secuenciales", Asiacrypt
2016, Octubre de 2016. Disponible en: https://eprint.iacr.org/2016/027 .
[Listas negras] Habib, Hana, Jessica Colnago, William Melicher, Blase Ur, Sean Segreti, Lujo Bauer, Nicolas Christin y
Lorrie Cranor. "Creación de contraseñas en presencia de listas negras"
2017. Disponible en: https://www.ndss-symposium.org/wp- content / uploads /

2017/09 / usec2017_01_3_Habib_paper.pdf .
[Composición] Komanduri, Saranga, Richard Shay, Patrick Gage Kelley, Michelle L Mazurek, Lujo Bauer, Nicolas Christin,
Lorrie Faith Cranor y Serge Egelman. "De contraseñas y personas: medición del efecto de las políticas de composición de
contraseñas". En Actas de la Conferencia SIGCHI sobre factores humanos en sistemas informáticos, 2595-2604. ACM,
2011. Disponible en: https://www.ece.cmu.edu/~lbauer/papers/2011/chi2011-passwords.pdf .
[E-Gov] Ley de gobierno electrónico [ incluye FISMA] (PL 107-347), diciembre de 2002, disponible en: http://www.gpo.gov/fdsys/pkg/PLAW-107pub
.
[EO 13681] Orden ejecutiva 13681, Mejorar la seguridad de las transacciones financieras del consumidor, 17 de octubre de
2014, disponible en: https://www.federalregister.gov/d/2014-25439 .
[FEDRAMP] Administración de servicios generales, Programa Federal de Gestión de Autorizaciones y Riesgos, disponible en:
https://www.fedramp.gov/ .
[ICAM] Grupo de enfoque del Subcomité de sistemas de seguridad nacional y gestión de identidades, credenciales y
acceso, Consejo federal de CIO, Léxico ICAM, Versión 0.5, marzo de 2011.
[M-03-22] Memorando OMB M-03-22, Guía de la OMB para implementar las disposiciones de privacidad de la Ley de
gobierno electrónico de 2002, 26 de septiembre de 2003, disponible en: https://georgewbush-whitehouse.archives.gov/omb/memoranda/m03-22.html
.
[M-04-04] Memorando OMB M-04-04, Guía de autenticación electrónica para agencias federales,
16 de diciembre de 2003, disponible en: https: // georgewbush-
whitehouse.archives.gov/omb/memoranda/fy04/m04-04.pdf .
[Metros] de Carné de Carnavalet, Xavier y Mohammad Mannan. "De muy débil a muy fuerte: análisis de los medidores
de fuerza de la contraseña". En Actas del Simposio de seguridad de redes y sistemas distribuidos (NDSS), 2014.
Disponible
a: http://www.internetsociety.org/sites/default/files/06_3_1.pdf .
62
[NISTIR8062] Informe interno 8062 del NIST, Introducción a la ingeniería de privacidad y la gestión de riesgos en sistemas
federales, Enero de 2017, disponible en:
http://nvlpubs.nist.gov/nistpubs/ir/2017/NIST.IR.8062.pdf .
[NIST Usabilidad] Instituto Nacional y Estándares y Tecnología, Usabilidad y biometría, asegurando sistemas
biométricos exitosos, 11 de junio de 2008, disponible en: http://www.nist.gov/customcf/get_pdf.cfm?pub_id=152184 .
[OWASP-session] Proyecto de seguridad de aplicaciones web abiertas, Hoja de trucos para la gestión de sesiones,
disponible en: https://www.owasp.org/index.php/Session_Management_Cheat_Sheet .
[OWASP-XSS-prevención] Proyecto de seguridad de aplicaciones web abiertas, Hoja de trucos para la prevención de XSS (Cross Site
Scripting), disponible en: https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet .
[Persistencia] Herley, Cormac y Paul van Oorschot. “Una agenda de investigación que reconoce la persistencia de las
contraseñas”, Revista de seguridad y privacidad de IEEE, 2012. Disponible en: http://research.microsoft.com/apps/pubs/default.aspx?id=154077
.
[Acto privado] Ley de Privacidad de 1974 ( PL 93-579), diciembre de 1974, disponible en: https://www.justice.gov/opcl/privacy-act-1974
.
[Políticas] Weir, Matt, Sudhir Aggarwal, Michael Collins y Henry Stern. "Prueba de métricas para políticas de creación de
contraseñas atacando grandes conjuntos de contraseñas reveladas". En Actas de la 17ª Conferencia de la ACM sobre seguridad
informática y de comunicaciones, 162-175. CCS '10. Nueva York, NY, EE.UU .: ACM, 2010. doi: 10.1145 / 1866307.1866327.
[Sección 508] Ley de la Sección 508 y leyes y políticas relacionadas (30 de enero de 2017), disponible en: https://www.section508.gov/content/learn/law
.
[ Shannon ] Shannon, Claude E. "Una teoría matemática de la comunicación", Revista técnica de Bell System, v.27,
págs.379-423, 623-656, julio, octubre de 1948.
[Fuerza] Kelley, Patrick Gage, Saranga Komanduri, Michelle L Mazurek, Richard Shay, Timothy Vidas, Lujo Bauer, Nicolas
Christin, Lorrie Faith Cranor y Julio Lopez. "Adivina otra vez (y una y otra vez): medir la fuerza de la contraseña mediante la
simulación de algoritmos para descifrar contraseñas". En Seguridad y privacidad (SP), 2012 IEEE Symposium On,
523–537. IEEE, 2012. Disponible en: http://ieeexplore.ieee.org/iel5/6233637/6234400/06234434.pdf .
Estándares
[BCP 195] Sheffer, Y., Holz, R. y P. Saint-Andre, Recomendaciones para el uso seguro de la seguridad de la capa de transporte (TLS) y la
seguridad de la capa de transporte de datagramas (DTLS), BCP 195, RFC
7525, DOI 10.17487 / RFC7525, mayo de 2015, https://doi.org/10.17487/RFC7525 .
[ISO 9241-11] Organización internacional de normas, ISO / IEC 9241-11 Requisitos ergonómicos para el trabajo de oficina con
terminales de visualización visual (VDT) - Parte 11: Orientación sobre usabilidad, marzo
1998, disponible en: https://www.iso.org/standard/16883.html .
63
[ISO / IEC 2382-37] Organización de Normas Internacionales, Tecnología de la información - Vocabulario

- Parte 37: Biometría, 2017, disponible
a: http://standards.iso.org/ittf/PubliclyAvailableStandards/c066693_ISO_IEC_2382- 37_2017.zip .
[ISO / IEC 10646] Organización de Normas Internacionales, Juego de caracteres codificados universales, 2014, disponible
a: http://standards.iso.org/ittf/PubliclyAvailableStandards/c063182_ISO_IEC_10646_2014.zip .
[ISO / IEC 24745] Organización de Normas Internacionales, Tecnología de la información - Técnicas de seguridad - Protección
de la información biométrica, 2011, disponible en: http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=52946
.
[ISO / IEC 30107-1] Organización internacional de normas, Tecnología de la información - Detección de ataques de
presentación biométrica - Parte 1: Marco, 2016, disponible en: http://standards.iso.org/ittf/PubliclyAvailableStandards/c053227_ISO_IEC_30107-1_2
.
[ISO / IEC 30107-3] Organización internacional de normas, Tecnología de la información - Detección de ataques de presentación
biométrica - Parte 3: Pruebas e informes, 2017.
[RFC 20] Cerf, V., Formato ASCII para intercambio de red, STD 80, RFC 20, DOI
10.17487 / RFC0020, octubre de 1969, https://doi.org/10.17487/RFC0020 .
[RFC 5246] IETF, El protocolo de seguridad de la capa de transporte (TLS) versión 1.2, RFC 5246, DOI
10.17487 / RFC5246, agosto de 2008, https://doi.org/10.17487/RFC5246 .
[RFC 5280] IETF, Certificado de infraestructura de clave pública de Internet X.509 y perfil de CRL, RFC
5280, DOI 10.17487 / RFC5280, mayo de 2008, https://doi.org/10.17487/RFC5280 .
[RFC 6238] IETF, TOTP: Algoritmo de contraseña de un solo uso basado en el tiempo, RFC 6238, DOI
10.17487 / RFC6238, https://doi.org/10.17487/RFC6238 .
[RFC 6960] IETF, X.509 Protocolo de estado de certificado en línea de infraestructura de clave pública de Internet - OCSP, RFC 6960,
DOI 10.17487 / RFC6960, https://doi.org/10.17487/RFC6960 .
[UAX 15] Consorcio Unicode, Formularios de normalización Unicode, Anexo 15 del estándar Unicode, versión 9.0.0, febrero
de 2016, disponible en: http://www.unicode.org/reports/tr15/ .
Publicaciones especiales del NIST
Las publicaciones especiales de la serie NIST 800 están disponibles en: http://csrc.nist.gov/publications/PubsSPs.html . Las siguientes
publicaciones pueden ser de particular interés para quienes implementan sistemas de aplicaciones que requieren autenticación digital.
[SP 800-38B] Publicación especial NIST 800-38B, Recomendación para los modos de operación de cifrado en bloque: el modo
CMAC para autenticación, octubre
2016, https://doi.org/10.6028/NIST.SP.800-38B .
64
[SP 800-52] Publicación especial del NIST 800-52 Revisión 1, Directrices para la selección, configuración y uso de
implementaciones de seguridad de la capa de transporte (TLS), abril
2014, https://doi.org/10.6028/NIST.SP.800-52r1 .
[SP 800-53] Publicación especial del NIST 800-53 Revisión 4, Controles de seguridad y privacidad recomendados para organizaciones y
sistemas de información federales, Abril de 2013 (actualizado el 22 de enero de
2015), https://doi.org/10.6028/NIST.SP.800-53r4 .
[SP 800-57 Parte 1] Publicación especial del NIST 800-57 Parte 1, Revisión 4, Recomendación para la gestión de claves, Parte
1: General, Enero de 2016, https://doi.org/10.6028/NIST.SP.800-57pt1r4 .
[SP 800-63-3] Publicación especial del NIST 800-63-3, Directrices de identidad digital, junio
2017, https://doi.org/10.6028/NIST.SP.800-63-3 .
[SP 800-63A] Publicación especial NIST 800-63A, Pautas de identidad digital: requisitos de inscripción y prueba de
identidad, Junio de 2017, https://doi.org/10.6028/NIST.SP.800-63a .
[SP 800-63C] Publicación especial NIST 800-63C, Directrices de identidad digital: Federación y afirmaciones, Junio de 2017,
https://doi.org/10.6028/NIST.SP.800-63c .
[SP 800-90Ar1] Publicación especial del NIST 800-90A Revisión 1, Recomendación para la generación de números aleatorios
utilizando generadores de bits aleatorios deterministas, junio
2015, https://doi.org/10.6028/NIST.SP.800-90Ar1 .
[SP 800-107] Publicación especial del NIST 800-107 Revisión 1, Recomendación para aplicaciones que utilizan algoritmos
hash aprobados, Agosto 2012, https://doi.org/10.6028/NIST.SP.800-107r1 .
[SP 800-131A] Publicación especial del NIST 800-131A Revisión 1, Transiciones: recomendación para la transición del uso
de algoritmos criptográficos y longitudes de clave, noviembre
2015, https://doi.org/10.6028/NIST.SP.800-131Ar1 .
[SP 800-132] Publicación especial NIST 800-132, Recomendación para la derivación de claves basada en contraseña, Diciembre
de 2010, https://doi.org/10.6028/NIST.SP.800-132 .
[SP 800-185] Publicación especial NIST 800-185, Funciones derivadas de SHA-3: cSHAKE, KMAC, TupleHash y
ParallelHash, Diciembre de 2016, https://doi.org/10.6028/NIST.SP.800-185 .
Estándares federales de procesamiento de información
[FIPS 140-2] Publicación del estándar federal de procesamiento de información 140-2, Requisitos de seguridad para módulos criptográficos, 25
de mayo de 2001 (con avisos de cambio hasta el 3 de diciembre de
2002), https://doi.org/10.6028/NIST.FIPS.140-2 .
[FIPS 198-1] Publicación del estándar federal de procesamiento de información 198-1, El código de autenticación de mensajes hash
con clave (HMAC), Julio de 2008, https://doi.org/10.6028/NIST.FIPS.198-1 .
sesenta y cinco
[FIPS 201] Publicación del estándar federal de procesamiento de información 201-2, Verificación de identidad personal (PIV)
de empleados y contratistas federales, agosto
2013, https://doi.org/10.6028/NIST.FIPS.201-2 .
[FIPS 202] Publicación 202 del estándar federal de procesamiento de información, Estándar SHA-3: Hash basado en
permutación y funciones de salida extensible, agosto
2015, https://doi.org/10.6028/NIST.FIPS.202 .
66
Apéndice A: Fortaleza de los secretos memorizados
Este apéndice es informativo.
En este apéndice, la palabra "contraseña" se utiliza para facilitar la discusión. Cuando se utilice, debe interpretarse que
incluye frases de contraseña y PIN, así como contraseñas.
A.1 Introducción
A pesar de la frustración generalizada con el uso de contraseñas tanto desde el punto de vista de usabilidad como de seguridad, siguen siendo
una forma de autenticación muy utilizada [ Persistencia ]. Sin embargo, los seres humanos solo tienen una capacidad limitada para memorizar
secretos complejos y arbitrarios, por lo que a menudo eligen contraseñas que pueden adivinarse fácilmente. Para abordar las preocupaciones de
seguridad resultantes, los servicios en línea han introducido reglas en un esfuerzo por aumentar la complejidad de estos secretos memorizados.
La forma más notable de estas son las reglas de composición, que requieren que el usuario elija contraseñas construidas con una combinación de
tipos de caracteres, como al menos un dígito, una letra mayúscula y un símbolo. Sin embargo, los análisis de las bases de datos de contraseñas
violadas revelan que el beneficio de tales reglas no es tan significativo como se pensó inicialmente [ Políticas ], aunque el impacto en la usabilidad y
la memorabilidad es severo.
La complejidad de las contraseñas elegidas por el usuario se ha caracterizado a menudo utilizando el concepto de entropía de la teoría de la
información [ Shannon ]. Si bien la entropía se puede calcular fácilmente para los datos que tienen funciones de distribución deterministas, estimar
la entropía para las contraseñas elegidas por el usuario es difícil y los esfuerzos anteriores para hacerlo no han sido particularmente precisos. Por
esta razón, aquí se presenta un enfoque diferente y algo más simple, basado principalmente en la longitud de la contraseña.
Muchos ataques asociados con el uso de contraseñas no se ven afectados por la complejidad y longitud de las contraseñas. Los ataques de
registro de pulsaciones de teclas, phishing e ingeniería social son igualmente efectivos en contraseñas largas y complejas que en contraseñas
simples. Estos ataques están fuera del alcance de este Apéndice.
A.2 Longitud
Se ha descubierto que la longitud de la contraseña es un factor principal para caracterizar la seguridad de la contraseña [ Fuerza ] [ Composición
]. Las contraseñas que son demasiado cortas ceden a los ataques de fuerza bruta, así como a los ataques de diccionario que utilizan
palabras y contraseñas comúnmente elegidas.
La longitud mínima de la contraseña que debe requerirse depende en gran medida del modelo de amenaza que se esté abordando. Los ataques
en línea en los que el atacante intenta iniciar sesión adivinando la contraseña se pueden mitigar limitando la tasa de intentos de inicio de sesión
permitidos. Para evitar que un atacante (o un demandante persistente con habilidades de escritura deficientes) inflija fácilmente un ataque de
denegación de servicio al suscriptor al hacer muchas conjeturas incorrectas, las contraseñas deben ser lo suficientemente complejas como para
que la limitación de la tasa no se produzca después de una modesta número de intentos erróneos, pero ocurre antes de que haya una posibilidad
significativa de una suposición exitosa.
Los ataques fuera de línea a veces son posibles cuando el atacante obtiene una o más contraseñas hash a través de una violación de la base
de datos. La capacidad del atacante para determinar las contraseñas de uno o más usuarios depende de la forma en que se almacena la
contraseña. Comúnmente, las contraseñas son saladas
67
con un valor aleatorio y hash, preferiblemente usando un algoritmo computacionalmente costoso. Incluso con tales medidas, la capacidad
actual de los atacantes para calcular muchos miles de millones de hashes por segundo sin limitación de velocidad requiere que las
contraseñas destinadas a resistir tales ataques sean órdenes de magnitud más complejas que aquellas que se espera que resistan solo
ataques en línea.
Se debe alentar a los usuarios a que hagan sus contraseñas tan largas como deseen, dentro de lo razonable. Dado que el tamaño de una
contraseña con hash es independiente de su longitud, no hay razón para no permitir el uso de contraseñas largas (o frases de contraseña) si el
usuario lo desea. Las contraseñas extremadamente largas (quizás megabytes de longitud) posiblemente requieran un tiempo de procesamiento
excesivo para el hash, por lo que es razonable tener algún límite.
A.3 Complejidad
Como se señaló anteriormente, las reglas de composición se usan comúnmente en un intento de aumentar la dificultad de adivinar las
contraseñas elegidas por el usuario. La investigación ha demostrado, sin embargo, que los usuarios responden de formas muy predecibles a
los requisitos impuestos por las reglas de composición [ Políticas ]. Por ejemplo, es relativamente probable que un usuario que haya elegido
"contraseña" como contraseña elija "Contraseña1" si se le solicita que incluya una letra mayúscula y un número, o "¡Contraseña1!" si también
se requiere un símbolo.
Los usuarios también expresan su frustración cuando los servicios en línea rechazan los intentos de crear contraseñas complejas. Muchos
servicios rechazan las contraseñas con espacios y varios caracteres especiales. En algunos casos, los caracteres especiales que no se aceptan
pueden ser un esfuerzo para evitar ataques como la inyección SQL que dependen de esos caracteres. Pero una contraseña correctamente hash
no se enviaría intacta a una base de datos en ningún caso, por lo que tales precauciones son innecesarias. Los usuarios también deben poder
incluir espacios para permitir el uso de frases. Sin embargo, los espacios en sí mismos agregan poco a la complejidad de las contraseñas y
pueden presentar problemas de usabilidad (por ejemplo, el uso no detectado de dos espacios en lugar de uno), por lo que puede ser beneficioso
eliminar los espacios repetidos en las contraseñas escritas antes de la verificación.
Las opciones de contraseña de los usuarios son muy predecibles, por lo que es probable que los atacantes adivinen las contraseñas que han
tenido éxito en el pasado. Estos incluyen palabras de diccionario y contraseñas de violaciones anteriores, como "¡Contraseña1!" ejemplo
anterior. Por esta razón, se recomienda que las contraseñas elegidas por los usuarios se comparen con una “lista negra” de contraseñas
inaceptables. Esta lista debe incluir contraseñas de corporaciones de violaciones anteriores, palabras del diccionario y palabras específicas
(como el nombre del servicio en sí) que los usuarios probablemente elijan. Dado que la elección de las contraseñas por parte del usuario
también se regirá por un requisito de longitud mínima, este diccionario solo debe incluir entradas que cumplan con ese requisito.
Los secretos memorizados altamente complejos introducen una nueva vulnerabilidad potencial: es menos probable que sean
memorables y es más probable que se escriban o almacenen electrónicamente de manera insegura. Si bien estas prácticas no son
necesariamente vulnerables, estadísticamente algunos métodos para registrar tales secretos lo serán. Esta es una motivación adicional
para no requerir secretos memorizados excesivamente largos o complejos.
68
A.4 Secretos elegidos al azar
Otro factor que determina la fuerza de los secretos memorizados es el proceso mediante el cual se generan. Los secretos elegidos al
azar (en la mayoría de los casos por el verificador o el CSP) y distribuidos uniformemente serán más difíciles de adivinar o de un ataque
de fuerza bruta que los secretos elegidos por el usuario que cumplan con los mismos requisitos de longitud y complejidad. En
consecuencia, en LOA2, SP 800-63-2 permitió el uso de PIN generados aleatoriamente con 6 o más dígitos, al tiempo que requería que
los secretos memorizados elegidos por el usuario tuvieran un mínimo de 8 caracteres.
Como se mencionó anteriormente, el modelo de amenazas que se está abordando con requisitos de longitud secreta memorizados incluye
ataques en línea con velocidad limitada, pero no ataques fuera de línea. Con esta limitación, los PIN de 6 dígitos generados aleatoriamente
todavía se consideran adecuados para los secretos memorizados.
A.5 Resumen
Los requisitos de longitud y complejidad más allá de los recomendados aquí aumentan significativamente la dificultad de los secretos
memorizados y aumentan la frustración del usuario. Como resultado, los usuarios a menudo evitan estas restricciones de una manera
contraproducente. Además, otras mitigaciones como listas negras, almacenamiento seguro con hash y limitación de velocidad son más
efectivas para prevenir los ataques modernos de fuerza bruta. Por tanto, no se imponen requisitos de complejidad adicionales.
69

NIST SP 800-63b en Es PDF

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

NIST SP 800-63b en Es PDF

Загружено:

Авторское право:

Доступные форматы

Publicación especial NIST 800-63B

Directrices de identidad digital

Esta publicación está disponible de forma gratuita en:

Directrices de identidad digital

Paul A. Grassi Ray A. Perlner

James L. Fenton William E. Burr

Autores de privacidad: Autores de usabilidad:

Jamie M. Danker Mary F. Theofanos

Esta publicación está disponible de forma gratuita en:

Departamento de Comercio de EE. UU.

Instituto Nacional de Estándares y Tecnología

Publicación especial 800-63B del Instituto Nacional de Estándares y Tecnología

Esta publicación está disponible de forma gratuita en:

Los comentarios sobre esta publicación pueden enviarse a:

Instituto Nacional de Estándares y Tecnología

Informes sobre tecnología de sistemas informáticos

Requisitos de notación y convenciones

1 Propósito................................................. .................................................. ................ 1

2 Introducción ................................................. .................................................. ......... 2

3 Definiciones y abreviaturas ............................................... ............................... 4

4 Niveles de garantía del autenticador ............................................... ........................... 5

Nivel de garantía del autenticador 1 .............................................. ...................... 5

4.1.1 Tipos de autenticadores permitidos ............................................ ................. 5

4.1.2 Requisitos de autenticador y verificador ........................................... ... 6

4.1.3 Reautenticación .............................................. ..................................... 6

4.1.4 Controles de seguridad ............................................. ..................................... 6

4.1.5 Política de retención de registros ............................................ ......................... 6

Nivel de garantía del autenticador 2 .............................................. ...................... 6

4.2.1 Tipos de autenticadores permitidos ............................................ ................. 7

4.2.2 Requisitos de autenticador y verificador ........................................... ... 7

4.2.3 Reautenticación .............................................. ..................................... 8

4.2.4 Controles de seguridad ............................................. ..................................... 8

4.2.5 Política de retención de registros ............................................ ......................... 8

Nivel de garantía del autenticador 3 .............................................. ...................... 8

4.3.1 Tipos de autenticadores permitidos ............................................ ................. 9

4.3.2 Requisitos de autenticador y verificador ........................................... ... 9

4.3.3 Reautenticación .............................................. ................................... 10

4.3.4 Controles de seguridad ............................................. ................................... 10

4.3.5 Política de retención de registros ............................................ ....................... 10

Requisitos de privacidad ................................................ ................................... 10

Resumen de requisitos ............................................... ............................ 11

5 Requisitos de autenticador y verificador .............................................. ............ 13

Requisitos por tipo de autenticador .............................................. .............. 13

5.1.1 Secretos memorizados ............................................. ................................ 13

5.1.2 Buscar secretos ........................................... ...................................... 15

5.1.3 Dispositivos fuera de banda ......................................... ................................. dieciséis

5.1.4 Dispositivo OTP de factor único .......................................... ........................ 19

5.1.5 Dispositivos OTP multifactor .......................................... ........................ 20

5.1.6 Software criptográfico de factor único .......................................... ...... 22

5.1.7 Dispositivos criptográficos de factor único .......................................... ....... 22

5.1.8 Software criptográfico multifactor .......................................... ........ 23

5.1.9 Dispositivos criptográficos multifactor .......................................... .......... 24

Requisitos generales del autenticador ............................................... ............. 25

5.2.1 Autenticadores físicos ............................................. ......................... 25

5.2.2 Limitación de velocidad (estrangulamiento) .......................................... .......................... 25

5.2.3 Uso de datos biométricos ............................................ ................................... 26

5.2.4 Atestación .............................................. ............................................ 28

5.2.5 Resistencia a la suplantación de identidad del verificador ............................................ .......... 28

5.2.6 Comunicaciones Verificador-CSP ........................................... ................. 29

5.2.7 Resistencia al compromiso del verificador ........................................... ............. 29

5.2.8 Resistencia a la repetición ............................................. ................................. 30

5.2.9 Intención de autenticación ............................................. .............................. 30