How secure is e signing

Three credentials that do different jobs

Owner routes, everything to do with creating, preparing and tracking envelopes, require the account holder's own signed in session. The recipient token in a signing link identifies which row a request concerns but authorises nothing on its own. Past the identity check, a separate short lived session is issued, bound to that one recipient, and it is what the document, submit and decline routes actually require. Mixing those three up is how a product like this becomes insecure, so they are kept apart.

The link on its own reveals almost nothing

Somebody holding a signing link, before passing whichever check applies, can learn the document title, the name and address of the recipient it was issued to, and which check is required. Not the pages, not a preview, not the other parties, not the file. That is the point of serving the challenge separately from the document, and it is why a forwarded email is not a leak of the contract.

Codes are stored the way passwords are

Access codes and emailed one-time codes are never stored in readable form. Each is hashed with scrypt against its own random salt, and comparison is done with a constant time function, so the time a wrong guess takes gives nothing away. No route hands a code back, to the sender or to anybody else. Guessing is capped per recipient: five failed attempts and that recipient is locked out for fifteen minutes, with the counter written conditionally so a burst of parallel guesses cannot slip past it.

Evidence is written once

The uploaded document is never written to again. Each signature produces a new working file under its own key rather than replacing the previous one, and the completed copy gets a key derived from its own hash. The storage bucket is versioned as a further backstop. The event log is append only, enforced by a database rule that refuses to modify a row, and the hash chain over it means a missing row is detectable rather than invisible.

Concurrency is handled deliberately

Status changes are conditional writes against the state that was read, so a double clicked Send cannot dispatch two sets of invitations and two simultaneous submissions cannot both be accepted as the same signature. A one-time code is redeemed with a conditional write too, so the same digits cannot be spent twice. These are unglamorous details, and they are the difference between a clean record and one with two of everything in it.

What none of this protects against

An identity check confirms access to an inbox or knowledge of a code, not who is at the keyboard. If the invitation and an emailed code both land in the same shared mailbox, they are one factor rather than two. The recorded address is what the edge saw, which for corporate networks is often shared. And the ordinary risks apply: your own account is only as safe as its password, and a code you email alongside the link protects nothing at all.

How it works, in three steps

1. Step 1

   Pick the check that matches the document

   Link only for routine work. An access code shared over the phone where the contents or the value justify a genuinely separate channel.

2. Step 2

   Never send the code down the same wire

   The product deliberately does not deliver access codes, so that a single compromised inbox is not enough on its own.

3. Step 3

   Check the chain badge when it matters

   Opening an envelope re-verifies its whole event chain and reports the result, rather than trusting a stored flag.

Limits worth knowing

• A signing session lasts thirty minutes and is never persisted, so reloading the signer's page means verifying again.
• Emailed one-time codes arrive at the same address as the invitation, which makes them one factor rather than two.
• Recorded addresses come from the trusted edge hop and are frequently shared corporate or mobile addresses.
• Nobody verifies that a signer has authority to bind the organisation they name on the page.

Questions people ask

Related pages