Greboca  

LinuxFr.org : les journaux  -  Comment j'ai (presque) réussi à ne plus retenir de mot de passe pour mes services en ligne

 -  21 janvier - 

Sommaire

Après quelques années d'errance, je suis presque au bout de mon périple pour atteindre l'objectif suivant:

  • Ne plus avoir de mot de passe à retenir
  • Avoir un niveau de sécurité supérieur ou égal au niveau de sécurité offert par un mot de passe seul
  • Avoir un spectre de moyens d'authentification suffisamment large pour pouvoir me connecter depuis différents supports.

Ce journal est donc un retour d'expérience et une description des différents outils que j'ai mis en place pour atteindre l'objectif sus-cité.

Les services que j'héberge et pour lesquels j'ai ca en place sont:

  • Gestionnaire de mots de passe en ligne
  • Nextcloud pour le carnet d'adresse/agenda, le partage de fichiers
  • Divers sites web pseudo statiques mais qu'il ne faut pas rendre publics pour autant
  • Courriel: Rainloop webmail et Postfix/Dovecot

La base: un serveur d'authentification SSO OAuth2/OpenID Connect (OIDC)

C'est le socle de base et celui sur lequel beaucoup de ces services reposent pour authentifier l'utilisateur, et c'est la première étape de l'authentification sans mot de passe.

Les méthodes d'authentification que j'ai mises à ma disposition sont:

  • Le mot de passe à l'ancienne de mon serveur OpenLDAP
  • Le mot de passe à usage unique, les fameux codes à six chiffres HOTP ou TOTP qui changent tout le temps
  • Webauthn avec les yubikeys ou assimilé ou encore la reconnaissance de mon empreinte digital sur mon téléphone android
  • Le certificat TLS
  • Le mot de passe à usage unique, mais envoyé par courriel

Le serveur SSO OAuth2/OpenID Connect que j'utilise (et que je développe mais c'est pas le sujet) se base sur les scope pour définir les niveaux d'autorisation: un utilisateur doit avoir le droit d'utiliser les scopes disponibles pour les services. J'ai donc défini les scopes dont j'ai besoin: mail, cloud, admin, fichiers, etc. Et j'ai assigné les scopes aux utilisateurs selon leurs besoins.

Chaque scope est configuré pour être autorisé si l'utilisateur prouve son identité via un ou deux (voire plus) facteurs d'authentification. Typiquement les scopes non critiques sont accessibles avec une simple session non expirée sur le SSO (niveau 0), les scopes un peu sérieux comme Nextcloud, Icinga ou des rapports générés par des scripts maison nécessitent un facteur d'authentification, enfin les scopes critiques comme le courriel ou le gestionnaire de mot de passe demandent deux facteurs d'authentification.

Gestionnaire de mot de passe en ligne

C'est le seul pour lequel un mot de passe est encore requis pour accéder aux données, car elles sont chiffrées avec le mot de passe maître. Mais l'accès au services est protégé par le SSO OIDC en amont. En ce qui me concerne j'utilise mon gestionnaire maison qui a son plugin OAuth2 mais de ce que j'ai pu voir, keepass et bitwarden par exemple ont des connecteurs OIDC.

Nextcloud

Pour lui il y a au moins un plugin OIDC qui fonctionne bien avec ma config. Puis pour brancher mon agenda et carnet d'adresse ou l'accès webdav, j'utilise des mots de passe d'application qui sont des mots de passe permettant de se connecter aux services nextcloud. Ces mots de passe sont générés automatiquement et doivent être sécurisés quelque part (comme dans le gestionnaire de mot de passe par exemple…)

Apache2 mod_auth_openidc pour tous les services web statiques ou pseudo statiques

Lui c'est le module apache qui sécurise tout sous-domaine ou site que je veux avec OIDC. La configuration est suffisamment fine pour permettre de configurer différemment les sites à sécuriser selon le niveau de sécurité adapté. Ainsi mes flux video de caméra, mes applis toutes pourries que j'ai faites en PHP il y a des années et que j'ai pas envie de changer parce que ca marche, tous les trucs comme ca sont planqués derrière mod_auth_openidc.
Je crois savoir que des plugins similaires existent pour NGINX mais je ne connais pas ce serveur HTTP, si quelqu'un a un retour d'expérience je suis preneur.

