triauth

Trust model ​

The security of triauth rests on three things. Knowing them tells you what to protect, and what an attacker gains from each position.

What is trusted ​

The integrity of your DNS records ​

Your public keys are DNS records. Whoever can write to your DNS zone can publish a key and sign in as you. This is the same position that controls your email today, and with it every password reset. Triauth makes it visible. Verifiers read your records through several independent resolvers, and DNSSEC lets them check that your zone signed the records.

The secrecy of your private keys ​

The browser creates the keys and marks them as non-extractable, so no script can read them out. A passphrase can wrap a key, and a security key or biometrics can protect it further. Each device has its own keys, so one lost device means one record to delete.

The integrity of the authenticator's origin ​

Your browser trusts the code it loads from the authenticator's address, and stores your keys for that origin. Whoever controls that origin controls the screen where you approve. Use the hosted authenticator, or host your own copy under your own domain, and keep it updated.

What triauth does not do ​

  • It does not manage sessions. Your application does, and it decides when to re-check.
  • It is not a complete risk-based authentication system. Add a second factor or a confirmation step where your risk profile calls for it, for example for a new device.
  • It does not validate DNSSEC chains itself. It relies on validating resolvers, and it cross-checks them.

Report a vulnerability ​

Email security@triauth.org with a description and, if possible, a proof of concept. At the moment we do not operate a paid bug bounty program.