Inútil 2FA en caso de atacante interno

Question

Inútil 2FA en caso de atacante interno

#1 de HopelessN00b (3 votos)
#2 de TTT (2 votos)

3

Supongamos un escenario de firma del lado del servidor, donde las claves de usuario se generan en un HSM y se exportan a una base de datos, cifradas con una clave simétrica derivada de una contraseña de usuario y la clave maestra de HSM.

Para firmar, los usuarios deben proporcionar la contraseña referida y un factor adicional, como una OTP, por ejemplo. La OTP no se puede usar para proteger la clave porque es un valor dinámico, por lo que solo se usa como barrera de autorización. La transmisión de los dos factores se realiza a través de SSL.

Ahora imagine que un atacante interno malintencionado cambia el código de la aplicación, para que las contraseñas que envían los usuarios se registren en un archivo.

Aunque la operación de firma a través de la aplicación requiere 2 factores, que previenen de algún modo los ataques de atacantes externos, qué se puede hacer para evitar que un atacante interno acceda directamente al HSM y descifre una clave de firma con la contraseña y la utilice para firmar documentos. en nombre del usuario?

Por lo general, el acceso físico a los HSM está protegido por un control doble, pero los usuarios pueden tener acceso lógico a HSM si tienen la contraseña para iniciar sesión de forma remota.

¿Qué tipo de medidas de seguridad puedo implementar para evitar este tipo de ataque interno?

authentication digital-signature hsm

pregunta wolvz 13.06.2016 - 18:37

fuente

2 respuestas

2

Quizás estás pensando demasiado en esto. Cuando dices:

Ahora imagine que un atacante interno malicioso cambia el código de la aplicación ...

A continuación, intenta adivinar a qué se cambiará el código de la aplicación y estás tratando de encontrar una solución para ese cambio en particular. El problema es que, si pueden cambiar el código en primer lugar, también pueden cambiarlo para hacer muchas otras cosas, la mayoría de las cuales no puede predecir. Entonces, incluso si protege contra un cambio, es probable que no lo haga contra un cambio diferente.

Las medidas de seguridad que toma para protegerse contra un ataque interno son, en primer lugar, limitar quién tiene acceso para cambiar el código de la aplicación y establecer un sistema de notificación para que sepa de inmediato si se modificó y quién lo cambió.

respondido por el TTT 13.06.2016 - 20:43

fuente

Lea otras preguntas en las etiquetas authentication digital-signature hsm

requisitos de contraseña vs opciones de almacenamiento de contraseña ¿Por qué usar valores aleatorios al sobrescribir archivos?

score 3 · Accepted Answer

Auditoría y alerta es el enfoque general de las amenazas internas.

Si se asegura de que la actividad en los sistemas confidenciales se registre y controle en gran medida, aumentará dramáticamente la dificultad de subvertir esos sistemas. Por lo general, se registra y alerta en cualquier inicio de sesión y mantiene un registro de auditoría de todas las acciones tomadas en el sistema. Para proteger esos registros de manipulación, los envía a medios de una sola escritura u otro sistema al que los usuarios del sistema confidencial no tienen acceso.

Otro enfoque efectivo y relativamente barato del problema es el principio de los cuatro ojos (que requiere que dos personas supervisen una acción determinada).

Por último, si le preocupa la integridad de su código (u otros archivos), siempre puede utilizar la firma de código. Adjuntar una firma criptográfica a lo que sea que le preocupa que se modifique le daría un alto grado de certeza de que el código no se modifica sin autorización (asumiendo que, por supuesto, obtiene la PKI para la configuración del sistema de firma correctamente) .