SpeedRunEthereum icon indicating copy to clipboard operation
SpeedRunEthereum copied to clipboard

Change message to sign

Open dgrcode opened this issue 4 years ago • 1 comments

This is not an MVP feature, but something I think we should consider.

I see the message to be signed something like a CSRF token. If we always send the same message, the same addresses will always produce the same signature, so an eavesdropper will be able to re-authenticate maliciously with the signature they found.

Why we shouldn't worry too much

I don't think this is a big deal because:

  • We won't be dealing with highly sensitive information,
  • All communications will be through https, so eavesdropping will be expensive and definitely not worth it taking into account the information they would get access to if someone is successfully hacked,
  • Even changing the message to sign an eavesdropper would have the JWT token, and complete access until the JWT token is expired.

Why I think this should be implemented at some point

However, I think changing the message to be signed shouldn't be too hard. The only concern here is storing the message to compare it with the signed message. For that, an in-memory dictionary with { [address]: messageToBeSigned } should work completely fine. At least until we have >10k users signing in at the same time (should be fine).

(cc @carletex @sogasg)

dgrcode avatar Sep 17 '21 08:09 dgrcode

From a comment in #48

Nothing to change here, but something to keep in mind. Once we have non-deterministic input to generate the messages (like nonce, timestamp, etc), we'll need a way to store the message even if just in memory because it won't be possible to regenerate the message as we're doing in (currently) line 30:

const trustedMessage = getSignMessageForId(verifyOptions.messageId, verifyOptions);

We also need to update all the messages to sign, not just the one at /sign (we only had that one when the issue was created)

dgrcode avatar Sep 24 '21 15:09 dgrcode