Authentification, état de l’art

L’autre jour, quelqu’un m’a demandé quelle est la bonne méthode pour échanger des informations d’authentification entre un client mobile et un service web. Question simple aux réponses multiples, évidentes pour certaines et complexe pour d’autres.

Vu que le sujet peut intéresser, je me propose d’entamer ici un état de l’art de l’authentification, ou du moins des méthodes d’authentifications que je connais. Si vous pensez que j’ai omis quelque chose, les commentaires sont là pour ça ! J’intègrerais les commentaires les mieux rédigés en ajout de l’article pour leur donner une meilleure visibilité.

Pour commencer, tâchons de définir ce qu’est l’authentification et dans quel contexte cela se déroule.

L’authentification, c’est l’action qui nous permet de certifier à l’ordinateur de qui nous somme. Cette action est nécessaire lorsqu’on souhaite garantir des accès spécifiques en fonction des personnes. Le réceptionniste d’une société n’accède pas aux mêmes ressources qu’un comptable. Cette notion d’autorisation d’accès à des ressources (comme les données comptables) nécessite d’avoir une base d’identités des utilisateurs et une liste de contrôle d’accès. L’authentification étant l’élément de contrainte qui va permettre de valider que la personne derrière le clavier est bien qui elle prétend être.

La base d’identité des utilisateurs de l’entreprise est généralement publique, ou au moins accessible aux employées et aux services. Elle est stockée dans une base de données (accessible par LDAP par exemple) et permet aux utilisateurs et aux ordinateurs de savoir comment est définie une personne (nom, prénom, e-mail, numéro de téléphone, méthodes d’authentification). Le point important est que dans la base d’identités de l’entreprise, les utilisateurs sont définis et un lien est fait vers les méthodes disponibles pour authentifier la personne au besoin, mais cette base n’a pas comme vocation initiale la validation de l’utilisateur qui prétend être quelqu’un.

À l’autre bout de la chaine, la liste de contrôle d’accès est ce qui permet à un ordinateur de savoir si la personne dûment authentifiée a le droit d’accéder à une ressource. Cela peut être simplement le droit d’accès à un service comme le VPN, où nous somme dans du oui / non, ou des droits plus poussés comme l’accès à un document (.pages, wiki…) qui lui peut être en lecture seule pour l’utilisateur ou en lecture et écriture par exemple.

Notre authentification se trouve donc entre les deux, c’est le point sensible de cette chaine. Si notre service d’authentification peut être dupé, les contrôles d’accès ne sont plus garantis. Pire, un service mal conçu peut mettre en danger la confidentialité du facteur d’authentification de l’utilisateur, permettant ainsi à un éventuel attaquant d’usurper une identité.

Alors, quelles sont les méthodes d’authentifications qui ont existé ou existent encore ? Pour les cas les plus intéressants, quels sont les détails d’implémentation à connaitre ?

Méthodes d’authentification

Authentification par adresse IP

Certains protocoles anciens comme le NFS ont basé leur mécanisme d’authentification en fonction de l’adresse IP de l’émetteur. Ainsi, si une machine avec une IP autorisée se présente au serveur en indiquant que son utilisateur est Alice, le serveur fera confiance à l’information.

Autant le dire, cette méthode d’authentification désuète n’est plus en vigueur aujourd’hui. Elle avait du sens à une époque où l’économie de cycle était de rigueur et où l’environnement était sous contrôle, mais aujourd’hui ce n’est plus le cas.

Authentification par secret partagé

L’idée de ce type d’authentification n’est pas d’authentifier un utilisateur, mais un groupe d’utilisateurs disposants des mêmes droits. Ils se verront remettre un secret commun, chacun disposant de la même information à utiliser pour s’authentifier auprès d’un service.

