Pourquoi sortir du modèle classique des mots de passe ?
L’authentification par mot de passe est la norme sur le web, mais elle reste fragile. Même avec un stockage sécurisé (hachage avec sel, Bcrypt, Argon2…), les menaces sont nombreuses : vol de base de données, administrateur indélicat, interception sur un réseau peu sûr, ou encore le Cloud Act qui autorise certains gouvernements à exiger l’accès à des données hébergées dans le cloud.
Chez LetReco, nous avons étudié attentivement le sujet de l’authentification par mot de passe, dans l’optique de générer une clé unique par utilisateur pour chiffrer ses données.
De la donnée au chiffrement
Actuellement, nos travaux portent sur l’identification des éléments de la base de données pouvant être chiffrés ainsi que sur les méthodes permettant de le faire à l’aide d’une clé unique dérivée d’une information propre à chaque utilisateur. Les données chiffrées peuvent être exfiltrées, mais elles restent protégées par un chiffrement symétrique (par exemple AES-CTR ou AES-GCM).
Ce protocole s’appuie principalement sur le mot de passe de l’utilisateur pour la dérivation de la clé.
Le problème des mots de passe
Le mot de passe est, par nature, un secret partagé entre l’utilisateur et le serveur. À chaque connexion, il doit être transmis d’une manière ou d’une autre, ce qui ouvre la porte à des attaques variées :
- Vol de base de données : même hachés, les mots de passe peuvent être attaqués par force brute.
- Administrateurs malveillants : l’hébergeur ou un sous-traitant peut accéder aux données.
- Réseaux compromis : sur un Wi-Fi public ou un proxy douteux, un attaquant peut intercepter les identifiants.
- Lois extraterritoriales : même stockées dans un datacenter européen, les données restent accessibles à certaines juridictions étrangères.
Bref, l’authentification par mot de passe est une faiblesse structurelle. La vraie question devient alors : comment prouver son identité sans jamais transmettre son mot de passe ?
OpenPGP comme solution d’authentification sécurisée
Cryptographie asymétrique et défi-réponse
La réponse se trouve dans la cryptographie asymétrique. Chaque utilisateur dispose d’une paire de clés :
- une clé publique, que l’on peut transmettre librement,
- une clé privée, qui doit rester secrète et protégée par un mot de passe local.
A l’inscription, l’utilisateur génère cette paire de clés. La clé privée est chiffrée avec son mot de passe, puis les deux clés sont envoyées au serveur, mais protégées à leur tour par la clé publique du serveur. Ainsi, la base de données ne contient jamais de secrets exploitables.
Etapes d’authentification avec OpenPGP
A la connexion, le processus repose sur un challenge aléatoire :
- Le serveur génère une chaîne aléatoire et la chiffre avec la clé publique de l’utilisateur.
- L’utilisateur la déchiffre grâce à sa clé privée (protégée localement par son mot de passe).
- Il calcule l’empreinte SHA-256 de cette valeur et la renvoie, chiffrée avec la clé du serveur.
- Le serveur compare avec sa propre version. Si les valeurs concordent, l’authentification est validée.
Le mot de passe ne quitte donc jamais le poste de l’utilisateur : il ne sert qu’à déchiffrer la clé privée.
Mise en œuvre technique
Bibliothèques utilisées (PGPainless, OpenPGP.js)
Côté serveur, une bibliothèque comme PGPainless (Java/Kotlin) facilitent la gestion des clés et du chiffrement OpenPGP.
Côté navigateur, la librairie OpenPGP.js (maintenue par Proton Mail) permet de générer et d’utiliser des clés directement en JavaScript.
Fonctionnement des API
Le protocole repose sur trois API principales :
- /key : pour récupérer la paire de clés stockée, déchiffrée par le serveur,
- /challenge : pour envoyer un défi aléatoire à l’utilisateur,
- /login : pour vérifier la réponse et valider l’authentification.
En pratique, le navigateur génère les clés, les protège avec le mot de passe de l’utilisateur et la clé publique du serveur, puis les enregistre. Lors de la connexion, il déchiffre le challenge, calcule le hash et renvoie la preuve.
Quels avantages pour la sécurité des utilisateurs ?
Ce modèle apporte plusieurs bénéfices :
- Aucun mot de passe transmis ni stocké : aucun secret réutilisable ne circule.
- Résistance au vol de base : une fuite de données ne révèle que des clés chiffrées.
- Indépendance vis-à-vis du cloud : même sous juridiction étrangère, les données restent inexploitables.
- Confidentialité renforcée : l’utilisateur garde le contrôle de sa clé privée.
Limite du modèle : le mot de passe reste un point faible
La principale limite reste le mot de passe qui protège la clé privée. En effet, toute la sécurité repose sur le fait que l’utilisateur soit le seul à pouvoir déchiffrer sa clé grâce à son secret. Si ce mot de passe est faible (ex. trop court, trop simple, réutilisé), un attaquant en possession de la clé chiffrée peut facilement la déchiffrer via des attaques par dictionnaire ou brute force. Dans ce cas, le schéma entier s’effondre, même si les algorithmes de chiffrement utilisés sont robustes.
Renforcer la sécurité : dérivation de clé et authentification multifactorielle
1. Utiliser un mécanisme de KDF
Une piste d’amélioration consiste à renforcer la dérivation de la clé qui protège la clé privée. Au lieu de chiffrer directement la clé avec le mot de passe utilisateur, on applique un mécanisme de KDF (Key Derivation Function), comme PBKDF2, scrypt ou Argon2, avec :
- un sel (valeur aléatoire fournie par le serveur et stockée en clair), pour éviter que deux utilisateurs ayant le même mot de passe aient la même clé chiffrée,
- un facteur de coût (nombre d’itérations, mémoire utilisée, complexité), qui rend les attaques de force brute beaucoup plus coûteuses en temps et en ressources.
Ainsi, même si l’utilisateur choisit un mot de passe imparfait, l’effort nécessaire pour l’attaquer devient exponentiellement plus important.
2. Utiliser une authentification multifactorielle
Recourir à une authentification multifactorielle (ex. mot de passe + code à usage unique ou clé matérielle) permet de limiter l’impact d’un mot de passe compromis.
En résumé, sans mesure de renforcement, le mot de passe demeure le maillon faible d’un protocole, par ailleurs, très robuste. L’introduction d’un sel fourni par le serveur, associée à une fonction de dérivation moderne, et éventuellement complété par un second facteur d’authentification, permettrait de consolider considérablement ce modèle.
Conclusion : vers une authentification plus sûre
OpenPGP permet de réinventer l’authentification web en supprimant la dépendance au mot de passe classique. Le serveur ne valide plus un secret transmis, mais la preuve qu’un utilisateur détient bien sa clé privée.
Ce modèle plus robuste demande un effort d’implémentation. Cette clé pourrait également servir à chiffrer une partie des métadonnées utilisateur directement dans le navigateur. Ces données seraient ensuite stockées de façon sécurisée.
Ce dispositif est encore en phase de recherche et doit être validé avant d’être déployé en production mais ouvre la voie vers un web plus sûr pour ses utilisateurs et plus respectueux de la vie privée.
A propos de l’auteur :
Pierre-Emmanuel Gros, Docteur Ingénieur
Auteur d’articles sur l’innovation et la culture tech, conteur d’expériences et semeur d’idées, j’aime explorer ce qui se joue en coulisses, derrière les lignes de code… et rappeler qu’au fond, toute aventure technologique est d’abord collective.
Articles sur le même thème :
