Security
Security
Seed encryption, team isolation, roles, access log, account protection and hosting: what Share Auth does, and what it does not.
Share Auth stores secrets that open accounts. This page describes how they are protected at every step, and what the tool cannot guarantee.
Seeds stay encrypted
A TOTP seed is encrypted with AES-256 before it is saved, using a key specific to the application that is not kept in the database. It is only decrypted in memory, at the moment a code is computed, and is never returned by the API, the browser extension or the MCP connector: they only receive the current code.
Each team is walled off
A secret belongs to a team. Every request checks that it is part of the person’s active team, then that their role allows the requested action:
- reader: view and copy codes, without seeing the seed;
- editor: add and edit secrets, and see their seed;
- administrator: all of that, plus deletion and billing;
- owner: every right, including members, billing and the access log.
Your plan’s limits apply on top, without ever deleting anything.
Every code handed out is recorded
The access log notes who obtained which code, when and through which channel: website, API, Slack, Discord or Microsoft Teams, with the IP address for the website and the API. It is reserved for the owner. Repeated views of the same secret by the same person are grouped over five minutes, so that a page left open does not flood the history.
Messaging bots
Every bot call is authenticated by the platform’s signature (Slack, Discord or Microsoft Teams), and the number of commands per person is limited. Only the owner can create an integration, and they can disable it at any time.
An integration opens access to the whole connected workspace: the platform proves where the command comes from, not which Share Auth account sends it, so team roles do not apply to it. Per-channel restrictions limit the secrets each channel can obtain. Every code handed out by a bot appears in the log, with the name reported by the platform.
Accounts are protected
- Two-factor authentication for your Share Auth account with a TOTP app, with recovery codes.
- Without an authenticator app, every new browser has to be confirmed by email, by link or by code. A confirmed browser is recognised for 30 days.
- The password is asked for again before a new device is connected, such as the browser extension.
API tokens are limited
A token carries the permissions chosen when it was created, and no more: a token that lists and reads codes cannot change anything. It lasts 1, 7, 30 or 90 days, it can be revoked from your profile, and the API limits each user to 60 requests per minute.
Hosting and transport
The data is hosted in France. Everything goes over HTTPS, with HSTS, and the application pages that display secrets are never cached. Details of the providers are set out in the privacy policy.
What Share Auth does not do
Share Auth shares 2FA codes. It replaces neither a password manager nor an identity management strategy, and it does not protect an account whose password is already circulating. Keep your list of editors short: they are the ones who can see the seeds.
Frequently asked questions
Editors, administrators and owners, from a secret's edit page, so that they can move it elsewhere. A reader only sees the current code. The API, the extension and the MCP connector never return the seed, whatever the role.
You remove them from the team, and their access stops. As a reader they never had an account's seed, so they have nothing to give back. Their API tokens stop giving access to the team's secrets, since they act on their behalf.
In France, with o2switch and Scaleway. The application's traffic goes through Cloudflare, and payments through Stripe: card details never pass through our servers. The privacy policy lists the providers and the transfers.
Write to us from the Contact page, choosing the subject "Security and compliance". Describe the problem without publishing it anywhere else, and we will get back to you before any disclosure.