Wallet Sign-In

A user connects a wallet, signs a message, and Rails verifies the signature itself. There is no third party in this path: Onchain::Signature does secp256k1 public-key recovery on Ruby's stdlib OpenSSL bindings.

Why no gem

Ruby's OpenSSL binding exposes EC::Point#mul(bn1, bn2), which computes bn1 * P + bn2 * G. That is exactly the ECDSA recovery equation, so no libsecp256k1 binding is needed: no C extension, no autotools in the Dockerfile, nothing new for a fresh clone to fail on. A full verification measures around three milliseconds against a five-minute challenge window.

Keccak-256 is hand-written for a sharper reason. OpenSSL ships SHA3-256, which is a different function: NIST changed the padding byte between Keccak's submission and the SHA-3 standard. Substituting it produces confident, wrong addresses with no error at all. A spec asserts the two disagree, so nobody makes that swap later.

Correctness comes from implementations that are not ours. spec/fixtures/onchain/ holds nine (address, message, signature, digest) quadruples generated by viem, and the address and hash specs use the published EIP-55 and Keccak vectors. A round trip through our own signing code would only prove it is self-consistent with itself.

The server builds the message

Rails builds the canonical EIP-4361 message, stores it verbatim in siwe_nonces.message, and never parses a client-supplied one. Verification re-reads the stored text.

Every SIWE vulnerability to date has lived in a lenient message parser: the grammar is fiddly, and a parser that disagrees with what the wallet displayed is exploitable. Storing the exact signed string deletes that entire class of bug for the cost of one column.

The challenge is also bound to the host it was issued for, and that is re-checked at verification. A challenge minted on one domain cannot be spent on another.

Cold signup has two steps, and both matter

A wallet proves control of an address and nothing else, while this app's accounts are keyed on an email. So a visitor the app has never seen signs once, and then supplies an email in a plain form (not a second wallet popup):

1. Signature. A known wallet signs in. A signed-in visitor links the wallet to their existing account. An unknown wallet is recorded as verified, and asked for an email.
2. Email. Claimed through User.upsert_by_email!, the kit's single account-creation chokepoint, so the welcome mail, the Stripe customer and the GDPR export all keep working untouched.

Two guards in step two are load-bearing:

The pending challenge is bound to the browser session. Without that, anyone who observed the nonce could claim the wallet under their own email address.

An email that already has an account is refused, never linked. Signing proves control of the wallet; it proves nothing about the mailbox. Auto-linking would let anyone holding any wallet seize any account simply by typing its email. This is the same reasoning as User::UnverifiedProviderEmail in the OAuth path, and it gets the same explicit refusal.

upsert_by_email! is called with verified: false, so email_verified_at stays nil. Anything in your app that needs a proven email address still gates on it.

Two limits to know about

One sign-in wallet per user. The identities table is uniquely indexed on (user_id, provider), which is obviously right for "link Google at most once" and debatable for wallets, where people hold several. Relaxing it is a schema decision (which address is the identity when any of three can sign?), so v1 keeps the existing contract and fails with an actionable message rather than a raw constraint violation.

Smart-contract wallets need a real RPC. Coinbase Smart Wallet and Safe sign via ERC-1271, which requires a contract call to verify. Against the offline fake they cannot sign in. That is a configuration limit rather than a bug, but it presents as an intermittent one if you do not know it.

Trying it

Open /onchain and click Connect. Signing costs no gas and sends no transaction: it is a proof of control, not a payment.