← Back to blog
Engineering

Sign-In with Ethereum: how Sudo replaced passwords with cryptography

Sudo has no password field, no email field, no recovery questions. The only thing we ever ask for is a signature from a wallet you already control. Here is what that means, why it matters and how it works under the hood.

Sudo Engineering@eng.sudo··11 min read
Engineering

Open most apps and the first thing you see is a username field. Sudo doesn't have one. We don't have a password field either. There is no email recovery flow, no SMS one-time code, no security question about your first pet's middle name. The only thing the Sudo client ever asks you for is a single signature from a wallet you already control.

This post unpacks what Sign-In with Ethereum (SIWE, formalised in EIP-4361) actually is, why we believe it is the most underrated piece of plumbing in Web3, and how Sudo uses it to replace the entire identity stack of a traditional messenger.

The problem with passwords is older than the web

Passwords were invented in 1961 at MIT to ration time on the CTSS mainframe. They have outlived their usefulness by sixty years. We know they are bad — we have known since the first big credential breach. Users reuse them, attackers phish them, databases leak them, and the recovery flows we build around them (SMS codes, security questions, email magic links) are themselves attack surfaces. Every additional fallback turns the highest-trust act of your account — proving you are you — into the weakest link in the system.

The Web2 industry tried to fix this with password managers, hardware tokens, FIDO/WebAuthn and passkeys. All of those help. None of them remove the central authority that ultimately decides who you are. Apple, Google, your employer's IdP, your bank — somebody still owns the row in a database that says "this human controls this identifier" and can therefore lock you out, hand you over, or get breached on your behalf.

Sudo's bet is that the cryptographic key in your wallet — the same one you already use to move money on chain — is a much better root of trust than anything a centralised provider can give you. You generated it. You hold it. Nobody can take it from you.

What SIWE actually does

SIWE is a tiny standard. The whole spec fits on a few pages. Here is the short version.

When you click "Connect wallet" in Sudo, the client builds a human-readable challenge message that looks roughly like this:

sudo.so wants you to sign in with your Ethereum account: 0x7e3F…9C12

URI: https://sudo.so Version: 1 Chain ID: 1 Nonce: 9f2b4ad1 Issued At: 2026-04-29T08:00:00Z Expiration Time: 2026-04-29T08:10:00Z

Your wallet displays that message in plaintext, you tap "Sign", and the wallet returns a signature that is mathematically bound to (a) the exact text of that challenge and (b) the private key behind your address. Sudo's relay verifies the signature with one curve operation, checks the nonce was the one we issued in the last ten minutes, and lets you in.

That is the entire authentication flow. There is no password to forget, no database row to leak, no email server to spoof, no SMS gateway to SIM-swap. The signature is short-lived, single-use, scoped to a domain, and impossible to replay anywhere else.

What we deliberately don't store

A traditional auth system stores a password hash, a session table, a recovery email, an OTP secret, IP history, device fingerprints, and a long tail of attributes nobody can quite explain. Each one is a target.

Sudo stores none of that. After we verify your signature, we issue a short-lived JWT (15 minutes) signed by our relay, plus a refresh token bound to a per-device key your client generated. The refresh token is symmetric, never leaves your device unencrypted, and is invalidated the moment you press "Sign out everywhere" — which any client can issue with a fresh signed challenge.

There is no "forgot password" link because there is nothing to forget. If you lose access to your wallet, you lose access to that Sudo identity, the same way you would lose access to the funds inside it. We are explicit about that trade-off — see the delete-account page — and we strongly recommend social-recovery wallets, multisig signers or a hardware key for any meaningful balance.

What about smart accounts?

The simple SIWE flow assumes an externally owned account: a private key signs, the curve verifies. Smart accounts (ERC-4337, Safe multisigs, account-abstraction wallets) are more interesting because there is no single private key to point at — instead, a contract decides whether a signature is valid.

Sudo handles this through EIP-1271. When the address you connect resolves to a contract, our verifier doesn't try to recover a public key. Instead it calls the contract's isValidSignature function with the original challenge and the signature your wallet returned. The contract decides whether it counts as a valid sign-in. That single change unlocks signing in as a 3-of-5 multisig, as a corporate Safe, as a passkey-controlled smart account or as any future AA flavour.

What we still can't fix

SIWE is not magic. A few problems remain, and we want to be honest about them.

The signing UX is still ugly in many wallets. Several mobile wallets show signature prompts as opaque hex blobs instead of the readable EIP-4361 text, which trains users to sign anything. We are pushing every wallet vendor we work with toward proper EIP-4361 rendering, and the Sudo client refuses to issue a challenge to wallets that do not support readable formatting.

Phishing also moves up the stack. A malicious site can still ask you to sign a SIWE message scoped to its own domain — and if you sign, it gets a session on its own service, not on Sudo. The defence is the same as for any signing UI: read the domain in the message before you tap. Hardware wallets that display the domain on a separate trusted screen are a meaningful upgrade.

Finally, key loss is permanent. We cannot recover your wallet for you. We will not pretend otherwise.

Why this matters beyond Sudo

The reason we belabour SIWE is that it is the missing piece in the move from "Web3 is a wallet you connect to a dApp" to "Web3 is a continuous identity that follows you across the open internet". Once your wallet is the login, the same identity that owns your tokens owns your DMs, your communities, your votes, your subscriptions, your validator bond and your reputation. Nothing has to be re-created in fifty different databases.

The flip side is that you are responsible for one key in a way you have never been responsible for a password. The next decade of consumer crypto is going to be about making that key easier to hold safely — through smart accounts, social recovery, hardware signers and better mobile UX. Sudo is built to assume those tools win. SIWE is the bridge.

What's next

We are working on three SIWE upgrades for the next quarter. First, a one-click subscription flow where a single signature can grant a recurring permission to a specific contract for a capped amount and duration. Second, sign-in with EIP-7702 delegations, so you can use a session key for a low-value action without unlocking your hardware wallet every time. Third, a "wallet health" check that nags you when your signing wallet has not been used for a high-stakes action in months — a soft prompt to test your recovery before you need it.

If you want to follow the work, the discussion happens in the developers community and the relevant EIPs are cited in the whitepaper.

Subscribe

Get the next post in your wallet.