D’un niveau de sécurité primaire, cette option présente l’avantage de la simplicité de configuration, mais ne permet pas de savoir précisément qui est derrière la machine. De plus, lorsque la confidentialité du secret est compromise, l’ensemble des machines s’en servant est à reconfigurer, ce qui nécessite donc un transfert de la connaissance du nouveau secret à un certain nombre d’utilisateurs, transfert devant lui même être sécurisé…

Aujourd’hui, on trouve ce type d’authentification principalement à deux endroits : les clefs WPA des réseaux WiFi pour particulier, chaque ordinateur rentre la même clef pour accéder au réseau et les clefs de chiffrement IPSec pour les VPN de type L2TP/IPSec, le secret partagé sert à ouvrir un canal sécurisé entre le client et son serveur puis le L2TP prends la relève pour l’authentification de l’utilisateur.

Authentification simple facteur, ce que l’utilisateur sait

Le cas le plus courant, un utilisateur dispose d’un identifiant unique (comme une adresse e-mail par exemple) et avec, un mot de passe. Pour authentifier l’utilisateur, il faut donc que soit entré le bon identifiant avec le bon mot de passe. L’identifiant étant généralement connu de tous (ou au moins facilement déterminable), la seule chose secrète est le mot de passe, propre à chaque utilisateur.

Ce type d’authentification, dit simple facteur puisqu’un seul élément est secret, est le plus répandu aujourd’hui. Vous vous en servez pour accéder à vos e-mails, payer sur l’App Store, vous connecter à des réseaux WiFi WPA Entreprise, ou même accéder à votre machine.

Cette option permet de savoir précisément qui est la personne derrière l’ordinateur puisque son identifiant est unique et lui seul est censé connaitre son mot de passe. En cas de compromission du facteur d’authentification, le propriétaire d’un compte pourra demander une remise à zéro de son mot de passe pour garantir de nouveau l’intégrité de son identité, sans impacter les autres utilisateurs.

La faille de cette méthode réside dans le fait que seule la connaissance d’un secret est mise en jeu pour valider l’identité de l’utilisateur. Il n’y a rien d’unique dans une connaissance. Un attaquant correctement entrainé subtilisant le mot de passe d’un utilisateur tâchera de rester le plus discret possible pour effectuer son larcin, de sorte que l’utilisateur ne se doute pas que son identité a été usurpée.

Authentification à double facteur

L’authentification à double facteur fut créée pour pallier le problème de la seule connaissance comme critère d’authentification. Ce principe demande à l’utilisateur de disposer de deux éléments pour valider son identité : quelque chose qu’il connait, un mot de passe, et quelque chose qu’il possède.

Ce second facteur d’authentification étant physique, unique, réputée incopiable et inutilisable seul, il devient beaucoup plus simple pour l’utilisateur de savoir si son identité est attaquée ou non.

Ce second facteur peut prendre différentes formes, les plus courantes sont : le générateur de nombre, dit « token OTP » (One Time Password) et la carte à puce.

Dans le cas du code OTP, l’utilisateur cherchant à s’authentifier devra entrer deux code, son code personnel ainsi que le code fourni par son générateur de nombre et valable pour un temps limité.

L’autre cas, celui de la carte à puce, vous le connaissez déjà, c’est celui de votre carte à puce de paiement. Pour valider à la banque que ce soit bien vous qui avez fait une transaction, il faut votre carte ainsi que votre code personnel, le code PIN. Quelque chose que vous avez et quelque chose que vous connaissez.

À noter que dans le milieu bancaire, on trouve des niveaux de sécurité assez disparate au niveau des systèmes de payement :

  • la piste magnétique sans signature du porteur de carte (au péage) ;
  • la piste magnétique avec signature de carte (aux USA) ;
  • l’empreinte physique de la carte (les numéros en relief) avec la signature du porteur de carte (dans les avions ou au fin fond du Canada si un jour vous allez faire un tour de traîneau à chien…) ;
  • la puce avec contact qui demande votre code PIN pour être lue ;
  • la puce NFC sans aucune signature ni code.

