¿Cuándo debo emitir más de un dispositivo multifactor a un usuario? ¿Está bien dar varios tokens activos vs ninguno en absoluto?

Tengo varios dispositivos de autenticación multifactoriales vinculados a mi cuenta de PayPal. También tengo dos dispositivos de autenticación multifactoriales diferentes que aseguran el inicio de sesión de stackexchange. Definitivamente es posible hacerlo.

Existen múltiples requisitos para hacerlo. Una es la conveniencia simple (me autentico con el dispositivo más cercano a mí en ese momento). Podría surgir un requisito más formal porque se emiten diferentes tokens en diferentes niveles de Aseguramiento (LoA): tengo múltiples credenciales en diferentes niveles de aseguramiento. Puede ser conveniente para mí iniciar sesión con una credencial de seguridad baja, pero si quiero tomar una acción que requiere una seguridad más alta, es posible que deba volver a autenticarme con una credencial diferente.

@Lucas Kauffman es completamente correcto; NO quiero que mis administradores inicien sesión con la misma credencial cuando navegan por Internet que cuando están parchando mis servidores.

Esta respuesta podría continuar fácilmente a la longitud del libro y estar fuera del alcance de SEC: SE. La Estrategia Nacional para Identidades de Confianza en el Ciberespacio (NSTIC) se puede ver como una respuesta a la pregunta.

Si su usuario es un usuario de prueba y necesita, por ejemplo, acceso a una cuenta con admin, una cuenta normal y una cuenta especial (no lo hace una cuenta de administrador sino también más privilegios de lo normal). Entonces podría necesitarse más de una ficha.

También veo que esto sucede en la práctica cuando una sola cuenta no puede realizar las acciones A y B. Si el usuario necesita acceder a las acciones A y B, es posible que deba emitir dos fichas. (Si hace esto, por favor asegúrese de mantener una buena separación de tareas). Sin embargo, esta es una solución para una limitación dentro de la aplicación.

La "sabiduría común" de que solo se necesita un dispositivo para una organización es una cuestión de costo: si un token cuesta $ 60 cada uno, y ya confía en él para asegurar su acceso más confidencial, puede reutilizarlo para proporcionar un acceso más bajo. El mismo token podría estar asociado con su cuenta de "administrador", su cuenta "regular" y su cuenta de "sistema de prueba" de bajo nivel. La responsabilidad recae en el usuario para utilizar la cuenta adecuada para la situación.

Es importante entender que el token está asociado con su identidad y no con su nivel de autoridad. Por sí mismo, el token no otorga la autoridad de administración. El token está asociado con usted y su cuenta, y es la membresía de su cuenta en el grupo de usuarios de administración que otorga la autoridad de administración.

Donde se necesitan múltiples tokens es cuando dos organizaciones diferentes otorgan acceso, y las dos organizaciones no se conocen, hablan o confían entre sí. Es posible que tenga un token emitido por un proveedor para acceder al sitio del proveedor, y si no tiene un acuerdo de inicio de sesión federado con ellos, puedo entender que se emita un segundo token. Pero hay pocas razones para hacer que sus usuarios carguen con alrededor de 8 tokens diferentes, y hay muchas razones para no: costo por token y confusión del usuario (¿cuál de estos tres tokens idénticos utilizo para la cuenta de laboratorio?)

... para cada entorno

Dependiendo de los requisitos de seguridad de cada entorno, (test, dev, qa, prod) debe haber un token separado. Esto puede evitar problemas operativos cuando un script de prueba de QA "se filtra" en la producción y afecta el servicio.

... para cada función

Los tokens deben ser únicos según el riesgo para las operaciones que plantea: (Administrador de dominio, administrador de CA).

... tokens múltiples por inicio de sesión

Nunca he visto esto en producción, pero puedo imaginar un escenario en el que alguien se enfrenta a un nombre de usuario, una contraseña, una contraseña HTOP y una contraseña Yubikey.

..así es apropiado para la necesidad de seguridad

Creo que hay un punto medio entre no tener un dispositivo multifactorial en lugar de tener un solo token asignado. Específicamente, una vez que la Seguridad de TI impida la usabilidad del sistema, los usuarios encontrarán una forma de evitarlo. Aquí hay un usuario que usa una cámara de video para automatizar de forma remota su desafío de llavero RSA .

Si un usuario está usando esta técnica, o simplemente usa una cámara web apuntada a un token, entonces puede ser una buena idea averiguar por qué. Si se trata de reducir el aumento de la capacidad física del llavero, o porque pueden perderlo, entonces la emisión de múltiples tokens a ese usuario podría solucionar el problema. Por ejemplo; un YubiKey nano se puede conectar a una PC doméstica y de trabajo. Dado que el nano es difícil de quitar, también puede tener sentido tener un token USB portátil.

La seguridad está ligeramente más diluida que el modelo de una sola ficha por persona, pero está muy lejos de no tener ningún factor múltiple. En este caso, el área de ataque de la superficie se reduce para que se rechacen las sesiones aleatorias sin token.

Las desventajas de requerir más de dos factores de autenticación se hacen evidentes cuando responde la pregunta: "¿un usuario deberá proporcionar todos estos factores cada vez que acceda a su cuenta?".

Si la respuesta es sí, entonces si bien el sistema técnicamente sería más seguro (más información tendría que caer en las manos equivocadas para que el esquema de autenticación sea falsificado), también sería menos fácil de usar. . Si el usuario necesitaba ingresar su nombre, una contraseña secreta que crearon y memorizaron, el número de una tarjeta en su billetera y el número de una clave criptográfica en su llavero, entonces muchas cosas tienen que ir mal para que la cuenta de un usuario ser iniciado sesión por alguien que no sea esa persona. Sin embargo, solo una cosa tiene que salir mal para que el usuario legítimo quede bloqueado de su propia cuenta (olvide su contraseña, pierda su tarjeta, pierda sus llaves). También tienen que ingresar toda esta información para iniciar sesión, cada vez; No sé sobre usted, pero el usuario promedio lo consideraría una barrera de entrada extrema.

Si la respuesta es no, entonces el sistema se vuelve menos seguro; si el usuario pudiera usar su número de tarjeta con el código de clave criptográfica o , aún podría ingresar si le robaron su billetera, pero ahora el atacante tiene una opción; puede robar la cartera del usuario o su llavero para obtener un dispositivo que proporcione la autenticación necesaria, además de la contraseña que se adquirió con un keylogger. Puede elegir el objetivo más fácil, lo que hace que la opción sea una reducción en el nivel total de seguridad.

Creo que debería ser posible para cada usuario obtener varias claves, si se pierde o se la roban (o en el caso de los tokens que tienen su propia batería, si la batería se agota), siempre debe tener un token de respaldo. para que pueda ingresar (y deshabilitar el otro token, por ejemplo)

esa es también la razón por la que Google, Github y Dropbox permiten múltiples dispositivos U2F.