Aplicación web usando Identity Federation y OTP

Question

Aplicación web usando Identity Federation y OTP

#1 de Procrastinator (0 votos)
#2 de cornelinux (0 votos)

2

Estamos ejecutando una aplicación web utilizando la federación de identidad de un cliente para autenticar a los usuarios. Un nuevo requisito es usar 2FA, hemos decidido usar un algoritmo OTP usando Java, similar a este presentado en GitHub.

Según el algoritmo OTP, debemos proporcionar una clave secreta compartida para que cada usuario autentique el código OTP. En nuestro caso de uso, es una buena práctica válida almacenar una asignación entre la clave secreta y los usuarios relacionados en la base de datos de la aplicación para que luego podamos validar el código OTP.

Soy nuevo en 2FA, por lo que no estoy seguro de si el enfoque anterior está permitido o esto no está permitido en la federación de identidad web.

one-time-password multi-factor federation

pregunta K.Pil 04.04.2018 - 01:22

fuente

2 respuestas

Lea otras preguntas en las etiquetas one-time-password multi-factor federation

stdin no espera la siguiente entrada después de la cadena ROP Tunneling SSH sobre Shadowsocks

score 0 · Answer 1

Esto depende del proveedor de identidad (IdP) que está utilizando para este propósito.

Caso 1: IdP admite la validación de TOTP
Si su IdP admite la validación del TOTP, puede llamar directamente a la API y no necesita almacenar ninguna clave secreta en la base de datos de su aplicación.

Caso 2: IdP no admite 2FA
En este caso, deberá almacenar la clave secreta para cada usuario y validar el TOTP en su propia aplicación.

Ejemplo: en Shibboleth puede usar esto con la extensión Shibboleth-IdP3-TOTP-Auth , mientras que algunos IdP solo admiten la autenticación de 2 factores basada en SMS.
Básicamente, tiene que ir con la especificación de IdP, a menos que pueda elegir el IdP. Si tiene una opción, vaya a aquellas que admitan varios tipos de autenticación multifactor (TOTP, SMS, tokens de hardware, etc.)

score 0 · Answer 2

Sí, necesita almacenar una asignación entre el usuario y el material clave, que representa el segundo factor.

Esto también se recomienda en RFC4226.

Debes ocuparte de dos cosas:

Almacene el material clave de manera cifrada. Por supuesto, la clave de cifrado y el material de la clave pueden estar ubicados en el mismo servidor. Pero al menos esto lo protege contra inyecciones de SQL y quizás pérdidas de copias de seguridad de la base de datos ;-)
Debe implementar una asignación 1: n o tal vez incluso una asignación n: m. Un usuario podría tener más de un segundo factor. También un segundo factor podría ser utilizado por más de un usuario.

Habiendo dicho todo esto, ¡me pregunto si realmente desea implementar su propio sistema de gestión 2FA! ;-)

Hay muchas soluciones por ahí que están haciendo un gran trabajo. Probablemente solo tendría que mejorar su código de inicio de sesión y no preocuparse por registrar 2FA, almacenar claves cifradas y mapear ...

Eche un vistazo a privacyIDEA , que es un proyecto mío ( descargo de responsabilidad ). En este caso, si un usuario necesitara autenticarse con un segundo factor, se reduce a llamar a la API REST

POST https://yourserver/validate/check
user=fred
pass=128930

Hecho. Puede echar un vistazo a la documentación de la API REST .