Le cas de l’authentification à double facteur présente peu de faille fonctionnelle. Si l’utilisateur perd sont élément physique d’authentification il le verra et pourra le signaler à son responsable, s’il évente son mot de passe, c’est gênant, mais moins critique si tous les services nécessitent une authentification double facteur.

Un troisième facteur ?

Section revue suite aux commentaires de marsu78

Un troisième type de facteur d’authentification existe au côté de ce que l’on sait et ce que l’on possède : ce que l’on est.

La biométrie est un facteur d’authentification supplémentaire qui doit être utilisé en complément des facteurs précédents, en aucun cas seuls si l’on souhaite de la sécurité et non du faire-valoir.

Dans la plupart des cas, la biométrie va faire appel à vos empreintes digitales ou votre iris dans certains cas. Le net intérêt de cet outil est de garantir qu’en temps normal, la personne derrière la machine est bien la personne attendue et non le patron qui aurait laissé son badge d’accès à sa secrétaire.

Cependant, la biométrie qui marche bien est assez chère, elle analysera des choses difficilement volables à l’insu de l’utilisateur. La forme des veines de la main plutôt qu’une simple empreinte digitale, le dessin de la rétine de l’œil… Les systèmes avancés ayant pour but de vérifier que c’est bien un organe vivant qu’il analyse et non une photo.

De plus, il ne faut pas oublier qu’en biométrie, pas de révocation possible ! On ne peut que faire confiance aux capteurs utilisés, si un attaquant réussit à trouver le moyen de duper les lecteurs avec un enregistrement du facteur physique d’authentification, vous ne pourrez pas simplement révoquer un certificat.

En terme de sécurité donc, je dirais que la biométrie est un facteur de sécurité intérieure, impossible pour les employer de se passer leur badge d’accès. Par contre, la sécurité face aux attaques est moins intéressante qu’une carte à puce.

Authentification forte

On appelle authentification forte la combinaison de deux facteurs ou plus, carte à puce et code PIN, mot de passe et empreinte des veines, etc.

Détails d’implémentation

Je vais m’attarder ici aux implémentations possibles de l’authentification à simple facteur. C’est la plus répandue et différentes variations existent.

Les règles de bonne implémentation

Ne jamais communiquer un mot de passe en clair sur un réseau

Les protocoles comme HTTP, FTP, SMTP, POP et IMAP sont des protocoles originellement non chiffrés, lorsque vous échangez vos informations d’authentification, les données transitent en clair sur le réseau et si la méthode d’authentification fournie par le serveur n’est pas de type « challenge », votre mot de passe sera accessible au premier venu écoutant votre communication.

Il convient donc de toujours chiffrer ses communications (et le premier qui me parle d’encryption des communications me fait une dissertation sur le fonctionnement de RSA !). Le chiffrement peut intervenir de différente manière, la plus répandue est l’ajout d’une couche TLS (nom du standard créé à partir de SSL 3.1), cela permet l’ouverture d’un canal de communication chiffré entre le poste client et son serveur, le tout basé sur un système de certificat de sécurité et de confiance accordé à des tiers (renseigné vous sur les PKI et ses failles, ce n’est pas l’objet du jour). Bien que plus répandue, TLS n’est pas la seule option, la seconde bien connue est IPSec, tout comme TLS, cette boite à outils permet de chiffrer n’importe quel protocole ne supportant pas nativement le chiffrement, et contrairement à TLS, IPSec permet de travailler avec des secrets partagés entre le serveur et un ou plusieurs clients en plus des certificats de sécurité.

Les protocoles HTTP, FTP, SMTP, POP et IMAP disposent chacun d’une version sur TLS, je vous recommande très fortement de ne vous servir que de ces versions lorsque votre fournisseur vous le propose.

Le VPN L2TP sur IPSec est un exemple de service basé sur IPSec, le service « Back To My Mac » d’Apple dans iCloud en est un autre.

Ne jamais stocker les mots de passe des utilisateurs

