hash - comandos - ¿Cómo funcionan los dispositivos de token de hardware?
clusvcadm (2)
Recientemente, mi banco me envió este pequeño dispositivo que genera un código único que debe usarse al realizar transacciones en línea, todo lo que hace el dispositivo es generar este código único cuando presiono un botón blanco en particular y no parece que se conecte a un servidor remoto o nada de eso.
Investigué un poco y terminé en criptografía con algo que se llama la función Hash, pero aún no lo entiendo.
Mis preguntas
- ¿Cómo saben los servidores de mi banco que el código generado por este dispositivo es correcto?
- Como solo genera cinco dígitos aleatorios cada 30 segundos, ¿por qué el servidor no autentica un número aleatorio que también he decidido usar?
Antes de empezar:
Soy Ingeniero Eléctrico y Electrónico. y acaba de abrir un antiguo dispositivo de seguridad y se inspiró en él.
Tengo una respuesta que está relacionada con el tiempo transcurrido:
Cada uno de estos dispositivos de seguridad tiene un cristal de cuarzo en el interior y cada vez que se enciende, su ciclo de vida está comenzando (como todos los nacidos en el mundo) y ninguno de los dispositivos se inició exactamente a la misma hora (debido a que no se genera el mismo número exactamente al mismo) momento), por lo que cada vez que presiona el botón, genera un número único al calcular el tiempo transcurrido (probablemente en el orden de 1/1000000 de precisión debido a los 6 dígitos que se muestran en mi dispositivo con intervalos de 15 segundos) convertido a un número único. Pero, ¿cómo sabe el servidor bancario mi número único generado?
Respuesta al servidor bancario:
Probablemente el banco esté contando el tiempo transcurrido después de que lo actives; porque tiene que activar estos dispositivos de seguridad en el primer uso con un número único generado desde su propio dispositivo. Por lo tanto, en un cálculo de tiempo exacto, el servidor del banco sabe que el número de entrada debe ser xxx-xxx y cambiará mientras transcurra el tiempo.
Estoy seguro de que la batería del dispositivo proporciona energía al cristal de cuarzo dentro del ciclo de vida de la batería, incluso si nunca usa el dispositivo de seguridad. Si se retira la batería, falla el número de generación debido a que el cristal de cuarzo no está encendido y el tiempo no se puede contar en ese momento. Así que nunca podrá volver a generar los mismos números únicos.
Esto tiene muy poco que ver con las funciones hash. Una función hash criptográfica puede ser parte de la implementación, pero no es necesaria.
En realidad, genera los dígitos en un intervalo de tiempo, si presiono el botón para que genere los dígitos, genera los dígitos y después de unos 25 segundos, y lo presiono nuevamente, los dígitos no cambian cuando lo presiono nuevamente inmediatamente después de que acabo de presionarlo.
Ahí está tu pista. Es un algoritmo pseudoaleatorio o criptográfico basado en el tiempo. Basado en el tiempo, hay un código. El dongle y el servidor saben, o mejor dicho, pueden calcular, el código para cada ventana. Este es un secreto compartido : el dongle no se conecta a un servidor remoto. El servidor probablemente permitirá una o dos de las claves secretas más recientes, para evitar la situación en la que ingresa una clave que acaba de caducar mientras la transmisión estaba en camino.
(Aunque mi experiencia reciente con la autenticación multifactor del servicio web de Amazon definitivamente ha resultado en fallas de inicio de sesión dentro de los 5 segundos posteriores a la visualización de un código. En otras palabras, algunos proveedores son muy estrictos con sus ventanas de tiempo. Como siempre, es un intercambio -off entre seguridad y usabilidad.)
Las abreviaturas que mencionan CodesInChaos son la contraseña de un solo uso basada en el tiempo (TOTP) y la contraseña de un solo uso basada en HMAC (HOTP) , dos algoritmos que se utilizan comúnmente en la autenticación de dos factores.
Wikipedia tiene esto que decir acerca de RSA SecurID , una marca particular de dongle de two-factor-authentication de two-factor-authentication .
El mecanismo de autenticación RSA SecurID consiste en un "token", ya sea hardware (por ejemplo, un dispositivo USB) o software (un token suave), que se asigna a un usuario de computadora y que genera un código de autenticación a intervalos fijos (generalmente 60 segundos) usando un reloj incorporado y la clave aleatoria codificada de fábrica de la tarjeta (conocida como "semilla"). La semilla es diferente para cada token y se carga en el servidor RSA SecurID correspondiente (RSA Authentication Manager, anteriormente ACE / Server) a medida que se compran los tokens.
Elegí este artículo porque tiene una descripción física razonable; Los artículos de nivel superior se centran en lo teórico sobre la implementación física.
El artículo también confirma que debe guardar el secreto del token, o que otra persona puede hacerse pasar por sus inicios de sesión al saber cuáles son los códigos tan fácilmente como usted.
El hardware del token está diseñado para ser resistente a la manipulación indebida para impedir la ingeniería inversa. Cuando las implementaciones de software del mismo algoritmo ("tokens de software") aparecieron en el mercado, la comunidad de seguridad ha desarrollado un código público que le permite a un usuario emular RSA SecurID en el software, pero solo si tiene acceso a un código RSA SecurID actual. y el archivo semilla original RSA SecurID de 64 bits introducido en el servidor.
Sin embargo, dado que el servidor de verificación debe tener conocimiento previo de los tokens , los secretos de dos factores también son vulnerables a los ataques en la fuente. SecurID fue víctima de un robo de alto perfil que afectó a sus propios servidores y, finalmente, provocó incursiones secundarias en los servidores de sus clientes.
Finalmente, hay más información disponible en el sitio hermano de security.stackexchange bajo la etiqueta multifactor, y también en este sitio bajo la etiqueta de two-factor-authentication .