.png%3Falt%3Dmedia%26token%3D0b8c3818-d37b-4dee-b7a0-5d7184ac934c)
.png%3Falt%3Dmedia%26token%3D0b8c3818-d37b-4dee-b7a0-5d7184ac934c)
🔓
Security Considerations
Sign-In with Ethereum Security Considerations
When using SIWE, implementers should aim to mitigate security issues on both the client and server. This is a growing collection of best practices for implementers, but no security checklist can ever be truly complete.
When processing a SIWE message on the backend, it must be validated as per specified in EIP-4361. This is achieved in the quickstart guide by creating the entire SIWE message on the backend, and verifying that the message signed was identical with a valid signature.
However, some implementers may choose not to generate the signing message entirely on the server-side, and instead, have the frontend request specific field values from the server or otherwise agree on a value generation method. The backend then asserts that the received signed message matches what is expected during verification.
(WIP) Notes on select fields and their value selection:
- nonce. To prevent replay attacks, a nonce should be selected with sufficient entropy for the use case, and the server should assert that the nonce matches the expected value. In some systems, the server and client may agree to use a nonce derived from a recent block hash or system time, reducing server interaction.
- domain. Wallets conforming to EIP-4361 are able to check for (or even generate) correct domain bindings to prevent phishing attacks, i.e., that the website "example.org" is indeed securely serving the SIWE message beginning with "example.org wants you to sign in with..."
Last modified 1yr ago