300.
Si c’est le nom d’un film sorti récemment, c’est aussi le nombre de comptes que j’ai ouverts depuis mes débuts sur Internet. Prenant rapidement conscience de cette inflation, j’ai pris la précaution de bien définir ma stratégie de sécurité. Plusieurs niveaux de mot de passe en fonction de l’importance du service et de la réputation du site, inscription systématique de mes comptes existants dans un fichier central, authentifications successives pour accéder aux mots de passe de haut niveau… m’ont permis de structurer ma démarche de manière à toujours connaître mes logins et mots de passe pour les innombrables services auxquels j’ai souscrits.
Depuis mes tentatives fructueuses de piratage des comptes hotmails de certains amis (en les informant bien entendu de la situation) en 2003, en répondant simplement aux questions “personnelles” posées en cas d’oubli du mot de passe (exemple : nom de jeune fille de ma grand-mère, de mon chien ou couleur préférée), facilement résolvables avec un peu de business intelligence, j’ai décidé de boycotter systématiquement ce que je considère comme d’énormes failles de sécurité.
Je comprends bien que, la majorité des gens étant épicuriens lorsqu’ils créent des comptes en ligne (j’entends par là qu’ils ne se soucient pas de se souvenir encore de ses identifiants quelques mois plus tard, choisissant même parfois un mot de passe et un login différent à chaque fois), il convient de mettre en place un système simple de récupération du mot de passe (ou de création d’un nouveau mot de passe dans le cas d’hotmail). Mais honnêtement, n’est-ce pas là jouer avec le feu ?
L’affaire Société Générale a mis en évidence l’importance des droits d’accès à certaines applications. L’usurpation d’identité, rendue possible par leur politique de sécurité vraisemblablement défaillante ainsi que décrite ici par des spécialistes d’informatique bancaire, peut facilement provoquer des cataclysmes sans commune mesure avec les fraudes commises en nom propre. Inutile d’aller chercher plus loin les coupables ou, comme le proclamait Daniel Bouton, du “Génie” à passer des opérations falsifiées. Si la situation dans certaines banques est telle que présentée par les consultants en SI bancaire contribuant au blog de Duo&Co, je me vois facilemement faire la même chose que Jérôme Kerviel après quelques temps au back office (histoire d’être sûr de bien maîtriser tous les rouages), et à condition tout de même d’être dépourvu de conscience professionnelle et de sens moral. Loin de moi l’idée de polémiquer sur la culpabilité et la responsabilité de qui que ce soit, je profite en fait de ce fait économique pour arriver sur une opportunité d’innovation et de business.
Si la sécurité informatique est si critique, ce que reconnaissent déjà bon nombre de banques, d’autres acteurs des secteurs sensibles, et bien sûr les particuliers, alors plutôt que de persister sur une voie incompatible avec nos capacités humaines (mémorisation à long terme d’identifiants et de mots de passe), je pense qu’il qu’y a un marché énorme à développer une solution d’authentification qui rompe avec les méthodes actuelles et qui néanmoins soit rétrocompatible (sans quoi elle est probablement vouée à l’échec).
Voilà de quoi augmenter la productivité de manière conséquente, d’apporter une plus grande confiance dans les systèmes informatiques, et donc de générer d’humbles milliards d’euros de profits, au profit de milliards d’êtres humains. Les idées c’est bien, le concret, c’est mieux. Comment donc trouver cette solution révolutionnaire ? Je n’ai pas encore suffisamment creusé la question pour produire un business plan, mais je vois déjà quelques pistes de recherche à suivre pour atteindre l’objectif ci-dessus (un système d’authentification unique, sécurisé, portable, personnel, rétrocompatible, aux fonctionnalités transparentes, et géré par une entité indépendante).
Schématiquement, le système se présenterait de la sorte :
{Application}
Services Internet, contrôles d’accès physiques, antidémarreurs…
{/Application}
\/ /\
{Système central d’authentification}
Se positionne comme couche logicielle intermédiaire entre l’application et l’utilisateur.
1. Récupère l’événement de requête d’authentification soumis par l’application, la reconnaît (pour une fiabilité maximum et éviter le phishing par exemple, il reconnaît le certificat de sécurité signé par une autorité de confiance), établit en conséquence le niveau de sécurité minimum et maximum requis
2. Vérifie s’il dispose déjà d’une authentification valide (une authentification peut être valide pour un certain nombre de niveaux de sécurité, une certaine période de temps, un certain nombre d’application, un certain nombre de fois, selon certains critères externes comme la présence dans l’entreprise d’un collaborateur)
3. Déclenche un événement de sollicitation de l’utilisateur, le cas échéant
{/Système central d’authentification}
\/ /\
{Utilisateur}
Personne physique, Entité informatique (programme, macro, webservice…), Ensemble d’utilisateurs
Peut choisir différents niveaux d’authentification, lorsque sollicité par le SCA
0. Utilisateur déjà authentifié
1. Mot de passe bateau pour une sécurité faible, comme un code pin de téléphone
2. Mot de passe pour plusieurs niveaux de sécurité successifs, le cas échéant
3. Relevé d’identification biométrique
4. Puce matérielle contenant des éléments uniques d’authentification, non usurpables et non spoofables (cf. technologies de transmission exploitant les propriétés quantiques, algorithme de modification du cryptage à chaque lecture des informations…)
Les événements de niveau supérieur permettent d’accéder aux niveaux inférieurs. Par exemple une identification biométrique permet de s’authentifier pour n’importe quel service normalement activable par mot de passe.
{/Utilisateur}
On ne se passera donc pas des mots de passe, mais ceux-ci seront gérés par le SCA et seront composés de plusieurs centaines de bits, éventuellement moins pour des raisons de rétrocompatibilité, mais en tous les cas invisible pour l’utilisateur qui pourra utiliser des méthodes d’authentification synthéthiques (un mot de passe ou un badgeage lui permettra ainsi d’accéder à différents sites qui recevront chacun un mot de passe différent généré par le SCA, limitant ainsi les dégats en cas de mot de passe non crypté dans la base d’un récipiendaire peu scrupuleux, ce qui m’est arrivé une fois et m’a valu d’avoir mon compte eBay usurpé, et surtout d’une complexité suffisante pour déjouer les attaques par force brute (donc des centaines de bits que l’utilisateur n’est généralement pas capable de retenir). De cette manière, la rétrocompatibilité serait assurée.
Dans l’étude de l’état de l’art, on s’intéressera notamment au SSO (single sign-on), qui a déjà fait l’objet de nombreuses recherches et développements, académiques ou commerciales, et présentent de nombreuses ramifications dont certaines seront sans doutes plus pertinentes que d’autres.
Dans un prochain billet j’essaierai de détailler comment déployer ce type de système (serveur accessible par Internet ? Clef USB ? Puce intégrée dans l’architecture matérielle du périphérique ?) Si vous avez des idées, n’hésitez pas à les proposer en commentaire pour que nous puissions en discuter. La finalité, vous l’aurez compris, est qu’en cas d’aboutissement à une solution réellement novatrice, efficace, facile à mettre en oeuvre, et fiable, nous puissions passer à l’étape supérieure. Il y a là sans aucun doute un vaste marché (peut-être plus grand même que celui qui a fait la fortune de Mark Shuttleworth), la seule question est de savoir si nous saurons remporter le défi.
2 commentaires