Lorsque vous fournissez un service nécessitant l’authentification des utilisateurs, vous allez avoir besoin d’un élément de comparaison pour savoir si le mot de passe fourni par l’utilisateur est bien celui entré dans le système. Cependant, pour la sécurité et la confidentialité des données de votre utilisateur, vous ne devez jamais stocker le mot de passe de l’utilisateur sous une forme réversible. Cela entend l’interdiction formelle de stocker un mot de passe en clair, en base64 ou encore un mot de passe chiffré avec un mot de passe maitre.

La seule et unique option autorisée pour le stockage d’un mot de passe et l’usage d’une empreinte de mot de passe. Le passage dans un algorithme mathématique non réversible autrement appelé fonction de hachage. Les plus connues sont le md5, le SHA, SHA-1, SHA-256 et ce ne sont pas les seules.

Le but de cette règle et d’éviter la compromission des mots de passe des utilisateurs en cas de vol de votre base de données (comme c’est arrivé à bien des entreprises ces derniers temps).

Cependant, les fonctions de hachage ayant un certain succès aujourd’hui, il existe des bases sur Internet, appelé Rainbow Tables, contenant une multitude d’empreintes associées au mot de passe originel. Ainsi quelqu’un en possession d’une empreinte volée peut être en mesure de retrouver le mot de passe d’origine.

Pour contrer cela, il est de bon ton d’utiliser un sel, une chaine de caractère généré aléatoirement à l’enregistrement du mot de passe et stocké avec. Le sel est utilisé comme vecteur de modification du mot de passe avant l’utilisation d’une fonction de hachage. Le mot de passe 1234 avec le sel abc deviendrait ainsi abc1234. Le système doit garder une trace en clair du sel pour le rajouter au mot de passe fourni pour l’authentification et faire de nouveau son opération de hache. Si le mot de passe est bon, associé au sel d’origine, la comparaison d’empreinte sera positive.

L’envoi d’un mot de passe depuis le client

Certains peuvent se demander comment envoyer le mot de passe d’un utilisateur depuis un poste client vers le serveur en toute sécurité ?

La réponse simple est le TLS ou IPsec. Pour garantir la confidentialité et l’authenticité de la communication. Cependant, un excès de zèle est possible si l’on souhaite garantir la confidentialité du mot de passe de l’utilisateur même en cas de compromission des couches de chiffrement.

Ainsi, il peut être décidé que le mot de passe de l’utilisateur sera haché une première fois avant l’envoi sur le serveur. Si quelqu’un a réussi à déchiffrer la communication, il pourra toujours s’authentifier par rejeu du mot de passe haché, mais il n’aura pas directement le mot de passe en clair. Et à condition d’avoir une méthode de salage constante, il est également possible de se prémunir des Rainbow Tables depuis le client. Cela présente également l’avantage de vous dédouaner de tout problème côté serveur, en évitant la réception d’un mot de passe en clair à l’origine. Tout cela n’empêchant pas l’application des recommandations précédentes côté serveur.

Garder le mot de passe hors du réseau ?

Cette dernière explication me mène tout droit à la notion essentielle de la méthode d’authentification la plus fiable actuellement : Kerberos. L’objectif primaire est simple, ne jamais laisser transiter le mot de passe de l’utilisateur sur le réseau.

L’idée de Kerberos est de mettre en scène une série de clefs partagées entre un serveur central, les utilisateurs et les services. L’authentification de chacun des membres étant garantie par la confidentialité des clefs et la confiance accordée au serveur central.

Lorsqu’un utilisateur cherche à s’authentifier à un service, il devra d’abord demander à un serveur central une clef temporaire pour l’opération. Pour avoir cette clef temporaire d’accès à un service, il devra en premier lieu posséder une clef temporaire d’échange avec le serveur central.

