Security

Every file you upload is stored under a name the server chooses, never the one it arrived with. That closes a whole family of problems where a crafted filename decides where a file lands.

We record a SHA-256 hash of each file when it is stored, so we can demonstrate later that the bytes have not changed since.

The original is never overwritten. Signing produces a new file and the document points at both. There is no version of an e-Tanzz record that shows only the signed page — the unaltered original it came from is always there beside it.

A signing link is the only thing standing between the open internet and a signable document, so it is built accordingly. Each one carries 32 bytes from a cryptographic random number generator — not a GUID, which on some platforms is partly sequential and partly predictable.

Guessing one is not feasible, and the endpoints that accept a token are rate limited per address so that trying at volume is not feasible either. A token that does not resolve returns the same “not found” as one that never existed, so a stranger learns nothing from the response.

Each recipient gets their own link. Revoking or voiding a document stops every link for it working immediately, checked against the database on each request rather than carried inside the token.

The audit trail is append-only. Nothing in the application updates or deletes an event once it is written — which is what makes it worth showing to anybody.

For each document we record:

• When it was created, and by which account.
• When it was sent, and to which address.
• When the link was first opened.
• When it was signed or declined, the name and title typed, and the explicit confirmation of intent.
• The IP address and browser the signature came from.

A signed record is closed to further writes. You cannot edit a document after it has been signed — you raise a new one that supersedes it, which is what the paper equivalent would require too.

Passwords are stored as salted hashes using a slow, purpose-built algorithm. We cannot read your password, recover it, or tell it to you — only reset it.

Session tokens are stored hashed too. A leaked database backup should not hand somebody a working set of live sessions, which is the same reason passwords are not stored in the clear, applied to the credential actually presented on every request.

The session cookie is httpOnly, so scripts on the page cannot read it. Sessions expire, you can see every device you are signed in on, and you can end any of them.

Two-step verification is available and we recommend turning it on. It uses an authenticator app rather than SMS, because a text message can be redirected by taking over a phone number and an app cannot. Recovery codes are issued at the same moment, stored hashed, and each works once.

New passwords are checked against a public corpus of breached passwords before they are accepted. Only a five-character fragment of the hash leaves our server, and the password itself never does.

Not built yet. The AI features described on the pricing page are marked as coming, and nothing in the product sends your documents anywhere for analysis today.

When they do arrive they will be optional and off the critical path — signing will work completely without them — and this page will say exactly which processor sees document text and on what terms, before the feature is switched on rather than after.

Traffic is served over HTTPS. The application sets a content security policy and the usual protective response headers, and sensitive endpoints — signing in, signing a document, password resets — are rate limited. Those limits are held in the database rather than in memory, so they survive a restart and apply across every server rather than resetting on each one.

Access to documents is checked per request against the account that owns them, in the database query itself rather than in a check that could be skipped. Being signed in is not the same as being allowed, and the two are decided separately.

Sign-ins, failed attempts and security changes are recorded and visible to you under Settings. When you sign in successfully we can tell you how many failed attempts happened before it.

We keep the number of third parties that touch your data small: a host, a database, and an email provider. Every additional service is another place a document could go wrong, which is why the list is published rather than summarised — see who processes your data.

If you find a vulnerability, tell us at support@tsukuba-tech.com and we will get back to you. Please give us a reasonable chance to fix it before publishing.

We will not pursue you for testing carried out in good faith against your own account and your own documents. Do not test against other people’s documents, do not run denial-of-service attempts, and do not access, alter or keep data that is not yours.