Yubikey con KeePass usando desafío-respuesta vs OATH-HOTP

dependiendo de cómo el complemento lo haga internamente, esta puede ser una forma interesante de agregar seguridad.

Básicamente, esta cosa hace un mal uso de HOTP en gran medida, al calcular las siguientes OTP, sin embargo, muchas OTP necesarias y las forma junto con el pase maestro para cifrar la base de datos.

pero, por supuesto, cuando tiene una búsqueda anticipada activa (y debería hacerlo, especialmente en un nano), genera algunas secuencias de teclas más en caso de que incremente el contador accidentalmente.

La idea detrás de esto no es mala, aunque, obviamente, keepass necesita almacenar la semilla (secreto compartido) en la base de datos para permitir volver a cifrarla.

el complemento keechallenge funciona bajo la misma premisa: mezclar un secreto compartido con algún tipo de desafío (el contador en HOTP), pero este complemento es en realidad más seguro desde unos pocos puntos de vista.

1) proporciona una salida de 160 bits de HMAC-SHA1 en lugar de "solo" de bits de log2 (10 ^ (6 * x)) (x es el número de OTP consecutivas que selecciona, 8 OTP consecutivas que obtendría solo a 159 y medio bits de longitud)

Simplemente diga que debe tocar MUCHO menos para el mismo nivel de seguridad, y mientras que el complemento OTP probablemente podría configurarse para usar una tonelada de OTP para una seguridad aún mayor, con modificaciones, el complemento Challenge-Response también podría tener varios desafíos arrojar el número de bits a través del techo, con solo un octavo de los toques necesarios (y no hay que preocuparse por los errores de tapping y no obtener la secuencia correcta).

2) a medida que el desafío se proporciona desde la base de datos, no debemos preocuparnos por tocar la clave o el lookaheads accidentalmente, lo que significa que no necesitamos disminuir la seguridad al permitir que ingresen múltiples soluciones de segundo factor.

Dicho simplemente el número 2 significa que Yubi solo tiene el Secreto y la DB tiene lo que podría llamarse el "estado" del desafío, mientras que en TOTP, Yubi tiene el estado y el secreto necesarios para descifrar la DB y el los cambios de estado cada vez que toca la tecla, lo que significa que debería tener en cuenta varios estados.

aunque, obviamente, el secreto compartido aún debe almacenarse de una forma u otra dentro de la base de datos (a menos que no cambie el desafío en absoluto, pero eso es imprudente).

Debe tener en cuenta que cualquier mecanismo para implementar 2factor con KeePass no está agregando fundamentalmente ninguna verdadera seguridad. Cualquier atacante que obtenga una retención de su base de datos simplemente no instalará el complemento OTPKeyProv, y no se le pedirá que use el segundo factor.

OTP 2-factor proporciona autenticación, no cifrado, y solo funciona en situaciones en las que el atacante no tiene acceso directo a la bóveda de contraseñas antes de la autenticación, como en los servicios en línea como LastPass. Con KeepPass, el atacante debe tener acceso a la base de datos durante la autenticación, y como tal, simplemente puede descargar la base de datos e ignorar la pieza de autenticación.

Más simplemente: el uso de OtpKeyProv no agrega ninguna seguridad a su clave maestra y es principalmente un teatro de seguridad.

EDITAR: Estoy corregido en algunos frentes: en función de las respuestas del autor del complemento, el complemento está diseñado para agregar una clave secreta adicional a la contraseña maestra y protegerla mediante HOTP. Precisamente no está claro cómo se hace eso, pero suena plausible. Sin embargo, debe tenerse en cuenta que esto no es cierto factor 2, y es más como un factor y medio; el factor principal (clave de encriptación) se está fortaleciendo con una clave más débil que se encuentra débilmente protegida. Entonces, es seguridad adicional, pero no tanto como las verdaderas ofertas de 2 factores en los sistemas de autenticación.