Sign In With Solana Security

[ljiatu]

After reviewing the code for Sign In with Solana, I have a couple of questions about its implementation. Based on my understanding, the process operates as follows:

1. The frontend receives input from the backend and requests the wallet to sign it.
2. The frontend sends both the input and the signed output back to the backend for verification.
3. The backend parses the signedMessage from the output to reconstruct the input and compares it with the original input field by field.
4. The backend re-serializes the parsed output into string format and compares it with the signedMessage from the output to ensure byte-level equality.
5. Finally, the backend verifies the signature to confirm that the wallet indeed signed the signedMessage.

Here are my questions:

1. In the example code provided in the "Dapp Integration" section, the backend relies on both the input and output passed from the frontend for verification. Isn't this insecure since the input could have been tampered with? Shouldn't the backend perform the comparison using values stored server-side (or stored client-side but encrypted)?
2. Is the byte-level comparison in step 4 necessary? It seems redundant because the backend could simply verify that the signature matches the re-serialized message from step 4.

[adamdelphantom]

Hey @ljiatu,

Sorry for the delay in response. With regards to your questions:

1. The example code is just meant to illustrate how to use the verifySignIn method. Please use your judgement for determining the appropriate level of input security for your use case.

2. I'm somewhat confused by this question. Your stating 'step 4 is redundant because you could verify the sig matches from step 4.' Would you mind restating it?

[ljiatu]

Hi @adamdelphantom,

For #2, I'm wondering if the byte-level comparison in the first half of this line necessary: https://github.com/anza-xyz/wallet-standard/blob/2c354cf07daa1d440ba9631fcefc5c00b07aa9dd/packages/core/util/src/signMessage.ts#L20. Can't we just do ed25519.verify on the re-constructed message?

[0xproflupin]

byte-level comparison is necessary because of the following case:

1. client constructs message parameters for message M1, sends these parameters to the wallet for signature
2. malicious MITM changes the message to M2 and makes the user sign it with pubkey P, to get sig S.
3. Returns M2, P, S to the client, which then forwards them to the backend for deconstruction and verification.
4. ed25519.verify(S, M2, P) returns true.

I do agree that step 3 (deconstruction) that you have stated in your original post minimizes the chances of such an attack, but this check makes it more fool-proof.

[ljiatu]

Not sure I follow. If in step 3 the client forwards M2 to the backend, wouldn't byte-level comparison still pass?