A raíz de la piratería de Blizzard, ¿qué pasos puedo tomar para hacer que el craqueo fuera de línea de SRP sea más difícil?
Mi pregunta asume que su base de datos ya se ha ido y que usted implementó SRP más o menos correctamente.
Relacionado: ¿Qué tan seguro es el SRP que Blizzard utiliza para proteger las contraseñas?
En SRP, el servidor almacena un token derivado de contraseña, que puede usarse para adivinar la contraseña en un ataque de diccionario sin conexión (los atacantes intentan contraseñas potenciales hasta que se encuentra una coincidencia). Esto no es un defecto de SRP: el servidor necesariamente contiene algunos datos similares derivados de contraseñas, independientemente del protocolo de autenticación utilizado. La magia de SRP es que ningún otro lugar en el protocolo produce tales datos derivados de contraseñas (incluso si el atacante intenta hacerse pasar por el servidor). Pero si el servidor está comprometido (todos los secretos son conocidos por el atacante), entonces es posible un ataque de diccionario sin conexión.
El fortalecimiento de este token incluye las herramientas habituales, es decir, sales e iteraciones (consulte bcrypt ). En la práctica, esto significa que la salida de bcrypt se usa como "contraseña" en SRP.
Hay dos opciones. SRP calcula un hash de la contraseña del usuario, luego lo expone y almacena el resultado. Opción 1: puede reemplazar ese hash con un "hash lento": recomiendo PBKDF2. Opción 2: puede pre-hash la contraseña con PBKDF2, y luego usar el resultado como antes. Proporciono una propuesta detallada en mi respuesta a ¿Puedo usar una función de derivación de claves como función hash H en SRP? ; Por favor, vea mi respuesta allí para las matemáticas detalladas. Cualquiera de estas opciones resolverá su problema.
Relacionados:
Me sorprende que la gente no haya notado que puedes y debes cifrar el verificador en la base de datos. Normalmente, con las grandes empresas las bases de datos son infraestructuras segregadas. El régimen de copia de seguridad de los servidores de bases de datos también suele ser deliberadamente diferente de las copias de seguridad a nivel de host de los servidores de aplicaciones y la infraestructura web. Las copias de seguridad de la base de datos suelen estar fuera del sitio y en cinta con un largo período de retención. También suele haber diferentes especialistas y equipos que se ocupan de la infraestructura y las copias de seguridad de la base de datos. Cuando esto sucede, el cifrado del verificador es obviamente una protección adicional contra la pérdida de las cintas por parte de la empresa de mensajería que las traslada.
Si cifras el verificador, existe la pregunta de dónde guardas y haces una copia de seguridad de las claves de cifrado. Las grandes empresas como los bancos han tenido que resolver este problema por sus claves y contraseñas SSL junto con otra configuración de seguridad sensible. No los colocarán en las mismas cintas que las copias de seguridad de db. Por lo general, tendrían una red de seguridad segregada que puede administrar los hosts de primera línea y tener dos hosts (o dos cabezas NFS dedicadas) en dos centros de datos en esa red reflejada por unison / rsync para respaldar copias de las claves de cifrado y la configuración de seguridad .
Poniendo todo eso junto, debe tener una ubicación de configuración segura o compartir en los servidores de la aplicación que se excluye de las copias de seguridad a nivel de host. En esa ubicación, coloca una clave simétrica de solo lectura para el ID de usuario del servidor de la aplicación. La aplicación lo utiliza para cifrar / descifrar el verificador SRP de los usuarios, ya que se guarda / carga en la base de datos principal. Las claves que copia en los hosts segregados en cada centro de datos. Si pierdes absolutamente todo, entonces reconstruyes tu base de datos a partir de cintas externas y creas una nueva clave simétrica. Todos sus usos ya no podrán iniciar sesión, sino que simplemente usarán su lógica de restablecimiento de contraseña para establecer un nuevo verificador.
Lea otras preguntas en las etiquetas passwords hash cryptography key-exchange threat-mitigation