¿Es bueno almacenar contraseñas en una tabla / base de datos separada y administrarlas en un proceso separado?

6

Soy un novato en arquitectura de sistemas y seguridad, así que solo quiero comprobar que este plan tiene sentido. Estoy creando una aplicación web y necesito almacenar una contraseña para cada usuario. Ya he leído mucho sobre algoritmos de hash, sal, etc. Voy a usar Argon2 ya que parece ser la recomendación actual. Mi pregunta se refiere a cómo se almacenan y verifican los hashes en términos de la arquitectura general.

Como el hashing con Argon2 es intencionalmente bastante costoso, quiero crear un servicio en un módulo / proceso separado para que se pueda mover fácilmente a una o más máquinas separadas si es necesario. Incluso si viviera en la misma máquina que el servidor de aplicaciones principal, sería trivial monitorear el uso de la CPU y la memoria para ajustar los factores de costo del algoritmo de hash.

Mi aplicación enviará solicitudes POST de HTTPS al servicio para crear, actualizar, eliminar o verificar una contraseña. Todos los detalles estarán en el cuerpo de la solicitud, incluida la contraseña en texto sin formato. La conexión será encriptada. La respuesta será simplemente una indicación de éxito o fracaso.

El servicio manejará la lógica de las operaciones de la base de datos, las contraseñas de hash y la comparación de hashes para la igualdad. Las contraseñas vivirán en una base de datos separada de los usuarios, de modo que incluso si un atacante vuelca toda la base de datos de contraseñas, aún no conocen la contraseña de nadie y viceversa. Además, si alguna vez migro a una solución de almacenamiento diferente para mis otros datos, habrá menos migración ya que las contraseñas pueden permanecer como están.

¿Eso suena bien? ¿O de alguna manera abre más puntos débiles de los que no estoy enterado?

    
pregunta Alex Hall 25.03.2016 - 23:31
fuente

2 respuestas

4

Hashing es demasiado lento significa que necesitas usar un hash más rápido, no un segundo proceso. Intente ajustar los parámetros en Argon2 o muévase a bcrypt (que todavía es realmente seguro). Ajuste los parámetros para obtener el hash a un tiempo razonable (~ 0.2-0.4 segundos) y mantenga todo en un solo proceso.

Si lo desea, aún puede mantener las contraseñas en una segunda base de datos para reducir la pérdida de datos si le roban el contenido de su base de datos principal, pero no estoy seguro de que sea necesario. La sabiduría convencional dice que bcrypt es seguro incluso con el robo de todos los datos. Ahora eso no es una garantía, pero a menos que la NSA lo persiga, o esté almacenando algo lo suficientemente valioso para motivar a grandes porciones de la red de Bitcoin a que dejen de imitar y comenzar a descifrar sus contraseñas, me sentiría muy cómodo con un realizando bcrypt.

    
respondido por el Neil Smithline 26.03.2016 - 06:47
fuente
3

Si bien esta es una pregunta de seguridad, me gustaría informarle sobre otra consideración:

Consideraciones de rendimiento

Crear un servicio micro web para manejar la autenticación puede ser una buena idea en algunos casos, esto depende de los casos de uso.

Sin embargo, es posible que desee considerar que establecer muchas conexiones https (para muchas solicitudes) también tiene un costo. Podría ser útil en términos de minimización de carga (ya que eso parece ser una preocupación) para que los dos servicios establezcan un túnel de larga duración que sea usado por múltiples conexiones.

En cuanto a las consideraciones de seguridad

  • El servicio web real que enfrenta el usuario actuará como un cliente TLS en este szenario.

    Es extremadamente importante que el almacén de confianza funcione según lo previsto (por ejemplo, confiar solo en el certificado del servicio de contraseñas) y que la clave privada de los servicios de contraseñas y los servicios web permanezcan privados .

    Si no,

    • el servicio podría volverse vulnerable a los ataques MITM (especialmente cuando se ejecuta en diferentes máquinas)
    • los atacantes podrían interactuar directamente con el servicio de contraseñas, tal vez DOS con cargas muy grandes o ser capaz de usar ataques de temporización de canal lateral indirectos.
  • El servicio web y / o el servicio de contraseñas deben usar preferiblemente alguna estrategia para asegurarse de mitigar posibles ataques de tiempo y DOS.

También, por supuesto, el aumento de la escalabilidad, la separación de inquietudes y, especialmente, la segmentación de la red (que son buenas e importantes), tiene un precio: la implementación de la lógica puede ser más compleja y puede presentar problemas sutiles que no conoce. . Esto es especialmente cierto si no estás acostumbrado a eso.

Un ejemplo de mayor complejidad podría ser: en los cambios de correo electrónico, quién maneja el compromiso real después de que se verifique el nuevo correo electrónico y cómo, por ejemplo, ¿Quién es autoritario para cambiar los datos que están duplicados en las bases de datos? ¿Desea iniciar la red IO dentro de una transacción de base de datos?

En cuanto a la función de hash

Allí hay una pregunta aquí sobre las contraseñas de hashing de forma segura que tiene muy buena respuestas.

Tenga en cuenta que no es necesario que utilice funciones de hashing de investigación de vanguardia. Los otros (PBKDF2, bcrypt y scrypt) son tan buenos para este propósito y no tiene que esperar que se encuentre un problema grave en el corto plazo, ya que han tenido tiempo de ser revisados por expertos.

    
respondido por el Tobi Nary 26.03.2016 - 02:05
fuente

Lea otras preguntas en las etiquetas