Trois questions de sécurité reviennent à chaque audit d'une instance Odoo : quelle est la politique de mot de passe, le double facteur est-il obligatoire, et qui peut se connecter sous l'identité d'un autre. Le standard répond faiblement aux deux premières et pas du tout à la troisième.
Onze modules communautaires y répondent — et ajoutent un coffre-fort de secrets chiffré de bout en bout.
Résumé
Quatre modules traitent les mots de passe : une politique par société — longueur, composition —, un assistant pour vider le mot de passe d'un ou plusieurs utilisateurs, la vérification de l'adresse de courriel à l'auto-inscription, et le login rendu insensible à la casse.
Un module impose le double facteur : les utilisateurs doivent configurer une application d'authentification avant de pouvoir se connecter.
Trois modules traitent l'accès au compte d'autrui : la connexion de l'administrateur système sur n'importe quel compte avec son propre mot de passe, l'usurpation d'identité tracée pour le support, et un bouton d'historique des connexions sur la fiche utilisateur.
Un module corrige la confusion entre login et adresse de courriel sur la fiche utilisateur. Deux modules enfin ajoutent un coffre-fort de secrets chiffré dans le navigateur, avec une clé maîtresse par coffre, et le partage ponctuel d'un secret avec une personne sans compte Odoo.
L'essentiel
- Une politique de mot de passe par société : longueur, composition.
- Le double facteur imposé avant toute connexion.
- Le login insensible à la casse.
- L'adresse de courriel vérifiée à l'auto-inscription.
- L'usurpation d'identité tracée dans un journal dédié.
- L'historique des connexions depuis la fiche utilisateur.
- Un coffre-fort chiffré de bout en bout, dans le navigateur.
- Le partage d'un secret avec une personne sans compte.
Ce que ces modules ajoutent à l'instance
| Module | Version | Ce qu'il apporte |
|---|---|---|
password_security | 18.0.1.0.2 | Exigences de mot de passe par société (LGPL-3) |
auth_totp_enforce | 18.0.1.0.0 | Double facteur imposé avant connexion |
auth_user_case_insensitive | 18.0.1.0.0 | Login insensible à la casse |
auth_signup_verify_email | 18.0.1.0.0 | Adresse de courriel vérifiée à l'auto-inscription |
base_user_empty_password | 18.0.1.0.0 | Assistant de vidage du mot de passe |
base_user_show_email | 18.0.1.0.0 | Login et courriel distingués sur la fiche utilisateur |
auth_admin_passkey | 18.0.1.0.0 | Connexion de l'administrateur sur tout compte avec son propre mot de passe |
impersonate_login | 18.0.1.1.2 | Usurpation tracée (Paramètres ▸ Technique ▸ Journaux de l'usurpation d'identité) |
user_log_view | 18.0.1.0.0 | Historique des connexions sur la fiche utilisateur (LGPL-3) |
vault | 18.0.1.0.10 | Coffre-fort de secrets chiffré de bout en bout |
vault_share | 18.0.1.0.2 | Partage ponctuel d'un secret par lien protégé |
Les menus : Paramètres ▸ Technique ▸ Journaux de l'usurpation d'identité, et un menu racine Vault avec ses entrées, sa boîte de réception, ses droits et ses partages.
Les mots de passe
Odoo n'impose qu'une longueur minimale globale. Une PME qui doit justifier d'une politique de mot de passe — pour une certification, une assurance cyber ou un client donneur d'ordre — n'a rien à montrer.
password_security (LGPL-3) définit au niveau de la société la longueur minimale et la composition exigée — minuscules, majuscules, chiffres, caractères spéciaux. Il s'appuie sur les modules de politique de mot de passe et de double facteur du standard.
base_user_empty_passwordajoute un assistant vidant le mot de passe d'un ou plusieurs utilisateurs, depuis la liste ou la fiche. Il force le passage par une réinitialisation.auth_user_case_insensitiverend le login insensible à la casse : peu importe la façon dont l'utilisateur saisit son identifiant.auth_signup_verify_emailforce les utilisateurs qui s'auto-inscrivent à fournir une adresse valide, en retirant la saisie du mot de passe à l'inscription — il n'est demandé qu'à la confirmation de l'adresse.
Le login insensible à la casse est de ces modules qu'on installe après avoir perdu une heure : un utilisateur dont l'adresse a été créée avec une majuscule ne peut pas se connecter en minuscules, et personne ne pense à cela.
auth_totp_enforce impose le double facteur : les utilisateurs doivent configurer une application d'authentification avant de pouvoir se connecter. C'est la mesure la plus efficace contre le vol d'identifiants, et celle qu'un assureur cyber demande.
Se connecter sous l'identité d'un autre
Un utilisateur qui signale un problème qu'on ne reproduit pas est le cas quotidien du support. Deux solutions existent : lui demander son mot de passe — ce qui ruine toute politique de sécurité — ou disposer d'un mécanisme d'usurpation tracé.
impersonate_login (version 18.0.1.1.2) permet à un utilisateur habilité de se connecter temporairement sous l'identité d'un autre, sans connaître son mot de passe, avec un journal dédié sous Paramètres ▸ Technique ▸ Journaux de l'usurpation d'identité.
Le journal est la condition de l'acceptabilité du mécanisme : savoir qui s'est connecté sous quelle identité, et quand.
auth_admin_passkey permet à l'administrateur système de se connecter sur n'importe quel compte en saisissant son propre mot de passe à la place de celui du compte visé.
La différence entre les deux est importante : le second ne trace rien au-delà de la connexion elle-même, et confère à un seul compte un pouvoir total. Il répond à un besoin de dépannage d'urgence, pas à un usage courant de support.
user_log_view (LGPL-3) ajoute un bouton sur la fiche utilisateur donnant accès à l'historique de ses connexions. C'est la première chose qu'on regarde après un comportement suspect.
base_user_show_email corrige enfin une confusion du standard : dans les versions récentes, le champ de connexion s'affiche comme un champ de courriel, ce qui mélange login et adresse. Le module les distingue.
Le coffre-fort de secrets
vault (version 18.0.1.0.10, la plus avancée du dépôt) ajoute à Odoo un coffre-fort de secrets — mots de passe, notes, fichiers — chiffré de bout en bout : le chiffrement et le déchiffrement se font dans le navigateur, avec une clé maîtresse propre à chaque coffre.
Il apporte un menu racine Vault avec ses entrées, une boîte de réception et une gestion des droits.
Le chiffrement côté navigateur change la nature du risque : le serveur ne détient jamais les secrets en clair. Une base volée ne livre rien sans la clé maîtresse — ce qu'aucun stockage de mots de passe dans un champ texte ne peut prétendre.
vault_share ajoute le partage ponctuel d'un secret avec une personne sans compte Odoo, par un lien web protégé. Menu sous Vault ▸ Shares.
C'est le besoin réel qui fait circuler des mots de passe par courriel : transmettre un accès à un prestataire, un code à un client. Un lien à usage limité remplace une pièce jointe qui reste dans une boîte pour toujours.
Limites connues
- Imposer le double facteur bloque les connexions jusqu'à configuration : prévoir l'accompagnement, et un chemin de secours pour un utilisateur qui perd son téléphone.
auth_admin_passkeyconfère un pouvoir total à un compte : à réserver au dépannage, avec un mot de passe administrateur traité en conséquence.- L'usurpation d'identité doit être encadrée par les droits : le journal trace, il n'autorise pas. Décider qui en bénéficie.
- Une action faite sous usurpation porte le nom de l'utilisateur usurpé dans les écritures : la piste d'audit métier ne distingue pas, seul le journal d'usurpation le fait.
- La politique de mot de passe s'applique aux nouveaux mots de passe : les mots de passe existants restent, sauf réinitialisation forcée.
- La clé maîtresse du coffre-fort est irrécupérable : sa perte rend les secrets inaccessibles. C'est le prix du chiffrement de bout en bout.
- Un secret partagé par lien circule hors du coffre : limiter la durée de validité et ne pas transmettre le lien par le même canal que le contexte.
Identité technique
Les onze modules viennent du dépôt OCA server-auth, branche 18.0 — 27 modules au total. Neuf sont en AGPL-3, password_security et user_log_view en LGPL-3. Les dépendances : auth_totp et auth_password_policy_signup pour les mots de passe et le double facteur, auth_signup pour l'auto-inscription, mail et web pour les écrans, base_setup pour le coffre-fort.
Voir aussi identité fédérée, clés d'API et jetons pour le reste du dépôt, et droits utilisateurs et sécurité d'accès.
Questions fréquentes
Peut-on imposer une politique de mot de passe dans Odoo ?
Odoo n'impose qu'une longueur minimale globale. password_security définit au niveau de la société la longueur et la composition exigées — minuscules, majuscules, chiffres, caractères spéciaux. C'est ce qu'il faut pouvoir montrer pour une certification, une assurance cyber ou un client donneur d'ordre.
Peut-on rendre le double facteur obligatoire ?
Oui, avec auth_totp_enforce : les utilisateurs doivent configurer une application d'authentification avant de pouvoir se connecter. C'est la mesure la plus efficace contre le vol d'identifiants. Prévoyez l'accompagnement et un chemin de secours pour un utilisateur qui perd son téléphone.
Comment reproduire un problème signalé par un utilisateur sans son mot de passe ?
impersonate_login permet à un utilisateur habilité de se connecter temporairement sous l'identité d'un autre, avec un journal dédié. L'alternative — demander son mot de passe à l'utilisateur — ruine toute politique de sécurité. Attention : une action faite sous usurpation porte le nom de l'usurpé dans les écritures.
Pourquoi un utilisateur n'arrive-t-il pas à se connecter alors que son mot de passe est bon ?
Souvent à cause de la casse du login : une adresse créée avec une majuscule ne permet pas la connexion en minuscules. auth_user_case_insensitive rend le login insensible à la casse. C'est le module qu'on installe après avoir perdu une heure.
Peut-on stocker des mots de passe dans Odoo sans risque ?
Avec vault, oui : un coffre-fort chiffré de bout en bout, le chiffrement se faisant dans le navigateur avec une clé maîtresse propre à chaque coffre. Le serveur ne détient jamais les secrets en clair. Contrepartie : la clé maîtresse est irrécupérable — sa perte rend les secrets inaccessibles.
Se faire accompagner
La sécurité d'une instance Odoo se juge sur trois réponses : la politique de mot de passe, l'obligation du double facteur, et la traçabilité de l'accès au compte d'autrui. Les trois s'installent en une journée, et c'est exactement ce qu'un audit ou un assureur demande.
Nous posons donc ces trois mesures avant d'ouvrir une instance à des utilisateurs externes, et nous remplaçons les mots de passe qui circulent par courriel par un coffre-fort chiffré — en expliquant d'abord que la clé maîtresse ne se récupère pas. Voir les prestations d'Atalios Consulting ou demander un rappel.
Pour aller plus loin
En résumé
Trois questions reviennent à chaque audit d'une instance Odoo : quelle est la politique de mot de passe, le double facteur est-il obligatoire, et qui peut se connecter sous l'identité d'un autre. Le standard répond faiblement aux deux premières et pas du tout à la troisième. Parlons de votre sécurité.