Pour se faire, il devra envoyer un message au serveur central contenant l’identifiant revendiqué ainsi que la date, le tout chiffré avec une empreinte de son mot de passe et, avec le paquet chiffré, se trouve une nouvelle fois, mais en clair, l’identifiant demandé.

Le serveur recevant le paquet, il va regarder l’identifiant, chercher l’empreinte de mot de passe disponible dans sa base et déchiffrer le paquet. Si le déchiffrement est réussi et si le paquet a été émis il y a moins de 5 min, l’authentification est réussie et le serveur central renvoie à son client un paquet spécifique, contenant une clef de chiffrement temporaire ainsi qu’un bloc de donnée que lui seul peut lire contenant de nouveau l’identifiant, la clef et la date d’expiration de la clef. Ces deux éléments sont envoyés à la machine cliente en étant chiffrés avec l’empreinte du mot de passe de l’utilisateur.

Le client recevant le paquet, il le déchiffre et met de côté la clef temporaire et la charge utile d’authentification qu’il ne peut lire.

Souhaitant accéder à un service e-mail ou autre, le client utilisant Kerberos va d’abord contacter le serveur central en lui demandant une clef temporaire pour le service spécifié. Pour se faire, il va chiffrer sa demande avec la clef temporaire fournie par le serveur et envoyer le paquet chiffré avec la charge utile d’authentification précédemment reçue.

Le serveur disposant lui aussi de clef de chiffrement avec le service souhaité, il va générer une clef temporaire et la chiffrer deux fois, une première fois avec la clef de session partagée avec l’utilisateur et une seconde avec la clef partagée avec le service demandé puis, il va envoyer les deux informations au client.

Le client recevant ces deux informations va déchiffrer la partie le concernant et stocker sa clef temporaire destinée au service demander, il va également s’en servir pour chiffrer un paquet de demandes d’accès au service souhaité et l’envoyer avec le paquet à destination du serveur de service fourni par le serveur central.

Lorsque le serveur de service reçoit ces informations, il commence par déchiffrer la partie le concernant pour récupérer la clef de session créée pour l’utilisateur, puis, avec cette clef, il déchiffrera la demande de l’utilisateur et le processus d’authentification sera terminé.

Ce système, assez complexe, est le plus sécurisé connu à ce jour. À aucun moment le mot de passe de l’utilisateur n’a circulé sur le réseau, uniquement des paquets chiffrés avec un dérivé du mot de passe le temps de générer des clefs temporaires.

Fait originellement pour l’authentification sécurisée, sa conception apporte au passage une capacité de chiffrement des communications et d’authentification unique, l’utilisateur ne doit rentrer son mot de passe qu’une seule fois, pour générer la clef temporaire entre lui et le serveur central.

OK, Kerberos c’est bien, mais il n’y a pas plus simple ?

Kerberos fut conçu par le MIT pour répondre aux besoins d’authentification au sein d’une entreprise. Si vous fournissez un seul service, il n’est peut-être pas nécessaire d’implémenter tout le mécanisme dans votre logiciel. Une version allégée pourrait fusionner le serveur de services et le serveur central.

Lorsqu’un utilisateur cherche à s’authentifier à votre service web, il envoie uniquement un paquet contenant son identité ainsi que l’heure, chiffrée avec une empreinte du mot de passe de l’utilisateur, puis il place a coté une nouvelle dois l’identifiant demandé en clair.

La chose arrivant au serveur, vous reprenez l’empreinte stockée pour l’utilisateur, si le paquet est déchiffré correctement, c’est que l’utilisateur est justement authentifié. À vous de voir si vous souhaitez ensuite générer des clefs de session temporaire pour chiffrer la communication.

Les petits trucs

Les challenges

Certains systèmes d’authentification à mot de passe proposent un niveau de complexité supplémentaire dans le but d’éviter le rejeu, c’est le cas de l’authentification DIGEST en HTTP. L’idée est de demander à la machine cliente de s’authentifier en prenant en compte une chaine de caractère aléatoire fournie par le serveur.

