There is an older game that solely uses UDP to communicate, and I wanted to add password authentication to the game to facilitate things like experience points and rankings. To this end, I decided to go with an implementation of SRP-6a communicated over UDP using an extension of the existing game protocol, and I ended up using cocagne/csrp on the game client side, tunneled through the game server, and mozilla/node-srp on the authentication server side, slightly modified as to produce the csrp-compatible
HAMK follow-up response.
It has worked reasonably well so far, however I am not a fan of how the verifier is stored at rest, as it appears that in the process of calculating
x the inputs are only hashed once before turning into the verifier
v, see here. I have suggested that we change this library function to suit our needs (since it's reasonably small and already in-tree) and use something along the lines of PBKDF2. However I am getting (understandable) push-back from another developer about touching code of this nature, good intentions and all that.
It was suggested instead that perhaps the user's password itself undergo PBKDF2 hashing before being passed in as a password to the verifier creation and user challenge functions. That way, we do not have to modify any code in the csrp library itself. Is this a valid approach? Or is there another bear-trap waiting to snare us if we do this?
For what it's worth, the complete protocol document is here, so if I'm making any other sorts of snafus it'd be nice to know.