SRP es para situaciones en las que ya tiene un secreto compartido entre el cliente y el servidor, por ejemplo. como parte de un procedimiento de "emparejamiento" que ocurriría naturalmente en su contexto (por ejemplo, SRP se ha propuesto para periféricos Bluetooth: un dispositivo tiene una pantalla y muestra un código, el otro tiene un teclado en el que se ingresa el código) . Para una situación "completamente en línea" en la que nunca hay ocasión de obtener un secreto compartido, SRP tiene pocas ventajas. La seguridad tiene que comenzar en alguna parte.
En SRP, lo que el servidor almacena es, de hecho, una especie de hash de la contraseña, solo "sort-of" porque el valor almacenado también debe cumplir con alguna estructura matemática para que pueda usarse en el protocolo. Ese valor no se puede utilizar inmediatamente para autenticarse como cliente, pero, al igual que con cualquier contraseña con hash, es de hecho susceptible a la fuerza bruta. La magia de SRP es que la observación de paquetes de datos en el cable no es suficiente para aplicar un ataque de diccionario a la contraseña; sin embargo, lo que el servidor almacena permite tal ataque (y, de manera muy general, esto es inevitable).
En TLS / SRP como se especifica actualmente, el valor almacenado en el servidor se calcula como:
x = SHA1(s | SHA1(I | ":" | P))
v = g^x % N
donde s es la sal, I el nombre de usuario, P la contraseña y v es el que está almacenado ( x no está almacenado). g y N son parámetros SRP (públicos). Si el atacante puede obtener el valor v , entonces puede "probar las contraseñas" haciendo el cálculo anterior.
Este es un hash salado (eso es bueno), pero también es un hash bastante rápido (eso es malo). SRP se podría combinar con una buena función hashing de contraseña (por ejemplo, bcrypt), con las siguientes advertencias:
- No hay un estándar especificado o de facto para eso. Pero tanto el cliente como el servidor deben estar de acuerdo en lo particular.
- Si se utiliza el hashing lento, entonces, cuando se realiza una conexión, debe ocurrir en el cliente, no en el servidor. Así que esto se ejecutará a la velocidad del cliente.