LogoLogo
  • Sign-In with Ethereum
    • ⭐Quickstart Guide
      • Creating SIWE Messages
      • Implement the Frontend
      • Implement the Backend
      • Connect the Frontend
      • Implement Sessions
      • Resolve ENS Profiles
      • Resolve NFT Holdings
  • Libraries
    • ⌨️TypeScript
      • Migrating to v2
      • TypeScript Quickstart
    • 🦀Rust
    • 🍷Elixir
    • 🐍Python
    • 💎Ruby
      • 🛤️Rails
    • 💨Go
  • Integrations
    • 💬Discourse
    • 🛡️NextAuth.js
    • 🖼️Auth0
  • Additional Support
    • 🔓Security Considerations
    • 📇ENS Profile Resolution
    • 🫂Community Highlights
  • Servers
    • 🖥️OIDC Provider
      • ⭐Deployment Guide
      • 🔒Hosted OIDC Provider
  • General Information
    • 📒SIWE Overview
      • 📜EIP-4361
      • 🔍Review of Related EIPs
    • 🚨SIWE Code of Conduct
Powered by GitBook
On this page
  1. Additional Support

Security Considerations

Sign-In with Ethereum Security Considerations

PreviousAuth0NextENS Profile Resolution

Last updated 3 years ago

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.

Message Generation and Validation

When processing a SIWE message on the backend, it must be validated as per specified in EIP-4361. This is achieved in the 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..."

🔓
quickstart guide