# Account and organisation security This page gathers what protects access to your projects: console sessions, the password, the second factor and making it mandatory in an organisation, Glowsoft staff access to your data, and how to report a vulnerability to us. The security of your application's data (policies, backend keys) is covered in [Data security](data-security.md). ## Console sessions A person who signs in gets a **session**. A machine does not open one: it presents a token (see [API](api.md) and [Service accounts](service-accounts.md)). - A session closes **8 hours** after it opens, and after **60 minutes** without a call. - It carries no scopes: it is the person who is there, with everything their rank allows. - Changing your password or second factor closes the account's other sessions; a role change closes all of them. On the **Compte** (Account) screen, the "Sessions" card lists your open sessions, where they were opened from, until when, and with which factor. Closing a session refuses it on the next call; it does not reopen. From the command line: `bastide account session list`, then `bastide account session revoke --session-id ` ([account.session.revoke](../reference/operations/account.session.revoke.md)). ## Password and attempts - At least **12 characters**, at most 256. It must not reuse your address and must not appear among compromised or overly common passwords; the check is done locally, with no third-party service. Only a hash is stored. - **5 failures in 15 minutes** for one account from one IP address trigger a wait: 60 seconds, then double for each further failure, up to 15 minutes. The response is `trop_de_tentatives`, with a `Retry-After` header. - An unknown address, a suspended account and a wrong password all get the same response, `identifiants_invalides`. The password is changed on **Compte**, "Mot de passe" (password) card, under a session (not under a token). ## The second factor Three methods, added on **Compte**, "Second facteur" (second factor) card: - **An authenticator app** (TOTP: 6 digits, 30 seconds). An accepted code cannot be used again. - **A passkey** (WebAuthn): it signs for the console only, and requires your presence and verification (PIN or fingerprint). - **Ten recovery codes**, single use, shown only once when the first factor is confirmed. You can issue ten new ones, which replace the old ones. At sign-in, the right password returns a challenge; the second step must follow within **5 minutes**, in at most **5 attempts**. ### Rights guarded by the second factor Writing SQL, migrating the database and managing backend keys require a second factor, **whatever the organisation**. In practice: - the roles that open these actions, Maintainer, Administrator and Owner, can only be given (by a role change or by accepting an invitation) to an account holding a confirmed factor; otherwise `second_factor_required`, and nothing is written; - the last factor of an account holding such a role cannot be removed. A service account cannot hold a factor: it is not affected, and its safeguard is the named exemption described below. ## Make the second factor mandatory in the organisation An organisation can require a second factor from its **Owners**, **Administrators** and **Security** members. 1. Open the organisation's **Réglages** (Settings), "Second facteur" section. The card shows the state of the obligation and how many affected accounts have no factor; **Membres** (Members) says which ones. 2. Turn the obligation on (Owner or Security role). 3. A **14-day** grace period starts. Reminders are written to the audit log: four before the end, one at the block. The notices sent to each account can be read back in the "Avis reçus" (notices received) card of their **Compte** screen. 4. After the grace period, an account in these roles without a confirmed factor is refused in the organisation, through its session as well as its tokens, with `second_factor_required`. Enrolling a factor restores access at once. Turning the obligation off restores access immediately to the refused accounts; turning it on again keeps the date of the first activation. From the command line: ```sh bastide organization second_factor configure --organization-id org_01JQ8ZK4M7NP2RSTVWXYZ34567 --required true ``` ### Exempt a service account Only a service-account token of the organisation can be exempted; a person never exempts themselves. The exemption needs a reason (one sentence of 20 to 500 characters) and lapses on its own after at most **92 days**, for a quarterly review. Granting a new one to the same account removes the previous one. Active, expired and removed exemptions stay in the list, with who granted them. An agent reads this list with `organization_second_factor_exemption_list`; granting or removing an exemption remains a human action, from the console, the command line or the API ([organization.second_factor_exemption.create](../reference/operations/organization.second_factor_exemption.create.md)). ## Glowsoft staff access to your data Glowsoft team roles apply only at platform level: none of them is valid in your organisation. To reach a project's data, an operator must obtain an **access**, limited to that project and in time. - **At your request or with your consent.** An operator asks, stating why, for how long and in which mode (read, or read and write). The project's Owner or an Administrator decides, in the project's **Réglages** (Settings), "Accès" (access) section, "Accès de Glowsoft" card. An accepted access lasts as long as requested, **eight hours at most**. - **On a qualified incident.** An access can be opened without your consent to handle an incident; it then requires validation by a second Glowsoft operator. It shows in the same card, marked "sur incident" (on incident), with its reason. - **Always logged, always revocable.** Every action taken under an access goes into the project's audit log, in the operator's name. "Révoquer maintenant" (revoke now) cuts the access at any time; "Refuser" (refuse) turns a request down. An agent can list requests (`access_request_list`) and refuse or revoke an access (`access_request_revoke`). Accepting a request is reserved to a person, from the console or with `bastide access request accept`. > **Note.** No access is ever opened silently: either you accepted it, or it carries the incident mark and the double validation, and in both cases it is in the audit log. See [Audit log](audit.md). ## Report a vulnerability Write to **abuse@glowsoft.fr**, in French or English: what you observed, how to reproduce it, what it would allow. Do not attach any real customer data. - Acknowledgement within **72 hours**; assessment within **7 days**, with the severity retained and the target fix time. - No legal action against good-faith research: on your own account, without accessing other people's data beyond the proof, without degrading the service, without publishing before the fix or an agreed delay. The full policy is published at `https://bastide.app/divulgation-coordonnee` (the console also serves it at `/divulgation-coordonnee`). The `/.well-known/security.txt` file of the console, the API and the website gives the same address. Illegal content hosted on Bastide is reported through the console's public `/signaler` page instead; see [Acceptable use](acceptable-use.md). ## Common errors | Code | What happens | What to do | | --- | --- | --- | | `second_factor_required` | The organisation requires a factor and you have none; or the target role requires one. | Add a factor on **Compte**, then try again. | | `second_facteur_requis` | Normal sign-in response: the password is right, the second step is expected. | Give the code, the passkey or a recovery code within 5 minutes. | | `defi_expire` | The challenge has expired, was already used, or its 5 attempts are spent. | Start again with the password. | | `trop_de_tentatives` | Too many failures from this IP address. | Wait for the `Retry-After` time. | See also: [Organisations and members](organizations.md), [Single sign-on](sso.md), [Audit log](audit.md), [Agent safety](agent-safety.md), [Sovereignty](sovereignty.md).