Réduction du niveau de menu

2024-02-26 18:54:24 +00:00 · 2024-02-26 18:54:24 +00:00 · d62b44e2bc
commit d62b44e2bc
parent f40f4977e2
1 changed files with 33 additions and 34 deletions
--- a/posts/cours-id-authn.md
+++ b/posts/cours-id-authn.md
@ -20,9 +20,7 @@ tags:
 lang: fr
 ---

-# Identité et méthodes d'authentification
-
-## Définition des termes
+# Définition des termes

 Un **acteur** ou **sujet** (*subject*) est un membre actif d'un système d'information exerçant une **action** ou une **activité** sur les membres de ce système. Les acteurs peuvent être des personnes ou des processus.

@ -34,13 +32,13 @@ L'**authentification** est le procédé par lequel un acteur prouve son identit

 L'**autorisation** encadre les activités que l'acteur peut entreprendre sur les objets du système d'information.

-## Identité
+# Identité

-### Portée
+## Portée

 La **portée** d'une identité peut être vue comme son périmètre d'action, c'est-à-dire l'espace dans lequel cette identité a du sens (un peu comme une carte d'identité française n'a pas de valeur au Royaume-Uni). Nous allons en envisager plusieurs : locale, centrale, répartie et décentralisée.

-#### De la portée locale
+### De la portée locale

 Une identité peut être **locale** à un système d'information, ou même à un sous-ensemble d'un système d'information. C'est le cas des **comptes locaux** gérés par nsswitch et le module PAM (Pluggable Authentication Modules)[^PAM] `pam_unix` sur une machine Linux. Les identités locales présentent l'avantage d'être autonomes et toujours disponibles, sans être tributaires de la disponibilité de système tiers. La contrepartie est une difficulté notable à maintenir la cohérence des identités sur les différents systèmes, chacun ayant la même *force de vérité* dans leur périmètre.

@ -75,7 +73,7 @@ flowchart LR
 ```


-#### Des référentiels d'identités centraux
+### Des référentiels d'identités centraux

 La portée d'une identité peut être plus large et une identité peut être connue de plusieurs membres d'un système d'information ; on parle alors d'une identité **centralisée**. 

@ -124,7 +122,7 @@ flowchart LR
  ldapsrv --> db
 ```

-#### Des référentiels d'identités répartis
+### Des référentiels d'identités répartis

 Un référentiel d'identités peut être amené à voir sa taille grandir, que ce soit de manière organique ou lors d'acquisitions de sociétés. Dans ce dernier cas, en particulier, il existe alors plusieurs référentiels d'identités concurrents, qu'il pourrait être intéressant de fusionner. Cette opération est sensible, et difficile.

@ -222,7 +220,7 @@ flowchart LR
  ldapsrv2 --> db2
 ```

-#### Des référentiels d'identités décentralisés
+### Des référentiels d'identités décentralisés

 Les référentiels d'identités répartis ont du sens lorsque l'ensemble des référentiels d'identités sont sous le contrôle d'entités juridiques ayant un rapport de confiance ou ayant la volonté d'apparaitre sous une même bannière. La confiance et l'unification s'effectuent par les gestionnaires des référentiels d'identités ; *le consommateur de ces référentiels n'a aucun pouvoir de décision*.

@ -283,7 +281,7 @@ flowchart LR
  linkStyle 1,2 color:red;
 ```

-### Sur la séparation des référentiels d'identité
+## Sur la séparation des référentiels d'identité

 Le référentiel SecNumCloud[^SNC][^snclocalisationqte] prévoit que les comptes d'administration d'un prestataire de cloud qualifié soient gérés "à l'aide d'outils et d'annuaires distincts de ceux utilisés pour la gestion des comptes utilisateurs placés sous la responsabilité du commanditaire (c'est-à-dire de ses clients)".

@ -292,7 +290,7 @@ Le référentiel SecNumCloud[^SNC][^snclocalisationqte] prévoit que les comptes

 Exigée pour les prestataires de cloud qualifiés, cette séparation des référentiels d'identités afin d'en dédier un pour les comptes d'administration du système d'information semble une bonne pratique de sécurité à adopter en général. Elle permet, en effet, de limiter la surface d'attaque des services manipulant notamment les clés cryptographiques utilisées pour l’administration (clés TLS, clés de signature des “jetons d’accès”, etc.).

-## Authentification
+# Authentification

 L’authentification est un sujet complexe, que ce cours va aborder sous de nombreux angles :

@ -303,7 +301,7 @@ L’authentification est un sujet complexe, que ce cours va aborder sous de nomb
 * les **risques de la réutilisation** de moyens de preuve d'identité ;
 * le **stockage** des éléments authentifiants.

