¿Seguridad computacional liviana liviana?

1

He leído un montón sobre cómo se debe usar bcrypt o PBKDF2 como un buen punto intermedio entre la carga de trabajo optimizable y el tiempo aceptable para hacer inviables los ataques de fuerza bruta y colisión.

¿Qué sucede si el sistema no es un sistema informático de uso común, estándar, de uso general?

Trabajo con un sistema integrado, que se ejecuta en una CPU de 200MHZ ARM y más del 90% del tiempo de la CPU se dedica a realizar el trabajo real que está realizando el sistema, continuamente. Todo lo demás es secundario, lento y conservador en términos de memoria, tiempo de CPU y demás.

Actualmente, el acceso al control remoto está protegido por una respuesta de desafío bruta basada en md5; el dispositivo genera una cadena aleatoria y la envía al cliente, el cliente envía md5 (contraseña + cadena). Esto es para detener a los chiquillos y a los aficionados demasiado curiosos, pero soy consciente de que esta seguridad es bastante patética.

Con mucho gusto agregaría algo mejor, excepto que realmente no puedo ahorrar mucho RAM, tiempo de CPU o incluso espacio en disco para soluciones sofisticadas y prefiero un cliente válido para poder ingresar dentro de un tiempo razonable. Además, se utilizará el mismo protocolo para autenticar estos dispositivos que se comunican entre sí, por lo que las restricciones deben aplicarse a todos los sistemas de autentificación.

¿Cómo resolver razonablemente esto? ¿Alguno de los algoritmos y métodos que permitirían una seguridad razonable, asumiendo la restricción de que no debe imponer una penalización de rendimiento de más del 1%?

    
pregunta SF. 21.12.2012 - 12:36
fuente

1 respuesta

2

La protección de las contraseñas en el almacenamiento y el tránsito son dos problemas separados. La razón principal para usar PBKDF2 o bcrypt es que su resistencia al hash cracking es alta, en los casos en que los hashes se capturan desde el servidor (por ejemplo, a través de un volcado de base de datos a través de SQLi).

Ya que estás buscando proteger contraseñas en tránsito, creo que ya hayas caído en una trampa inesperada. Si un usuario legítimo envía una solicitud con una respuesta correcta al desafío, ¿qué impide que el atacante realice un ataque de intermediario y modifique el contenido de la solicitud, mientras mantiene el token de respuesta válido?

Entonces, primero debes definir lo que necesitas:

  • Confidencialidad de la contraseña.
  • Integridad del mensaje.
  • Autenticación del cliente (con la contraseña y el mensaje).

Un sistema de desafío-respuesta por sí solo no puede hacer esto, a menos que integres un MAC (código de autenticación de mensaje) en él. De hecho, lo que técnicamente necesita es un MAIC (autenticación de mensaje y código de integridad), ya que debe asegurarse de que el mensaje exacto que recibió es el que envió el usuario, que no fue manipulado, y que el usuario es quien dice ser.

Ahora se está ejecutando en áreas donde hay errores que cometer y donde fallan los errores de implementación. Escribir un protocolo que proporcione efectivamente la autenticación, la confidencialidad y la integridad es difícil, especialmente en un sistema integrado que usa lenguajes de bajo nivel. Sin embargo, TLS (SSL) hace exactamente esto. Al contrario de lo que algunas personas dicen, TLS es increíblemente eficiente en términos de uso de memoria y CPU. Lo he visto implementado en microcontroladores Atmega de 40MHz con muy pocos problemas.

En conclusión, recomiendo encarecidamente encontrar una biblioteca SSL (¿libssl quizás?) que compile en ARM, y luego la use.

    
respondido por el Polynomial 21.12.2012 - 12:54
fuente

Lea otras preguntas en las etiquetas