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.

Console sessions

A person who signs in gets a session. A machine does not open one: it presents a token (see API and Service accounts).

• 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 <value> (account.session.revoke).

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:

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).

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.

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.

Common errors

See also: Organisations and members, Single sign-on, Audit log, Agent safety, Sovereignty.

Report a mistake on this page