¿Se recomienda utilizar una solución recomendada para proteger el verificador SRP si se filtra la base de datos?

1

Estamos trabajando en un nuevo sitio web que nos gustaría usar el protocolo SRP. Así que el salt y el verificador se envían al servidor, y en teoría, el servidor los almacena así en una base de datos. Si se filtra el DB, el atacante seguramente podría forzar la contraseña de un usuario y verificar con el verificador / sal (incluso con un buen KDF como Argon2). Nos gustaría evitar esto, hay una solución recomendada, por favor?

Mi solución actual:

En el inicio del servicio REST, se ingresa manualmente una contraseña maestra, y luego se procesa con Argon2 varias veces (XOR el byte de cada contraseña para obtener el número, hasta 255). Este hash de contraseña maestra se utiliza para cifrar cualquier información confidencial con AES-GCM antes de almacenarlos en la base de datos (sal, verificador SRP).

Con este método, si se filtra la base de datos, incluso con el código fuente o el disco duro, el atacante no puede explotar el verificador SRP. El único ataque que tengo en mente, sería instalar un rootkit y volcar la memoria para encontrar la contraseña maestra.

    
pregunta lakano 29.10.2017 - 20:27
fuente

1 respuesta

1

Al igual que con las bases de datos de hashes de contraseña, el enfoque tradicional para evitar ataques basados en diccionarios es hacer que los hashes informáticos (o en este caso los verificadores) de las contraseñas sean lo suficientemente costosos.

En el caso de SRP, la forma obvia de hacerlo es elegir un grupo que sea lo suficientemente grande. (En cualquier caso, debe ser lo suficientemente grande como para resistir el criptoanálisis, como con RSA o DH).

Obviamente, aumentar el tamaño del grupo también ralentizará tanto a los clientes como a los servidores.

Otra posibilidad es reemplazar SHA-1 con otra función hash como se sugiere en la sección 3.2 de RFC 2945. La construcción SHA-1 con sal utilizada en SRP-SHA1 se puede reemplazar por otro resumen de mensaje, por HMAC o por un función de hashing de contraseña.

En mi opinión, usar una buena función de hashing de contraseñas como Argon2 o BCrypt o PBKDF2 en lugar de SHA-1 tiene sentido. Al hacer esto, aumenta el costo de los ataques de diccionario sin tener ningún impacto en el rendimiento del servidor. (Sin embargo, el rendimiento del cliente se ve afectado.) Por otro lado, esto no mejora la resistencia al análisis de cripto.

SRP está diseñado para proteger contraseñas en un modelo de amenaza que asume que un atacante puede obtener acceso a la memoria del servidor. Por lo tanto, SRP está diseñado para ser seguro en un contexto donde un atacante tendría acceso a su contraseña maestra.

Lo anterior también significa que SRP compite realmente con los administradores de contraseñas, siendo esta última una solución más ampliamente implementada. SRP es prácticamente inútil si sus usuarios ya usan administradores de contraseñas con una contraseña única para cada sitio.

Encriptar los verificadores almacenados es esencialmente lo mismo que "salpicar" una base de datos de contraseñas. Esto añade bastante complejidad. Que esto mejore la seguridad del sistema no es obvio.

Esto solo tiene sentido si asume que el atacante tiene acceso a la base de datos pero no al servidor (mientras que usar SRP solo tiene sentido si asume que el atacante tiene acceso al servidor), su contraseña maestra tiene una buena entropía y su cifrado el código está escrito correctamente (los IV se generan correctamente ...)

Con respecto a su uso de Argons2, debe corregir los parámetros: use la memoria y la capacidad de procesamiento que pueda. No haga que los parámetros dependan de la contraseña.

    
respondido por el Erwan Legrand 30.10.2017 - 13:21
fuente

Lea otras preguntas en las etiquetas