Con el servidor debe almacenar un "verificador de contraseña" con una estructura especial; en el SRP 3 (el que se describe en RFC 2945 ), esto se describe de esta manera:
The host stores user passwords as triplets of the form
{ <username>, <password verifier>, <salt> }
Password entries are generated as follows:
<salt> = random()
x = SHA(<salt> | SHA(<username> | ":" | <raw password>))
<password verifier> = v = g^x % N
El protocolo no puede funcionar si el servidor no tiene v o salt porque el servidor debe enviar el salt al cliente (en los pasos iniciales del protocolo) y debe usar v no mucho tiempo después. Por lo tanto, independientemente de lo que el servidor realmente almacene , el servidor debe saber lo suficiente como para recuperar o volver a calcular salt y v en una fracción de segundo. Un atacante que obtenga una copia completa del servidor podrá hacer lo mismo y acceder a salt y v , lo que permite un ataque rápido de fuerza bruta en la contraseña (rápido debido al cálculo de v , dado el salt , username y una contraseña putativa, implica solo un par de SHA-1 y una exponenciación modular).
Entonces, la única esperanza es encontrar una forma para que los atacantes no obtengan una copia completa del servidor. Es decir, cifre simétricamente los datos almacenados, con una clave que luego almacenará "en otro lugar", y ore por lo mejor. Por ejemplo, la mayoría de las violaciones de la persuasión de "inyección SQL" permiten al atacante obtener una copia más o menos completa de los datos del servidor almacenados en la base de datos, pero no (de manera inmediata) permite leer archivos arbitrarios fuera de la base de datos. Si el servidor almacena la clave de cifrado simétrica en un archivo y la utiliza para cifrar los campos relevantes en la base de datos (es decir, los valores v ), los atacantes que solo obtengan un volcado de la base de datos serán derrotados. p>
Una variante es configurar un servidor interno adicional que almacene los valores salt y v . Su servidor principal hablaría con ese servidor secundario. Entonces, dependería de ese servidor secundario detectar intentos de bombeo exhaustivo de todos los valores, si los atacantes hubieran pirateado totalmente el servidor principal. Al menos, la separación física protegería los valores sensibles ( salt y v ) de inyecciones de SQL y violaciones similares.
Hay poco más que puedes hacer sin modificar el cliente.