¿Cómo almacenar temporalmente los datos de forma segura en un servidor de caché / relé?

Tener una arquitectura asíncrona, donde las solicitudes se ponen en cola en una ubicación central, y luego son procesadas por los clientes que viven dentro de un límite de confianza, es una mejora importante de la arquitectura de seguridad que requiere la entrada directa de un PIN de los clientes de Internet que esperan una sincronización. interacción.

Un PIN es inútil como credencial y solo debe considerarse como un detalle de implementación desde una perspectiva de seguridad. Las expectativas de interacción sincrónica pueden limitar los tipos de inteligencia empleados para clasificar una solicitud en particular como benigna o maliciosa. Empuje de los no confiables a los confiables presenta una superficie de ataque mucho más amplia que la de confiado o no confiado Y una arquitectura sincrónica en la que la comunicación puede ser transitoria puede hacer que sea más fácil perder información relevante para el análisis posterior. Entonces, cambiar todo eso ya es mejor.

Sin embargo, hay muchas cosas que se pueden hacer para mejorar la postura de seguridad de la interfaz orientada por humanos. Los agruparía en 3 categorías.

1. autenticación de usuario

   Dado que se requiere una autorización especial del personal para el uso de este sistema, a uno le encantaría ver una autenticación superior, por supuesto, en la maquinaria, pero tal vez aún más importante en la capacitación y el conocimiento de los propios usuarios.

   El mecanismo de compromiso más común y lucrativo, lejos, es el phishing. El mejor escenario posible es que estas personas autorizadas, a través de la capacitación y los ejercicios, puedan estar profundamente sintonizados con las amenazas de suplantación, y convertirse en defensores y agentes en el campo para descubrir y evitar estas amenazas.

   En términos de maquinaria de autenticación, los detalles habituales de http / tls se aplican como una línea de base, pero hay muchas opciones: 2FA, certificados de clientes, devoluciones de llamadas en vivo, credenciales de rotación, autenticación social, etc. Los detalles técnicos, en cierta medida, son menos importantes que el compromiso y la capacitación que se produce con las personas que los utilizarán.

2. custodia de datos

   Los comandos emitidos por usuarios autorizados deben almacenarse de forma segura y con integridad. Lo que entra en el almacenamiento duradero debe salir de la misma manera. Existen muchas opciones para garantizar la seguridad de los datos en reposo, la mayoría de los cuales se centran en el cifrado de datos confidenciales en reposo y la firma de transacciones individuales por parte de los usuarios que los emitieron. Al texto de la pregunta, no hay "temporal" cuando se trata de almacenamiento. Cualquier cosa duradera comprometida puede vivir en ese estado durante mucho tiempo.

3. inteligencia

   El sistema como se describe ha autorizado a los usuarios a emitir comandos a varios sistemas de control. Probablemente hay una amplia gama de comandos y una gran cantidad de actividades legítimas que pueden ser dirigidas por esos individuos.

   Considere construir modelos que admitan la clasificación de comandos emitidos por cualquier individuo. Secuencias de comandos, tiempo de emisión del comando, información de retroalimentación consultada, ubicación y horas del día: se puede utilizar una combinación de estos metadatos para desarrollar huellas dactilares de la actividad esperada de individuos autorizados. Las secuencias de solicitud que no coinciden con las huellas digitales se pueden marcar para su posterior revisión y confirmación.

   En relación con esto, los sistemas de control tienen sus propios puntos de vista sobre lo que constituye una actividad aceptable. Considere desarrollar modelos de amenaza y esquemas de clasificación para usos inaceptables de estos sistemas de control. La existencia de una cola completa y el historial de comandos para una planta completa brinda una oportunidad única para este análisis.

No es necesario que almacene el PIN en la base de datos del servidor web, solo necesita almacenar algo que le permita saber (con mucha confianza) que el usuario ingresó el PIN correcto. Suponiendo que el PIN sea lo suficientemente largo (un PIN de doce dígitos podría funcionar) podría hacer un caso clásico de sal + hash.

Sin embargo, la mayoría de los PIN son de 4 dígitos, por lo tanto, no son útiles como método de autenticación. En su lugar, puede usar un método de autenticación decente además del PIN (haciendo que el PIN sea solo un detalle de la autenticación).

