Le phishing d'identifiants a une finalité économique : alimenter, ou exploiter, une base. L'attaquant collecte pour revendre, ou rejoue ce que d'autres ont collecté. Dans les deux cas, la valeur naît de la concentration. Une architecture décentralisée, où aucune donnée identifiante n'est détenue par l'éditeur et où la biométrie éventuelle est traitée localement sur le terminal, retire cette concentration — et avec elle, une bonne partie de l'intérêt de l'attaque.
Le phishing vise une base, pas une personne
L'échelle d'une campagne le montre : les leurres sont envoyés par lots, les pages de collecte sont louées à la semaine, les résultats sont revendus par paquets. Le raisonnement de l'attaquant est industriel.
Cette industrialisation suppose un actif accumulable. Or, dans une architecture classique, cet actif existe à deux endroits :
- chez l'attaquant, sous forme de lots d'identifiants collectés ;
- chez le fournisseur d'identité, sous forme d'annuaire, d'empreintes de mots de passe, parfois de gabarits biométriques.
Le second est de loin le plus intéressant. Compromettre un service qui détient les identités de milliers d'organisations produit un rendement sans rapport avec une campagne de phishing unitaire.
Ce qu'une architecture centralisée concentre
| Donnée centralisée | Usage légitime | Ce qu'elle vaut pour un attaquant |
|---|---|---|
| Annuaire d'identifiants | rattacher une session à un compte | liste de cibles, base de ciblage |
| Empreintes de mots de passe | vérifier une saisie | brute force hors ligne, jointure avec des fuites |
| Gabarits biométriques | comparer un facteur | donnée non révocable, valeur durable |
| Journaux détaillés d'usage | supervision et conformité | cartographie de l'organisation |
| Jetons de session actifs | continuité de service | accès immédiat, sans authentification |
La ligne biométrique mérite une attention particulière. Contrairement à un mot de passe, une donnée biométrique ne se change pas. Sa compromission est définitive, ce qui explique la vigilance des autorités de protection des données sur ces traitements.
Décentraliser : n'avoir rien à voler
L'approche retenue par HIAsecure repose sur trois choix cohérents entre eux :
- Aucune donnée identifiante détenue par l'éditeur. Il n'existe pas de base centrale à compromettre, donc pas d'actif à revendre.
- Biométrie traitée localement sur le terminal. Le gabarit ne quitte pas l'appareil ; il n'y a ni transfert ni stockage central à protéger.
- Aucun secret réutilisable en circulation. Approche passwordless et IDless : ce qui transite dans le canal éphémère ouvert par le QR code dynamique ne vaut que pour l'échange en cours.
L'effet sur le phishing est double. En amont, la page de collecte n'a rien à collecter, puisque l'utilisateur ne saisit ni identifiant ni mot de passe. En aval, la compromission du fournisseur — le scénario le plus rentable — ne livre pas de base d'identités.
C'est un déplacement de la logique de sécurité : plutôt que de mieux protéger un coffre, on cherche à ne pas constituer le coffre.
Ce que le RGPD en dit
Le règlement général sur la protection des données pose deux principes qui s'appliquent directement.
- La minimisation : ne traiter que les données nécessaires. Une architecture qui n'a pas besoin de détenir d'identité pour authentifier réduit mécaniquement le périmètre de traitement.
- La protection dès la conception : la conformité n'est pas une couche ajoutée après coup mais un choix d'architecture.
Une conséquence pratique souvent négligée : ce qui n'est pas détenu ne peut pas faire l'objet d'une violation de données à notifier. La question du transfert de données biométriques hors de l'Union européenne ne se pose pas davantage si le gabarit ne quitte pas le terminal.
Cette cohérence rejoint les exigences du Cyber Resilience Act (règlement UE 2024/2847) sur la sécurité dès la conception, et facilite les analyses d'impact demandées sur les traitements biométriques.
Souveraineté : un sujet voisin mais distinct
La solution est conçue, développée et hébergée en France, protégée par deux brevets, labellisée Finance Innovation 2025, et la qualification SecNumCloud est en cours. Ces éléments répondent à une question de gouvernance — qui peut accéder aux données, sous quelle juridiction — qu'il ne faut pas confondre avec la question technique traitée ici.
L'articulation est simple : la décentralisation réduit ce qui existe ; l'hébergement souverain détermine qui pourrait y accéder. Le premier point est structurel, le second contractuel et juridique. Les deux se renforcent, aucun ne remplace l'autre.
FAQ
Décentraliser ne complique-t-il pas la conformité ?
L'expérience est plutôt inverse : les analyses d'impact portent sur les données traitées, et il est plus simple de démontrer la conformité d'un traitement local que celle d'une base centralisée avec transferts, durées de conservation et sous-traitants.
Comment gérer les droits et les accès sans base centrale ?
La gestion des droits reste dans votre système d'information : annuaire interne, groupes, habilitations. Ce qui est décentralisé, c'est le facteur d'authentification, pas votre gouvernance des accès.
Que se passe-t-il en cas de perte du terminal ?
Le cas doit être traité au cadrage, comme pour une clé physique ou une application d'authentification. C'est un point à couvrir explicitement, avec le même niveau d'exigence que le parcours nominal.
Cela protège-t-il des attaques visant nos propres serveurs ?
Cela réduit ce qu'une compromission permettrait d'obtenir côté identité. Cela ne remplace ni la segmentation, ni la gestion des vulnérabilités, ni la supervision de votre système d'information.
Aller plus loin : l'authentification cognitive · le 4ᵉ facteur face au phishing · RGPD et authentification · hébergement des données en France