Chiffrement et sécurité

Le chiffrement est souvent pris comme une solution à tous les problèmes de sécurité. Si
le procédé n’amène aucune vulnérabilité, il nous parait bon de rappeler quelques principes
afin que l’outil soit utilisé à bon escient.

• Chiffrement et hachage

Il existe au moins trois procédés qu’on désigne communément par le terme « chiffre-
ment » : le chiffrement avec clé unique, le chiffrement à clé privée et clé publique, et le
hachage.

• Hachage

Cette dernière méthode est en réalité du chiffrement selon la définition la plus stricte : la
donnée est brouillée pour la rendre illisible. Personne ne peut la relire par la suite, pas
même celui qui a opéré la conversion la première fois. On parle aussi de chiffrement à
sens unique, pour montrer qu’il est impossible de décoder le résultat. Du fait qu’il n’y a
pas besoin qu’une donnée soit décodable, les procédés de hachage peuvent se permettre
d’avoir un résultat d’une longueur fixe. Ainsi, une donnée de 650 Mo aura un résultat de
32 caractères après hachage par la méthode MD5.
On peut considérer le procédé de hachage comme l’aboutissement de la sécurité puisque
nul n’a de méthode de décodage.

• Chiffrement avec clé

Les deux autres méthodes diffèrent uniquement par le système de clé. Dans la première,
il existe une clé unique, qui sert aussi bien à coder qu’à décoder. C’est le procédé utilisé
quand celui qui crypte et décrypte est la même personne, ou deux personnes partageant
les mêmes droits.
Le système à clé privée permet, lui, de séparer la personne pouvant chiffrer les données
de celle qui les décrypte. Ainsi, si je me réserve une clé de décryptage privée et que je
diffuse une clé de chiffrement publique correspondante, tout le monde pourra chiffrer des
documents, mais je serai le seul à pouvoir les relire. C’est par exemple le procédé utilisé
pour les signatures (dans ce cas, c’est le chiffrement qui est privé et le décryptage qui est
public).
La sûreté d’un chiffrement à clés dépend de deux critères : la longueur de la clé et sa
divulgation. Plus une clé est importante, plus il sera long de décoder les données sans
l’avoir. À partir d’une certaine taille, la durée de décodage pour quelqu’un qui n’a pas la
clé se chiffre en siècles ; on peut donc considérer que ce n’est pas un point faible.
Le réel problème de ces chiffrements est la sécurité de la clé elle-même. Il est très impor-
tant de se souvenir que vos données cryptées ont une sécurité limitée par celle de la clé
elle-même. Ceci implique un concept très simple : si vous stockez la clé au même endroit
que vos données, il sera inutile de faire un chiffrement car celui qui accédera aux données
pourra aussi lire la clé et donc les décoder. On dit que la sécurité d’un système est celle
de son maillon le plus faible.

• Chiffrement et mots de passe

Les mots de passe sont les données qui sont en premier soumises à chiffrement. Ne pas
les laisser en clair est d’une grande importance. Le chiffrement empêche les failles de
divulgation. Il nous reste ensuite à choisir si on utilise un hachage ou un système décodable.
Sécurité
De nombreux applicatifs utilisent des procédés décodables pour les mots de passe. Nous
vous déconseillons fortement un tel système.
En effet, si quelqu’un accède aux mots de passe, il est tout à fait possible qu’il puisse
accéder aussi à vos clés de codage. Vos mots de passe ne sont alors potentiellement
pas en sécurité et, à la première vulnérabilité trouvée, ils risquent d’être divulgués.
Le hachage n’a pas ce défaut et doit donc être préféré. Les systèmes d’exploitation
actuels utilisent d’ailleurs tous ce type de chiffrement pour leurs mots de passe, prenez
exemple.
La raison qui pousse souvent les développeurs à choisir la mauvaise solution est la possi-
bilité de rendre son mot de passe à un utilisateur s’il l’a oublié. Ce n’est en fait pas néces-
saire puisqu’il suffit d’en calculer un nouveau et de le lui donner lors de la procédure de
récupération. Il ne peut de toute façon pas préférer l’ancien puisqu’il l’a oublié. À lui de
le changer si le nouveau ne lui convient pas.
Il est de plus important de ne jamais redonner un ancien mot de passe en clair (même
dans une procédure de récupération) parce que la plupart des gens utilisent un unique
mot de passe pour toutes leurs ressources. Certains même utilisent leur numéro de carte
bancaire. Ils ne vous pardonneraient pas d’avoir donné ce mot de passe à un ami ou un
voisin qui a utilisé l’ordinateur personnel et qui a lancé une procédure de récupération en
profitant de la boîte aux lettres électronique.

• Mot de passe crypté dans un cookie

Il est relativement fréquent de voir des applications envoyant deux cookies : l’identifiant
de l’utilisateur et le mot de passe. Elles peuvent ainsi vérifier l’authentification à chaque
accès. Ces applicatifs cryptent le mot de passe en pensant qu’ainsi personne ne pourra le
voir et donc le réutiliser pour accéder à un compte frauduleusement.
C’est une mauvaise réflexion et un effet pervers des possibilités de chiffrement : elles
donnent un sentiment de sécurité. En effet, l’attaquant n’a pas besoin de connaître le mot
de passe pour avoir accès au compte : il lui suffit de noter la chaîne cryptée et de recréer
chez lui un cookie identique. Le mot de passe crypté est le bon et l’attaquant passe les
barrières de vérification.
Dans une telle méthode, on peut considérer que le mot de passe est en réalité la chaîne
cryptée et que la procédure d’authentification par formulaire n’est qu’une fonction de
conversion d’un mot mnémotechnique en mot de passe. Il y a donc bien suivant cette
logique un mot de passe en clair dans le cookie. Le chiffrement n’a amené aucune sécurité,
juste une impression.

Extrait de "PHP 5 avancé 4ieme edition"