Part 6 · Security, compliance and privacy

OTP tokens

Keep your one-time codes in a personal vault encrypted in the browser, file them by client, and share them with your phone.

Symbifox 18.0 (September 2026 catalogue) · Modules: OTP · Revised 2026-09-12

The Tokens OTP (OTP tokens) application stores the one-time codes that act as the second factor of your accounts. It is for anyone who holds credentials for themselves or for clients, and for the organization that wants to know what it holds without ever being able to read it. The vault is personal: each code's seed is encrypted in your browser, with a key derived from a passphrase that never leaves it. The result: your codes live in Symbifox, filed by client and by engagement, and the server remains unable to produce a single one.

Overview#

Two screens, two uses. Mon coffre (my vault) is the live screen: it opens with a passphrase, shows the codes, copies them, and closes by itself after five minutes without activity. The Inventaire (inventory) is the list in the Odoo sense: it is for filing, filtering and finding, never for producing a code.

A token is a protected account: an issuer, an account, a type, and the encrypted seed that produces the code. Two types exist: the code that changes every thirty seconds, and the counter-based code, which moves up one step with each use. A vault belongs to one person and one only; it holds the tokens, the enrolled passkeys and the recovery codes.

The principle of the module fits in one sentence: producing a code requires the seed in clear text, so that moment never happens on the server. Symbifox keeps only the encrypted data and a verifier, which lets it say “wrong passphrase” without knowing anything about the right one. The issuer and the account, on the other hand, stay readable on purpose: that is what makes searching, sorting and keeping the inventory possible.

Filing relies on two neighbouring applications. A token points to a Client in the Contacts application and to a Projet (project). The contact's record and the project's record then count the tokens linked to them, through a shortcut button at the top of the form.

Configuration#

Access and permissions#

A single group exists, Utilisateur (user). It opens the application, the person's vault and their inventory. It opens nothing that belongs to others: a rule limits each vault to its owner, and a person who tries to open someone else's token gets an access error, administrators included.

The vault requires a secure connection. Served without HTTPS, it refuses to work and says so in a banner, rather than failing field by field.

Settings#

The module adds no setting to the general Settings. Everything configurable belongs to the vault itself: the passphrase, the passkeys and the recovery codes, all three managed from Mon coffre.

Base data#

Nothing needs to be created in advance, with three reservations. Choose your passphrase and keep it somewhere other than the service these codes protect. Decide on your groupings: with no label, the client serves as the grouping, and failing that the issuer, as soon as it holds more than one token. Finally, the clients and projects you will link your tokens to must exist in Contacts and in Project.

Getting started#

This walkthrough creates your vault and files a first code in it. It happens entirely in your browser, on an HTTPS address.

1. Open Tokens OTP › Mon coffre.
2. Enter the passphrase that will open this vault, then confirm it.
3. Add a token by pasting the setup address the service gives you in place of its QR code, or by entering its details by hand.
4. Check the proposed Émetteur (issuer) and Compte (account), then save the token.
5. Create a recovery code and store it offline, in an envelope or a safe.
6. Open Tokens OTP › Inventaire and select the token you just created.
7. Fill in Client, Projet and Regroupement (grouping), then save.

Result: the code appears in Mon coffre and is copied in one step; the inventory shows who this token belongs to and for which engagement. The seed never left your browser other than encrypted.

Common tasks#

Add a token by hand#

The usual case is a service that shows a QR code without giving any text: it almost always offers a key to copy.

1. Open Tokens OTP › Mon coffre and enter your passphrase.
2. Ask to add a token, then choose manual entry.
3. Enter the Émetteur and the Compte, then paste the key supplied by the service.
4. Check the Type, the Algorithme (algorithm), the number of Chiffres (digits) and the Période (s) (period, in seconds).
5. Save.

Result: the token appears in the vault and produces its code. The seed is encrypted before it is sent; the server receives only the encrypted data and its vector.

Find and copy a code#

A vault holding dozens of credentials is browsed with the keyboard, not the mouse.

1. Open Mon coffre and enter your passphrase.
2. Type the first letters of the issuer or of the account.
3. Press Enter to copy the code shown.
4. Press Esc to close the vault.

Result: the code is on the clipboard and the token's last-used date is updated, which brings the credentials you really use back to the top.

File a token by client and by engagement#

Filing happens from the inventory, not from the vault: these fields do not touch the seed.

1. Open Tokens OTP › Inventaire and select the token.
2. Fill in Client and Projet.
3. If needed, enter a Regroupement, for example “Production” or the name of a team.
4. Check Sensible (sensitive) so that the code stays hidden until someone asks for it.
5. Save.

Result: the contact's record and the project's record count this token in their shortcut button, and the vault files it under its grouping.

Enrol a passkey#

A passkey opens the vault with a fingerprint, a face or a hardware key, instead of the passphrase.

1. Open Mon coffre and enter your passphrase.
2. Open the passkeys panel and ask to add a device.
3. Name the device, for example “laptop” or “yellow key”.
4. Confirm with your passphrase.
5. Touch the sensor or insert the key.

Result: the device now opens the vault. The vault key has not changed, so no seed was re-encrypted. Enrolment asks for the passphrase again on purpose, because adding a way to open a vault is confirmed by something you know.

Set a recovery code#

A passkey is tied to a device and to a domain. A recovery code fits in an envelope and outlives the laptop.

1. Open Mon coffre and enter your passphrase.
2. Ask to create a recovery code.
3. Say where it will be kept, for example “envelope in the safe”.
4. Copy the code shown and store it offline right away.

Result: the code opens the vault just like the passphrase. It is shown once only and is never sent to the server: nothing anywhere makes it possible to find it again. Five codes at most per vault.

Import an existing vault#