Le client recevant ce challenge devra renvoyer au serveur une empreinte de la chaine constituée par le mot de passe ou d’un dérivé et le challenge, cela permet d’avoir une empreinte d’authentification différente à chaque fois et évite ainsi le rejeu des paquets d’authentification.

OAuth, OpenID…

OpenID et OAuth adressent tous deux le même objectif, fournir à des services tiers une méthode d’authentification sur un annuaire privé. L’idée est simple, si je souhaite proposer à une entreprise un service de comptabilité en ligne, je peux souhaiter faire ça proprement et utiliser la base d’identité existante de mon client pour que les utilisateurs n’aient pas un nouveau mot de passe à retenir.

Pour cela, je vais choisir, en fonction de mes convictions politiques et de l’âge du capitaine, OpenID ou OAuth qui vont tout deux me permettre de rediriger l’authentification des utilisateurs sur un portail interne de la société qui me renverra en cas d’authentification réussie une clef unique me permettant d’authentifier l’utilisateur chez moi et de revenir périodiquement valider auprès du serveur interne de mon client que l’identification est toujours valable.

Voilà, si j’ai omis quelque chose, n’hésitez pas à me le signaler !

8 réflexions au sujet de « Authentification, état de l’art »

    • L’idée du hash à l’envois est simplement pour éviter une circulation de tout type du mot de passe en clair. Pour le serveur, ce qui arrive c’est le mot de passe utilisateur, qu’il va saler et hasher comme au normalement.

      Simplement la valeur qu’il aura eu n’est pas le vrai mot de passe de l’utilisateur mais un dérivé.

      Ça évite lorsqu’un utilisateur accepte un certificat invalide que le vrai mot de passe soit compromis.

  1. Sympa ces petits cours que tu nous ponds en ce moment !

    Quelques précisions :
    – On parle d’authentification forte à partir de 2 facteurs d’authentification (quels qu’ils soient)
    – La biométrie a un avantage : on est certain que c’est bien la bonne personne en face (et pas le patron qui a filé à sa secrétaire sa carte à puce et son code PIN)
    – Un petit chapitre d’introduction à la fédération d’identité ? (ok, c’est à la limite du sujet de l’article)

    • Je crois que je n’ai tout simplement pas employé le terme authentification forte non ? L’idée était justement de laisser le champ libre la dessus.

      Effectivement, je n’avais pas pensé à l’avantage de la biométrie en terme de détournement des utilisateurs, je ne vois que le mauvais coté du fait que c’est cher pour que ça ne soit pas spoofable par une simple image. Des retour là dessus ?

      Coté fédération d’identité, si tu as de l’expérience sur le sujet et que tu veux faire un article, je veux bien le publier ici. Pour le moment mes tentatives de OpenID se sont soldé par un échec, les solutions qui j’ai trouvé sont inutilisables sortie de leur contexte…

      • Non, tu n’as pas employé le terme. Mais comme il est couramment employé dans le métier, ça me paraissait utile de le préciser.

        Je n’ai personnellement jamais touché à la biométrie, mes des collègues oui. J’ai cru comprendre que les solutions s’améliorent et que les prix baissent. Par contre on m’avait clairement indiqué (il y a quelques années, les choses ont pu évoluer depuis) que le seul vrai avantage était de s’assurer de la présence effective de la personne en face.

        Non, je ne connais de la fédération d’identité que les concepts de base.
        Un exemple concret d’application (quand ça marche) est mon.service-public.fr qui permet ensuite de passer sur d’autres sites d’administration (CAF…) sans se réauthentifier.

        • J’ai réintégré tes commentaires à l’article.

          Concernant la biométrie c’est effectivement le seul vrai intérêt, l’authenticité de la personne en usage normal. En terme de sécurité vis à vis d’un vol d’identité, je trouve ça moins fort qu’une carte à puce (pour la révocation, on peut repasser ^^)

Laisser un commentaire