Chapitre 4 : Identités, mots de passe et contrôle des accès

Accéder au laboratoire pratique et aux trois nouveaux exercices corrigés

Objectifs du chapitre

• Distinguer identification, authentification et autorisation.
• Choisir des protections adaptées aux comptes.
• Organiser l’arrivée, le changement de rôle et le départ.

1. Trois questions différentes

L’identification annonce une identité, par exemple un nom de compte. L’authentification vérifie une preuve associée à cette identité. L’autorisation décide ensuite ce qu’elle peut faire. Un utilisateur correctement connecté peut donc être refusé lorsqu’il demande une fonction réservée à l’administration. Se connecter ne signifie pas disposer de tous les droits.

À GeniusCampus, un étudiant lit ses propres notes, un enseignant saisit les notes des groupes qui lui sont attribués et le secrétariat gère les inscriptions. Le serveur contrôle ces permissions pour chaque demande. Cacher un bouton dans la page ne suffit pas : une demande peut être envoyée sans utiliser le bouton.

Un compte individuel facilite l’attribution des actions. Un compte partagé complique le départ d’une personne et l’analyse des journaux : on sait quel compte a agi, mais pas nécessairement qui l’utilisait. Pour les processus automatiques, on crée des comptes de service distincts, limités à leur tâche et gérés par un responsable.

2. Un mot de passe unique et gérable

Le mot de passe doit être difficile à deviner et différent pour chaque service. Un gestionnaire peut générer et conserver des secrets longs sans exiger leur mémorisation. Sa propre protection mérite une attention particulière : secret principal robuste, MFA si disponible, appareils de confiance et procédure de récupération préparée.

Réutiliser un secret transforme une fuite sur un site en risque pour plusieurs autres comptes. Une modification cosmétique du même mot de passe ne crée pas une véritable séparation. Pour la récupération, vérifiez l’adresse de secours et protégez-la aussi : elle peut servir à réinitialiser d’autres comptes. Les codes de récupération doivent être conservés dans un emplacement protégé, accessible lors d’une perte de téléphone.

Côté application, on ne stocke pas les mots de passe en clair ni sous un chiffrement réversible destiné à les relire. On utilise une fonction de hachage de mot de passe adaptée, avec un sel propre à chaque mot de passe et des paramètres de coût appropriés. Le chapitre 5 expliquera pourquoi une empreinte SHA-256 seule n’est pas le bon outil pour cette tâche.

3. MFA : plusieurs facteurs, des protections différentes

L’authentification multifacteur combine des catégories de preuves : quelque chose que l’on connaît, que l’on possède ou que l’on est. Deux secrets mémorisés ne sont pas deux catégories indépendantes. Un mot de passe plus une application d’authentification apporte une couche supplémentaire ; les méthodes ne résistent cependant pas toutes aux mêmes attaques.

Les passkeys reposent sur des clés cryptographiques et une vérification liée au service ; elles évitent de saisir un secret réutilisable sur une fausse page. La biométrie sert souvent à déverrouiller localement l’utilisation de la clé. Le service ne reçoit pas pour autant une copie de votre empreinte digitale. Le stockage ou la synchronisation des clés dépend du dispositif choisi.

Une protection de connexion ne règle pas tous les risques : une session déjà volée peut rester utilisable, un appareil compromis peut agir pendant la session et un droit excessif permet toujours trop d’actions. Il faut donc considérer toute la durée de vie de l’accès.

4. Moindre privilège et séparation des responsabilités

Le moindre privilège attribue uniquement les droits nécessaires, pour la durée utile. Il limite les conséquences d’une erreur et d’une compromission. Le rôle de gestionnaire des inscriptions ne devrait pas permettre de désactiver les sauvegardes. Les opérations sensibles peuvent demander une approbation distincte, par exemple la validation d’un remboursement.

Construisez une matrice simple : en ligne les rôles, en colonne les ressources et actions. Séparez lire, créer, modifier, supprimer et administrer. Pour chaque permission, demandez un besoin précis. Une permission permanente donnée « au cas où » devient souvent une permission oubliée. Les accès temporaires doivent avoir une date de fin et être révoqués automatiquement lorsque cela est possible.

5. Sessions et cycle de vie des comptes

Après connexion, le service conserve une session ou remet un jeton. Cet élément est une capacité d’accès : il doit être protégé en transport et sur le poste. La déconnexion, l’expiration et la révocation doivent être prises en compte. Un changement de mot de passe ne supprime pas forcément toutes les sessions ; le comportement dépend du service.

