With Secure Remote Password protocol SRP6a random numbers are used for
s is the salt registered with the user,
b are random one time ephemeral keys of the user and host respectively. What would be the risk of letting some clients (old webbrowsers which don't have the WebCryptoAPI secure random numbers) perform a password proof using
a which is less random than a good secure source. Lets say that they use the web browsers insecure Math.random and that is seeded with a timestamp.
a was simply a nonce, not even a weak random, then an attacker can gain very little. With each login attempt a unique
B is sent by the server which can always use secure random numbers. This random
B is used with the nonce
a to create a new
S, then from that a new
M2 proof of a new shared key.
Or is it the case that
a being less than a high quality secure random would compromise the security of either the client or the server.
(Edit: Note that sending
a from the server opens you up to a server sending a crafted
B to attack the password using a dictionary lookup of
M1 to give the password so that is not something that anyone should consider doing. The question is about whether
a needs to be truly random not a question about suggested sources of secure random numbers for