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.