Webmail sous Rainloop

Alors lui ca m'a pris un peu plus de temps et d'énergie. À l'origine, je n'avais besoin que de mon mot de passe LDAP pour me connecter au webmail. J'ai regardé si des connecteurs OIDC existent pour Rainloop mais apparemment pas. Ne voulant pas en développer un moi-même, j'ai fini par trouver une solution de contournement à base de mod_auth_openidc décrit plus haut, de master password dans dovecot, et d'un plugin rainloop maison, développé à l'arrache en une journée, et qui combine les deux. Concrètement mod_auth_openidc s'occupe d'authentifier l'utilisateur, une fois que c'est fait il donne au plugin rainloop le login de l'utilisateur connecté via un header HTTP dédié, puis le plugin rainloop connecte rainloop au serveur IMAP avec la combinaison login utilisateur@master/master password.

Postfix/Dovecot

C'est le dernier service pour lequel je me suis débarrassé du mot de passe. Il est branché sur mon annuaire LDAP pour la connexion.
J'ai découvert récemment qu'on peut avoir plusieurs mots de passe pour un même compte LDAP. C'est utilisé notamment par certains systèmes pour stocker les anciens mots de passes et s'assurer que lorsqu'on demande à un utilisateur de changer son mot de passe, il n'utilise pas un ancien déjà utilisé. Mais OpenLDAP ne fait pas de manières si tu as plusieurs mots de passe pour ton compte et que tu utilises l'un ou l'autre pour t'authentifier. Et donc rien ne t'empêche d'avoir ton mot de passe "primaire" qui est un mot de passe que tu peux retenir, puis d'en avoir d'autres qui sont des mots de passes aléatoires et stockés dans ton gestionnaire de mot de passe.

Ainsi mes logiciels de courriel comme thunderbird ou K9-mail utilisent un mot de passe secondaire que je ne connais pas. Autre avantage, si je perds mon téléphone ou ma tablette, je n'ai qu'à changer ou supprimer le mot de passe secondaire compromis.

Il ne doit en rester qu'un

Le mot de passe qu'il reste encore est celui du gestionnaire de mot de passe.
Mais l'avenir est plein de promesses parce qu'il existe plein de solutions comme GnuPG ou une extension appelée hmac secret définie par la FIDO alliance et implémentée par les yubikeys et d'autres. En gros cette extension permet de générer un mot secret et de manière déterministe avec la yubikey en lui donnant un seed. La clé retourne alors un mot de 32 ou 64 octets, impossible à deviner. Ce mot peut alors servir comme mot de passe maître pour son gestionnaire de mot de passe. Cette extension n'est pas encore supportée par les navigateurs mais j'ai l'espoir que ca arrive un jour!

Conclusion

OAuth2 et OpenID connect, c'est cool!

Commentaires : voir le flux Atom ouvrir dans le navigateur

par Babelouest

LinuxFr.org : les journaux

LinuxFr.org : Journaux

Des nouvelles de boost

 -  23 février - 

Bonjour Nal, Je ne fais plus de C++ depuis longtemps, mais je regarde parfois l'actualité de ce langage. Sa meilleure bibliothèque est sortie en (...)


Pétrolette 1.1

 -  23 février - 

Pétrolette est une page d'accueil de lecture d'actualités, libre. Elle est immédiatement utilisable sans inscription avec la même URL dans le (...)


Un CV en ligne

 -  13 février - 

Cela faisait longtemps que ça me dérangeait: Refaire mon CV, cette fois en utilisant HTML/CSS. En utilisant les dernières avancées en HTML5 / CSS3, (...)


Fini l'obligation de compatibilité IPv6 par la loi

 -  6 février - 

Cher nal, Il y a quelques années, on avait parlé (même ici, il me semble) de la loi obligeant les constructeurs à rendre les « équipements terminaux (...)


Adapter les sites web à votre guise avec ViolentMonkey

 -  5 février - 

Lorsqu’on navigue sur la toile, certains sites/applications ne fonctionnent pas toujours comme on le souhaiterait. Pour ma part, l’application en (...)