43
Les différents volets de la protection du SI
Chapitre 2
http://2003.jres.org/actes/paper.116.pdf) et par Pascal Aubry et ses collègues
(Pascal Aubry, Julien Marchal, et Vincent Mathieu. « Single Sign-On Open Source avec
CAS ». 2003. http://2003.jres.org/actes/paper.139.pdf).
Mettre en œuvre et exploiter un tel système apporte un confort indéniable, mais cela
a un coût : l’investissement éventuel pour une solution du marché, les compétences
requises pour la mise en œuvre et l’exploitation de tous les jours, et enfin, l’adaptation
des applications « Web » au produit retenu. De l’avis même de ceux qui ont déployé
de telles solutions, le plus difficile est l’adaptation des applications au système de SSO
retenu.
Le bon vieux mot de passe
En cette année 2006, le procédé d’authentification le plus utilisé est sûrement
encore, de loin, et malgré ses faiblesses bien connues, le couple identifiant–
mot de passe (login–password). Rappelons-en brièvement le principe, en prenant
l’exemple d’un système Unix (ou Linux, qui, rappelons-le, n’est qu’une variété
d’Unix).
Sous Unix, la création du compte d’un utilisateur crée une entrée dans le fichier
/etc/passwd. Ce fichier contient une entrée par utilisateur, chaque entrée comporte plusieurs champs séparés les uns des autres par le caractère : ; les champs
sont :
• le nom d’utilisateur, ou identifiant, qui est une chaîne de caractères qui identifie de façon unique cet utilisateur ; cet identifiant est aussi appelé nom de
login ;
• la représentation chiffrée du mot de passe de l’utilisateur ; nous verrons d’ici
peu qu’en fait cette représentation chiffrée est conservée ailleurs que dans le
fichier /etc/passwd, pour des raisons de sécurité ;
• le numéro d’identification (uid) de l’utilisateur ;
• le numéro de groupe (gid) de l’utilisateur ;
• le vrai nom de l’utilisateur ;
• son répertoire d’accueil ;
• son programme d’accueil (shell).
Le fonctionnement d’Unix exige que le fichier /etc/passwd soit accessible en
lecture par tout le monde : cela ouvrait à des malveillants la possibilité de récupérer les mots de passe chiffrés des utilisateurs, puis d’essayer de les « casser »
Les différents volets de la protection du SI
Chapitre 2
http://2003.jres.org/actes/paper.116.pdf) et par Pascal Aubry et ses collègues
(Pascal Aubry, Julien Marchal, et Vincent Mathieu. « Single Sign-On Open Source avec
CAS ». 2003. http://2003.jres.org/actes/paper.139.pdf).
Mettre en œuvre et exploiter un tel système apporte un confort indéniable, mais cela
a un coût : l’investissement éventuel pour une solution du marché, les compétences
requises pour la mise en œuvre et l’exploitation de tous les jours, et enfin, l’adaptation
des applications « Web » au produit retenu. De l’avis même de ceux qui ont déployé
de telles solutions, le plus difficile est l’adaptation des applications au système de SSO
retenu.
Le bon vieux mot de passe
En cette année 2006, le procédé d’authentification le plus utilisé est sûrement
encore, de loin, et malgré ses faiblesses bien connues, le couple identifiant–
mot de passe (login–password). Rappelons-en brièvement le principe, en prenant
l’exemple d’un système Unix (ou Linux, qui, rappelons-le, n’est qu’une variété
d’Unix).
Sous Unix, la création du compte d’un utilisateur crée une entrée dans le fichier
/etc/passwd. Ce fichier contient une entrée par utilisateur, chaque entrée comporte plusieurs champs séparés les uns des autres par le caractère : ; les champs
sont :
• le nom d’utilisateur, ou identifiant, qui est une chaîne de caractères qui identifie de façon unique cet utilisateur ; cet identifiant est aussi appelé nom de
login ;
• la représentation chiffrée du mot de passe de l’utilisateur ; nous verrons d’ici
peu qu’en fait cette représentation chiffrée est conservée ailleurs que dans le
fichier /etc/passwd, pour des raisons de sécurité ;
• le numéro d’identification (uid) de l’utilisateur ;
• le numéro de groupe (gid) de l’utilisateur ;
• le vrai nom de l’utilisateur ;
• son répertoire d’accueil ;
• son programme d’accueil (shell).
Le fonctionnement d’Unix exige que le fichier /etc/passwd soit accessible en
lecture par tout le monde : cela ouvrait à des malveillants la possibilité de récupérer les mots de passe chiffrés des utilisateurs, puis d’essayer de les « casser »