-### Aspects juridiques de l'authentification
+## Aspects juridiques de l'authentification

 L'authentification est un sujet traité à la fois par les juridictions nationales et internationales. Un défaut de conformité à ces dispositions peut entrainer des sanctions parfois sévères. 

@ -340,7 +338,7 @@ Le respect des règles et "recommandations" listées dans ces documents est requ

 [^RGS]: https://cyber.gouv.fr/le-referentiel-general-de-securite-version-20-les-documents

-### Les facteurs d'authentification
+## Les facteurs d'authentification

 Le règlement d'exécution (UE) 2015/1502 définit trois types de facteurs d'authentification.
 	
@ -352,7 +350,7 @@ Le règlement d'exécution (UE) 2015/1502 définit trois types de facteurs d'aut

 Cette définition est également présente dans le code monétaire et financier, ainsi que dans le RGS (à une subtilité prête ; voir le chapitre concernant la force de l'authentification).

-#### Les facteurs d'authentification basés sur la possession
+### Les facteurs d'authentification basés sur la possession

 D'après le guide de l'ANSSI "Recommandations relatives à l'authentification multifacteur et aux mots de passe" :

@ -363,14 +361,14 @@ Le même guide spécifie également :
 > Un facteur de possession doit être un équipement attribué à un unique utilisateur. Afin de garantir la sécurité apportée par ce facteur, il est essentiel que des moyens de protection et de détection contre les tentatives de reproduction ou de falsification du facteur soient mis en place. Un facteur de possession peut être une carte à puce contenant une clé privée, une carte SIM d’un téléphone mobile comportant des données d’identification, ou un dispositif permettant de générer des codes à usage unique (OTP).


-#### Les facteurs d'authentification basés sur la connaissance
+### Les facteurs d'authentification basés sur la connaissance

 Les facteurs d'authentification basés sur la connaissance reposent sur le fait que l'acteur connaisse un secret. En général, il s'agit d'un **mot de passe**, d'une **phrase de passe**, ou d'un **code PIN (*Personal Identification Number*)**.

 Les **jetons d'authentification** (*authentication token* ou *bearer token*) sont un cas intéressant lorsqu'on parle d'authentification multifacteurs. En effet, ces derniers sont soit des valeurs aléatoires assimilables à des clés cryptographiques symétriques, soit des informations structurées et signées et encodées sous la forme d'une chaine de caractères (par exemple en base64). La simple preuve de la connaissance d'un tel jeton est suffisante pour prouver son identité ; cela laisserait donc entendre qu'il s'agisse d'un facteur d'authentification basé sur la connaissance. Pourtant, il s'agit d'un secret non mémorisable par un humain, ce qui entrerait aussi dans certaines des définitions d'un facteur d'authentification basé sur la possession.


-#### Les facteurs d'authentification inhérents
+### Les facteurs d'authentification inhérents

 L'authentification par des facteurs inhérents est une question épineuse en France. En effet, l'ANSSI a longtemps été une pourfendeuse de la biométrie, indiquant que les facteurs inhérents sont au mieux un facteur d'identification et non d'authentification, ou dans le pire des cas une méthode de déverrouillage pour un autre facteur d'authentification. Cette position a dû être partiellement révisée par la contrainte européenne, au travers du règlement eiDAS et la directive DSP2.

@ -385,7 +383,7 @@ Ensuite, les facteurs inhérents ne sont **pas renouvelables** à l'infini ; si
 [^credstuff]: https://www.cloudflare.com/fr-fr/learning/bots/what-is-credential-stuffing/
 [^biohack]: https://jankrissler.blogspot.com/2016/09/hacker-fakes-german-ministers.html

-#### Remarques concernant l'authentification des processus
+### Remarques concernant l'authentification des processus

 La notion de facteurs d'authentification n'a réellement de sens que pour les utilisateurs. Par définition, un processus ne peut posséder un équipement ou mettre en œuvre un attribut physique. 

@ -404,7 +402,7 @@ Il convient cependant de noter que strictement parlant, il pourrait être consid
 [^HSM]: https://en.wikipedia.org/wiki/Hardware_security_module
 [^KMS]: https://www.lemagit.fr/conseil/Key-Management-System-KMS-une-pierre-angulaire-du-chiffrement

-### La force de l'authentification
+## La force de l'authentification

 Le règlement eiDAS définit trois niveaux de garantie : **faible**, **substantiel** et **élevé**.

@ -437,13 +435,13 @@ En outre, l'expression "authentification forte" est de plus en plus galvaudée p

 Il convient donc de toujours **s'assurer de la définition de l'authentification forte** qu'un interlocuteur ou une interlocutrice utilise.

-### Les mécanismes d'authentification
+## Les mécanismes d'authentification

 Cette section du cours n'a pas vocation à être exhaustive. La liste qui suit n'est même pas forcément représentative des mécanismes les plus fréquemment utilisés. Elle permet cependant de couvrir un large éventail de techniques afin d'apporter une culture générale sur le sujet.

 Dans cette section, on utilisera le terme de prouveur pour désigner celui qui tente de prouver son identité ; c'est-à-dire de s'authentifier. Le terme vérificateur désigne celui qui vérifie les preuves d'identité. On peut penser de prime abord que seul l'utilisateur tente de prouver son identité auprès d'un serveur pour accéder à son compte. La réalité est que presque toujours, le serveur prouve également son identité auprès du logiciel mis en œuvre par l'utilisateur ou l'utilisatrice. En conséquence, il serait incorrect de considérer que prouveur et utilisateurs sont synonymes dans le chapitre qui suit.

-#### La preuve par divulgation
+### La preuve par divulgation

 La méthode la plus universelle pour prouver son identité est de divulguer un secret au vérificateur. Ce dernier peut alors comparer ce secret à celui attendu pour cet acteur. S'ils correspondent, alors la preuve est faite. C'est le cas typique de l'utilisateur qui envoie son mot de passe tel quel à un serveur. C'est également le cas pour les codes temporels (TOTP), les codes *Transaction Authentification Number (TAN)* (par exemple, des codes reçus par email ou par SMS et à reproduire auprès du vérificateur), les codes PIN, les jetons d'authentification, etc. C'est également le cas des "identifiants de session", comme les "cookies de session", qui ne sont ni plus ni moins que des jetons d'authentification présentés à chacune des requêtes.

@ -483,13 +481,13 @@ sequenceDiagram
  end
 ```

-#### La preuve par défi
+### La preuve par défi

 Les mécanismes d'authentification reposant sur des défis sont des procédés interactifs : un dialogue se met en place entre le vérificateur et le prouveur. Ce dialogue permet de s'accorder sur une valeur aléatoire, parfois appelée **nonce**. Cet accord peut être unilatéral : le vérificateur décide arbitrairement de cette valeur. Ensuite le prouveur effectue une opération cryptographique sur cette valeur aléatoire et envoie le résultat au vérificateur. Ce dernier vérifie alors la preuve à l'aide d'un élément en sa possession et qui est associé à l'identité supposée du prouveur.

 Il existe de nombreux protocoles reposant sur les défis ; certains ont de très bonnes propriétés de sécurité ; d'autres sont catastrophiquement mauvais, et même pires que la preuve par divulgation !

-##### RFC 7616 : HTTP Digest
+#### RFC 7616 : HTTP Digest

 La RFC 7616[^rfcdigest] décrit le mécanisme d'authentification HTTP Digest.

@ -544,7 +542,7 @@ sequenceDiagram
  end
 ```

-##### La signature électronique
+#### La signature électronique

 La signature électronique est une méthode d'authentification très courante. Elle est notamment employée par les protocoles SSH, TLS, et IPsec.

@ -615,7 +613,8 @@ sequenceDiagram
    victor ->> peggy:"Je ne crois pas, non"
  end
 ```
-#### La preuve par déchiffrement
+
+### La preuve par déchiffrement

 La preuve par déchiffrement repose sur la capacité du prouveur à démontrer la connaissance d'un secret arbitraire qui lui a été transmis sous une forme chiffrée par le vérificateur. 

@ -761,7 +760,7 @@ sequenceDiagram

 La preuve d'identité par déchiffrement est plus complexe à mettre en œuvre et ses assurances de sécurité sont plus faibles que d'autres types de preuves, notamment comme implémentée dans TLS 1.3. En conséquence, cette preuve est de moins en moins utilisée. Il s'agit d'un bel exemple du développement itératif et de l'amélioration continue des protocoles cryptographiques ; beaucoup de ceux conçus dans les années 90 sont désormais écartés au profit de constructions plus récentes et robustes.

-##### La preuve avec divulgation nulle de connaissance
+#### La preuve avec divulgation nulle de connaissance

 Les mécanismes reposant sur la preuve par divulgation nulle de connaissance (ou sans apport de connaissance) sont assez divers. Le principe commun de tous ces mécanismes est que l'élément secret utilisé par le prouveur n'est à aucun moment divulgué au vérificateur. Ce dernier reçoit la preuve de la connaissance de ce secret, sans obtenir d'information sur le secret !

@ -809,7 +808,7 @@ sequenceDiagram
  end
 ```

-##### La preuve par calculs répartis
+#### La preuve par calculs répartis

 Par proximité avec les protocoles à divulgation nulle de connaissance, il peut être fait mention également de ceux utilisant des fonctions pseudo-aléatoires oublieuses (*oblivious pseudo-random functions (OPRF)* ; il n'existe pas de traduction faisant autorité).

@ -863,16 +862,16 @@ sequenceDiagram
  end
 ```

-### Du stockage des éléments authentifiants
+## Du stockage des éléments authentifiants

 Pour effectuer l'authentification d'un acteur, le vérificateur a besoin d'avoir accès à une information permettant de vérifier la preuve d'identité. De la nature de la preuve dépend la nature de l'information à stocker côté vérificateur. Le cas le plus typique est celui du mot de passe, mais il en existe d'autres, comme les secrets permettant la génération des codes temporels (TOTP), des clés publiques ou des certificats.


-#### Protocoles reposant sur de la cryptographie à clé publique
+### Protocoles reposant sur de la cryptographie à clé publique

 Dans le cas où la preuve consiste en une signature numérique vérifiable avec la cryptographie à clé publique, tous les éléments stockés par le vérificateur sont publics par nature ; la seule protection requise est en intégrité, afin de prévenir un attaquant de remplacer les éléments de vérification par les siens. La confidentialité peut néanmoins être un sujet, en particulier si les clés sont réutilisées auprès de plusieurs vérificateurs (voir la section de ce cours dédiée à la réutilisation des moyens de preuve).

-#### Protocole reposant sur de la cryptographie à clé secrète
+### Protocole reposant sur de la cryptographie à clé secrète

 La cryptographie à clé secrète ou cryptographie symétrique effectue les opérations de vérification avec la même clé que celle qui a permis de créer la preuve. En conséquence, cette clé doit être stockée en clair, sous une forme réversible, ou dans un équipement de sécurité (par exemple, un TPM, un HSM, ou une carte à puce) permettant sa mise en œuvre sans risque d'extraction, copie ou falsification. Ce dernier cas est malheureusement trop rare.

@ -882,7 +881,7 @@ C'est le cas notamment des protocoles utilisant les mécanismes de preuve de typ

 [^rfctotp]: https://www.rfc-editor.org/rfc/rfc6238.html

-#### Protocoles reposant sur les mots de passe
+### Protocoles reposant sur les mots de passe

 Le stockage des mots de passe par le vérificateur est sans doute la problématique liée à l'authentification la plus connue, du fait de la quasi-omniprésence des mots de passe comme méthode d'authentification, des méthodes de stockage qui ont largement évolué à mesure que les techniques d'attaque se sont sophistiquées, et des sanctions de la CNIL qui ont été mises en avant sur ces sujets.

@ -918,7 +917,7 @@ La fonction de dérivation de mots de passe à l'état de l'art est argon2id. Ce

 Il existe d'autres fonctions, moins efficaces que argon2id, qui peuvent être mentionnées. Par ordre décroissant de protection, il peut être cité : scrypt, bcrypt, PBKDF2. Toutes ces fonctions, comme argon2id, intègrent toutes par conception un diversificateur pour contrer les précalculs.

-### De la réutilisation des moyens de prouver son identité
+## De la réutilisation des moyens de prouver son identité

 L'utilisation d'un même moyen permettant de prouver son identité n'est pas recommandée. Les conséquences sont cependant assez diverses en fonction du moyen.

@ -936,7 +935,7 @@ D'autre part, un attaquant ou une attaquante ayant pu obtenir la liste des clés

 [^tracessh]: https://words.filippo.io/dispatches/whoami-updated/

-### Considérations de sécurité relatives aux moyens de prouver son identité
+## Considérations de sécurité relatives aux moyens de prouver son identité

 Fort de toutes les connaissances évoquées dans ce chapitre, il peut sembler difficile de faire le bon choix. Quelles normes, référentiels ou lois s'appliquent ? Quelle force ? Quel protocole ? Faut-il utiliser plusieurs facteurs ? Si oui, lesquels ? Quelles assurances le stockage du vérificateur doit-il fournir ? Quelles assurances le protocole de transport réseau doit-il fournir ? Faut-il utiliser des facteurs physiques comme des cartes à puce ? Si oui, à quel cout ? Qu'utiliser quand on accède à une API ?

@ -1009,13 +1008,13 @@ sequenceDiagram
  end
 ```

-## Remerciements
+# Remerciements

 Je tiens à remercier mes relecteurs et relectrices pour leurs contributions à ce cours. Un merci tout spécial à [@karl@infosec.exchange](https://infosec.exchange/@karl) et [@bortzmeyer@mastodon.gougere.fr](https://mastodon.gougere.fr/@bortzmeyer) pour leurs suggestions d'amélioration nombreuses et détaillées.

 Le contenu de ce cours ne saurait les engager.

-## Licence
+# Licence

 Ce cours est publié sous licence [CC-BY](https://creativecommons.org/licenses/by/4.0/).