The import recognizes the source from the content of the file, without you having to declare it.

1. Open Mon coffre and enter your passphrase.
2. Ask to import, then choose the file: a Symbifox export, a Google Authenticator export or an export from the Nextcloud code manager.
3. Enter the passphrase that protects that file, if it is encrypted.
4. Confirm the import.

Result: the tokens enter your vault, decrypted and then re-encrypted in the page. The links come back by name, and only when the name designates a single client or a single project in the instance.

Export your vault#

The export is for moving to another instance or keeping an offline copy.

1. Open Mon coffre and enter your passphrase.
2. Ask for the export.
3. Choose a passphrase for the file itself, different from the vault's.
4. Save the file produced.

Result: an encrypted file, readable on another instance since it does not depend on the vault key. There is no clear-text export at all, and that is deliberate.

Remove a token without destroying it#

Removing is reversible; destroying is not, and takes two steps.

1. Open Mon coffre and enter your passphrase.
2. Move the token to the trash.
3. To bring it back, take it out of the trash; to erase it, confirm the destruction.

Result: a token in the trash no longer appears in the list of codes, keeps the date it was discarded, and nothing destroys it on its own.

Pair the mobile app#

The mobile app reads QR codes with the camera, which the browser on a computer does not do.

1. Open Symbifox in your phone's browser and sign in.
2. Open Tokens OTP › Mon coffre and ask to pair a device.
3. Let the app take over, and name the device.
4. Open your vault on the phone with your passphrase.

Result: the phone reads QR codes, encrypts the seed on the spot and sends it already sealed. Codes copied on the phone move up in the usage sort, and a counter-based code's counter advances where the code was produced. The rest of the mobile workflow is described in Mobile apps and browser extension.

Find what you hold for a client#

This is the question for the day someone leaves, or the day a client asks for an accounting.

1. Open Tokens OTP › Inventaire.
2. Group by Client, or enter the client's name in the search.
3. Read the Dernière utilisation (last used) column to spot dormant credentials.

Result: the list of what you hold for this client, with each token's project and grouping. The same count is available from the contact's record, through its shortcut button.

The menus, one by one#

Tokens OTP › Mon coffre: the vault screen, served in the page rather than by the server. It opens with the passphrase or with an enrolled passkey, shows the codes with the favourites first, and offers keyboard search, adding, import, export, passkeys, recovery codes and the trash. On the demo, served without HTTPS, it shows only a warning banner.

Tokens OTP › Inventaire: the list of the tokens in your vault, with the Émetteur, Compte, Regroupement, Client, Projet, Sensible and Dernière utilisation columns, plus the favourite star at the start of each row. Group by client or by project for an overview. The screen stays empty as long as your vault is, and its help text reminds you that tokens are added from Mon coffre: this inventory is for filing them, not for creating them.

Reference#

Fields of the Token form#

Reports and exports#

The application produces no printable report. The only file that leaves the vault is its encrypted export, protected by a passphrase chosen at export time. The inventory can otherwise be exported like any list in Symbifox, but it contains no readable seed.

Automations#

An hourly run clears device pairings that were left in progress. The rest happens in the page: the vault closes by itself after five minutes without activity, the last-used date is written each time a code is copied, and a counter-based code's counter advances where the code was produced, on the computer or on the phone.

Public pages and portal#

The module exposes no public page. The addresses it serves to the mobile app, for pairing, for enrolling a passkey and for recording a token, all require an open session. Only a branding probe answers before sign-in, and it returns nothing but the company name and two colours.

Modules that extend this application#

No satellite module is added to Tokens OTP. The module does rely on the Project application, which provides the token's Projet field, and on Contacts for the Client field; without them, filing loses its two axes. The counters that appear on a contact's record and on a project's record come from this module, and count only your own tokens.

Understanding#

Whoever produces, holds. A one-time code is computed from a seed in clear text. A service that produces your codes therefore holds your secrets, whatever it claims. This module moves the computation into your page: the server has neither the key nor anything to derive it from, and no encryption library is even loaded on its side.

Why no fingerprint of the passphrase is kept. Keeping a hash of the passphrase would give anyone who reads the database a better starting point than the encrypted data itself. Instead, the vault keeps a verifier: a known text, encrypted with the key, which makes it possible to say “wrong passphrase” without revealing anything about the right one.

Why the icons are bundled. About thirty common services have their icon inside the module. None is fetched from the web: the request would reveal to the service, and to anyone watching the network, the list of accounts you protect. Anything unrecognized gets a coloured badge computed from the name.

Why a passkey does not replace the passphrase. A passkey is tied to a device and to an origin: one enrolled on a domain will not open the vault from another, or from a browser extension. It seals a copy of the vault key; it does not replace it. The passphrase remains the fallback, and the recovery code is the only way to survive losing it.

Why there is no clear-text export. A file of readable seeds forgotten in a downloads folder is an open vault that nobody remembers three months later. The export is therefore always encrypted, under a passphrase distinct from the vault's, so that it can be read elsewhere without depending on this instance.

What the module does not do. Sharing a token between two people does not exist: it would require envelope encryption, where each token's key is sealed for each recipient. Reading a QR code with the camera does not exist on a computer either; the mobile app takes care of that, and on a computer you paste the content of the code.

What the server sees all the same. The issuer and the account are in clear text, on purpose: without them, no search, no sorting, no inventory. A person who administers the instance can therefore see that a token exists and remove it, but never read the code it produces.

Troubleshooting#

See also#

• Mobile apps and browser extension: the app that reads QR codes and opens your vault on the phone.
• Contacts: the client record where the count of tokens held is read.
• Project: the engagement a token is linked to.
• Secure transfers: the one-time codes that protect a transfer, not to be confused with this vault.
• Security awareness: the training that goes with two-factor authentication.