Implementando SRP sin almacenar el salt en ningún lugar

Estoy intentando usar el SRP para verificar a los clientes cuando se autentican con un servidor web, para que la contraseña nunca se envíe por cable.

Mirando el procedimiento SRP , cuando un cliente se registra en el servidor que envía v ( verificador), s (salt) y I (el nombre de usuario o identificador) al servidor que almacena estos valores. Sin embargo, se afirma que:

[The salt] could be chosen by either side but is done by [the client] so
that [it] can register I, s and v in a single registration request.

Si el servidor o el cliente pueden elegir la sal, podemos asumir que el servidor la genera.

Cuando el cliente más adelante intenta autenticarse con el servidor, el cliente envía I y el servidor responde con s . Luego, el cliente utiliza s y otros datos para realizar la prueba de la contraseña.

Mi pregunta es, ¿por qué está s estático? ¿Por qué necesita almacenarse?

La sal se envía a quien la solicite, y debido a esto, un atacante podría intentar construir una tabla de arco iris dirigida al solicitar la sal de un usuario específico. Esto aparece en esta pregunta , en el punto # 2.

¿No proporcionaría más seguridad para que el servidor genere de forma aleatoria un salt en un mensaje ClientHello ? En cada solicitud por separado, se enviaría un salt diferente , impidiendo que el atacante pueda compilar una tabla de arco iris dirigida. Además, la sal no se almacenaría en el servidor, lo que haría que la información fuera incluso menos útil en caso de una violación de datos.

Notablemente, este método podría abrir un vector de ataque donde el atacante inicia continuamente el procedimiento de autenticación hasta que el servidor responda con una sal favorable. Sin embargo, si la entropía de la sal s es lo suficientemente grande, esto sería inviable. Además, el servidor podría reducir la cantidad de intentos de autenticación por nombre de usuario I , de modo que un atacante no podría ejecutar este ataque en paralelo con una red de bots.

• Por ejemplo: después de iniciar un intento de autenticación para I , el servidor no responderá a los intentos subsiguientes para autenticar como I dentro de un período de tiempo de, digamos, medio segundo.