Cien mil palabras para atk por perseguirme en el hecho de que un PIN de 4 dígitos es inútil como autenticación y lo fácil que es forzarlo. En serio, aprendí mucho escribiendo y reescribiendo esto.

Opción decente: agregar la autenticación adecuada

Agregue una autenticación de inicio de sesión y contraseña (frase de contraseña) para los usuarios en el servidor web. Esta autenticación solo puede permanecer en el servidor web.

Un usuario que esté dispuesto a interactuar con la interfaz (al menos con la parte en la que puede alterar los datos) debe iniciar sesión primero. Tenga en cuenta que si la configuración actual del servidor web ya realiza esto, puede reutilizarlo para este propósito.

Ahora que tiene una autenticación adecuada (la frase de contraseña), puede almacenar el PIN en la base de datos del servidor web en función de ella. Puede cifrar el PIN en una clave generada a partir de la frase de contraseña. Por ejemplo, utilizando PBKDF2. En otras palabras, en la primera solicitud de un usuario, el servidor web deberá comunicarse con el sistema de control y recuperar el PIN. Luego almacenará el PIN en la base de datos de la siguiente manera:

AES(pbkdf2(user_passphrase), PIN)

El usuario debe proporcionar su contraseña / contraseña para el servidor web y el PIN para realizar la solicitud.

En una solicitud siguiente, el usuario nuevamente debe proporcionar la frase de contraseña y el PIN. Pero el servidor web puede usar PBKDF2 en la frase de contraseña y usar la clave generada para descifrar el registro de la base de datos y comparar con el PIN proporcionado.

En resumen, agrega una mejor característica de seguridad (una frase de contraseña adecuada) además del PIN (bastante inseguro). Puede (y probablemente debería) permitir que el usuario cambie su frase de contraseña en el servidor web, pero luego necesita una forma de invalidar el PIN cifrado en caché en la base de datos.

Opción limitada: hash trivial + sal

Lo siguiente es cómo podría realizar esto utilizando un PIN suficientemente largo (por ejemplo, un PIN alfanumercial de unos 12-20 bytes de longitud sería suficiente contra los ataques de fuerza bruta actuales). Tenga en cuenta que la selección de la función hash es importante.

A solicitud del servidor web, el sistema de control, en lugar de enviar el PIN, puede crear una concatenación de sal en el PIN y utilizar un hash criptográfico para generar un valor. Por ejemplo, el sistema de control puede realizar algo como:

1. Recibe una solicitud del servidor para el usuario Bob;
2. Genera un salt aleatorio (por ejemplo, 012345667890abcdef );
3. Recupera el PIN de Bob (por ejemplo, abdd );
4. Realiza hash <- hash_function(abdd + 012345667890abcdef) ;
5. Devuelve hash y salt al servidor web.

El servidor web almacenará tanto el salt como el hash en la base de datos. En una solicitud de Bob al servidor web se enviará un PIN, llamémoslo reqPIN . El servidor puede realizar lo siguiente para verificar que el PIN es correcto:

1. Recupere los salt y hash para Bob de la base de datos;
2. Preforma reqHash <- hash_function(reqPIN + salt) ;
3. Compare reqHash con el hash de la base de datos.

Si los hashes son iguales, Bob ha ingresado el PIN correcto.

Si el servidor web está comprometido, puede iniciar otro y solicitar nuevas sales y hashes al cliente de control. No se puede utilizar nada en la base de datos del servidor web para recuperar el PIN (al menos en menos de una docena de años de extenso procesamiento de hash).

Notas:

• El hash_function puede ser cualquier hash criptográfico y le da una posibilidad de colisión muy pequeña, que es bastante seguro ignorar en la práctica
• Se necesitan funciones hash como bcrypt o scrypt (tal vez incluso argon2 ), estas funciones hash son costosas computacionalmente, lo que hace que un ataque de fuerza bruta sea mucho más difícil. También puede realizar el hashing varias veces, es decir, hash_function(hash_function(hash_function(...)))
• La sal es necesaria en caso de que dos personas tengan el mismo PIN y una de ellas sea el atacante. No puede decir que la otra persona tiene el mismo PIN que él mismo, incluso en posesión de todos los hashes. Necesitaría todos los hashes y todas las sales, y todavía tendría que volver a calcular todas las iteraciones de hash.