À l’arrivée d’une personne, validez son identité, son rôle et le responsable de ses accès. Lors d’un changement de fonction, retirez les anciens droits autant que vous ajoutez les nouveaux. Au départ, révoquez comptes, sessions et accès aux groupes ; organisez le transfert des dossiers sans divulguer les secrets. Contrôlez régulièrement les comptes dormants et les comptes de service.

Une revue d’accès doit produire des décisions : droits conservés avec justification, droits retirés et anomalies à corriger. Le résultat se mesure par l’état réel des permissions, pas uniquement par le nombre de personnes ayant reçu un formulaire.

Exercices et corrigés

Essayez de répondre avant de déplier les corrigés. Les situations et données sont fictives.

Sources officielles et approfondissements

Repères consultés le 14 octobre 2026. Les cas GeniusCampus et les schémas sont des exemples pédagogiques originaux.

• OWASP : Authentification
• OWASP : Stockage des mots de passe
• OWASP : Sécurité des passkeys
• CISA : MFA

Laboratoire 4 : Tester les autorisations avec deux identités

Objectif : Vérifier les permissions sur une ressource, y compris les refus, avec une matrice reproductible. Durée indicative : 45 minutes.

L’authentification établit une identité ; l’autorisation décide ce que cette identité peut faire sur une ressource. Un identifiant de dossier difficile à deviner ne remplace pas une décision d’accès. Dans notre scénario, Amina possède le dossier 101 et Boris le dossier 202.

Le programme fourni simule une session déjà vérifiée. Il refuse par défaut les accès anonymes, les ressources absentes et celles d’un autre propriétaire. Cette petite politique n’inclut ni délégation ni rôle administrateur ; toute extension devra ajouter des cas de test explicites.

Manipulations guidées

1. Télécharger et extraire l’archive du cours dans un dossier de travail. Avec Python 3.10 ou ultérieur, lancer la commande acces ci-dessous.
2. Avant de lire le résultat, écrire les réponses attendues pour Amina→101, Amina→202, Boris→202, anonyme→101 et Amina→999. Le programme teste exactement ces cinq situations.
3. Ouvrir atelier.py et repérer la vérification du propriétaire avant la restitution du texte. Observer que le simple fait de connaître 202 ne donne aucun droit dessus.
4. Dans WebGoat, rechercher la leçon sur les références directes à des objets, souvent Insecure Direct Object References. Suivre uniquement les étapes affichées sur les objets de cette leçon ; utiliser son aide si les paramètres diffèrent selon la version.
5. Rédiger le correctif attendu : déduire l’utilisateur d’une session vérifiée, restreindre la recherche au périmètre autorisé et ajouter les tests de refus au même titre que les tests de réussite.

python atelier.py --atelier acces

Résultats attendus et preuves à conserver

Résultat : cinq tests ; propre dossier autorisé, dossier d’autrui refusé, anonyme refusé, inexistant refusé. Dans le rapport WebGoat, décrire la cause et le contrôle correctif plutôt que recopier un simple indicateur de réussite.

Limites de la démonstration

Ce programme est un modèle de décision, pas un serveur ni un système de connexion. Un test unitaire ne prouve pas que les routes réelles de l’application utilisent toutes cette politique.

Télécharger les ateliers Python complets, le journal fictif et le modèle de rapport · Mode d’emploi et code complet

Trois exercices d’application corrigés

1. Éviter un faux correctif

Remplacer 101 par un UUID aléatoire corrige-t-il l’accès au dossier d’autrui ?

Voir le corrigé 1

Non. Cela réduit certaines possibilités de deviner un identifiant, mais une fuite ou un partage peut toujours le révéler. Le serveur doit vérifier le droit sur chaque ressource demandée.

2. Tester une révocation

Une délégation a été retirée. Quel test ajouter ?

Voir le corrigé 2

Rejouer une requête avec l’ancien compte délégué et vérifier le refus après révocation, y compris avec une session encore ouverte selon la politique de l’application. Il faut préciser quand les changements de droits prennent effet.

3. Prévenir une fuite annexe

Pourquoi notre modèle renvoie-t-il None pour absent et interdit ?

Voir le corrigé 3

Il évite de donner au demandeur une distinction triviale sur l’existence de la ressource. Une API réelle choisira une politique de réponse cohérente, tout en gardant une journalisation interne utile et sans contenu sensible.

Références du laboratoire

• Contrôle des autorisations OWASP
• WebGoat

Complément original PandaCodeur, cas NKILItech fictif. Les interfaces de WebGoat peuvent évoluer : relever la version et le titre de la leçon suivie.