L'une des clés de voûte assurant la sécurité de vos données personnelles sur Internet, c'est le mot de passe. En effet, ce précieux sésame permet de protéger l'accès aux comptes que vous possédez sur divers sites Internet. Pourtant, les mesures de sécurité mises en œuvre pour les protéger sont rarement très poussées.

Après vous avoir expliqué le principe de fonctionnement de l'identification par mot de passe, je vais essayer de vous montrer comment les sites peuvent s'y prendre pour protéger vos mots de passe, en vous présentant quelques méthodes utilisées par les développeurs. Après cela, je vous donnerai quelques conseils pour essayer de mieux protéger vos mots de passe de votre côté, puis vous montrerai que leur sécurité est malgré tout très difficile à assurer.

Principe de fonctionnement de l'identification par mot de passe

Avant de parler de la sécurité des mots de passe, il faut comprendre le fonctionnement de ces derniers. Lorsque vous vous inscrivez sur un site comme Net-Actuality, le script d'inscription ajoute, dans une base de données, une ligne contenant le pseudo, l'adresse email ainsi que le mot de passe que vous avez choisis. Par la suite, lorsque vous tentez de vous connecter, le script de connexion compare les informations que vous avez saisies dans le formulaire de connexion à celles qui sont présentes dans la base de données du site. Si elles coïncident, il vous connecte à votre compte ; dans le cas contraire, il vous refuse la connexion.

Imaginons que je crée un compte sur Net-Actuality avec le pseudo « Florian » et le mot de passe « azerty ». Si je renseigne, sur le formulaire de connexion, le pseudo « Florian », le script va chercher cette occurrence dans la base de données et la trouver. Pour passer l'étape de la connexion, il va maintenant comparer le mot de passe que j'ai saisi à celui stocké dans la base de données, puis me connecter à mon compte si le résultat est positif.

Gauche : schéma du processus d'inscription / Droite : schéma du processus de connexion.

Pour prendre un exemple plus concret, c'est comme à la banque. Si vous essayez d'ouvrir un coffre fort, vous avez à la fois besoin du numéro du coffre et d'une clé ou d'un code lui étant associé. La mauvaise clé utilisée avec le bon coffre ou la bonne clé utilisé avec le mauvais coffre se traduisant fatalement par un échec.

Comment les sites essaient de protéger les mots de passe ou pas

Cryptage des mots de passe

C'est lors de l'enregistrement dans la base de données que la confidentialité de vos données est assurée ou pas. En effet, lorsque le script d'enregistrement enregistre vos informations dans la base de données, y compris votre mot de passe, il a deux choix : le stocker tel quel ou le crypter.

L'intérêt du cryptage ? Il est très simple : imaginez qu'un individu malintentionné arrivait à accéder la base de données d'un site sur lequel vous êtes inscrit. Si votre mot de passe n'y était pas crypté, le pirate pourrait alors le récupérer et s'en servir sur l'ensemble des sites sur lesquels vous êtes inscrits avec le même mot de passe. Comment trouverait-il les sites sur lesquels vous êtes inscrit me demandez-vous dubitatif ? Une petite recherche sur Google, avec votre email ou votre pseudo, et le tour est joué ! Pire encore, supposons que vous vous soyez inscrit avec votre adresse Gmail et que vous ayez utilisé le même mot de passe aux deux endroits : le pirate pourrait alors accéder à votre compte mail en toute impunité.

Le but, vous l'aurez donc compris, c'est d'augmenter la sécurité de votre mot de passe. Pour cela, avant d'enregistrer celui-ci dans la base de données, le script va le crypter. Ainsi, si un utilisateur arrivait à accéder à la base de données, il n'obtiendrait pas votre mot de passe en clair, mais de manière cryptée : inutilisable donc, en apparence.

Schéma présentant le processus de stockage des informations dans la base de données.

Maintenant que vous avez saisi l'intérêt du cryptage, vous allez me demander comment le script de connexion fait pour comparer le mot de passe crypté (que j'appellerai « hash » par la suite) et celui que l'utilisateur saisit lorsqu'il veut se connecter. En effet, l'utilisateur n'ayant pas connaissance du mot de passe crypté et ne sachant sûrement même pas que vous le site le crypte, il saisira l'original lorsqu'il tentera de se connecter. Si avez bien compris le principe de fonctionnement du système d'identification que je vous ai expliqué tout à l'heure, vous saisissez le problème : le mot de passe original connu de l'internaute n'est pas égal au mot de passe crypté connu de la base de données.

L'astuce, pour contourner ce problème, est simple : le script de connexion va crypter le mot de passe saisi par l'utilisateur avant de le comparer à celui stocké dans la base de données. Selon la même méthode que lors de l'enregistrement, donc. Magie, magie !

Schéma du processus de connexion avec un mot de passe crypté.

C'est justement à cause de ce cryptage que certains sites ne peuvent pas vous rappeler votre mot de passe quand le perdez et qu'ils en génèrent un nouveau pour vous. En effet, les fonctions de hachage fonctionnent à sens unique. Par conséquent, lorsqu'un site est capable de vous le restituer, c'est généralement qu'il ne crypte pas les mots de passe dans sa base de données ; vous pouvez alors vous inquiéter pour la sécurité de vos données.

Pour résumer : La sécurité des mots de passe repose en grande partie sur leur cryptage dans la base de données.

Un algorithme pour crypter vos mots de passe : le MD5

Sur beaucoup de sites, c'est la fonction de cryptage (ou plutôt de hachage) MD5 qui est utilisée. Sa fonction est simple : elle transforme une chaine de caractères initiale (mon mot de passe « azerty »), en une nouvelle chaine de 32 caractères (128 bits) supposée unique. Avec cet algorithme, mon mot de passe « azerty » est transformé en « ab4f63f9ac65152575886860dde480a1 ».

Ainsi, avec ce système, si un individu malintentionné arrivait à accéder à la base de données d'un site sur lequel vous êtes inscrit, il arriverait seulement à récupérer le mot de passe crypté et non le précieux sésame, c'est-à-dire votre mot de passe personnel. De ce fait, il ne pourrait pas s'en servir directement sur des sites où vous l'auriez également utilisé. Sympa, non ?

Pas tellement, en fait... puisque l'utilisation de ce simple algorithme, bien que très (trop) répandue, est malheureusement loin d'être vraiment efficace.

Entre autres choses :

1. En théorie, le décryptage d'un hash MD5 est impossible, mais en théorie seulement. En effet, MD5 étant très utilisé (et c'est un euphémisme), de nombreux dictionnaires « inversés » existent. Ainsi, comme sur un annuaire de téléphonie inversé, vous entrez le mot de passé crypté et le dictionnaire vous retourne le mot de passe d'origine, à condition qu'il le connaisse. Par conséquent, la plupart des mots de passe génériques, communs et courts (« azerty », « hello », « 123 »...), peuvent être décryptés en un clin d'œil.
2. Le risque de collision. Kezako ? Concrètement, c'est le fait d'obtenir la même chaîne cryptée à partir de deux chaines de caractères différentes. Pour prendre un exemple concrêt, si « azerty » et « azerty2 » donnaient tous deux le hash « ab4f63f9ac65152575886860dde480a1 », on pourrait considérer cela comme une collision. Les risques, pour vos données sont plus que limités, mais une collision peut néanmoins permettre à quelqu'un d'accéder à votre compte alors même qu'il n'a pas saisi le bon mot de passe. Une chance sur quelques millions, je vous l'accorde, la collision restant difficile à mettre en œuvre.
3. Imaginons qu'un des sites sur lesquels vous êtes inscrit se fait pirater. Supposons également qu'un autre site sur lequel vous êtes inscrit avec ce même mot de passe utilise le même type de cryptage. Dans ces deux cas, les mots de passe cryptés stockés dans les bases de données des deux sites seraient donc identiques. Imaginons en plus que le site « sain » utilise la méthode d'identification par cookies. Il suffirait alors au pirate de créer un cookie contenant le mot de passe crypté afin de se connecter au site non piraté. Je vous l'accorde, ça paraît extrême, mais c'est pourtant un véritable danger.

Schéma présentant ce qu'est une collision.

Pour résumer : MD5 est un premier rempart, pourtant loin d'être infaillible.

D'autres algorithmes pour crypter vos mots de passe

Vu les limites du MD5, de nombreux sites commencent à l'abandonner, au profit d'algorithmes jugés plus fiables. Ainsi, l'utilisation du SHA1 commence petit à petit à prendre le pas sur celle du MD5, car les collisions sont plus difficiles et les dictionnaires de mots de passe encore peu fournis, du fait de sa jeunesse.

Mais est-ce suffisant ? Non, car s'il était hier encore réputé fiable, il commence déjà à montrer ses limites ; les mêmes que celles du MD5.

Et c'est un cercle infini : les nouveaux arrivants, tels que SHA256 (qu'on préféra désormais), SHA512 ou encore Whirlpool non, non, pas les machines à laver , apportent tous une sécurité supplémentaire, dans la mesure où le nombre de caractères de la chaine cryptée augmente toujours. Imaginez : si azerty devient « f2d81a260dea8a100dd517984e53c56a7523d96942a834b9cdc249bd4e8c7aa9 » (SHA256) plutôt que « ab4f63f9ac65152575886860dde480a1 » (MD5), du fait de sa grandeur, le risque de collision est moins élevé, car il y a plus de combinaisons possibles. De plus, les tentatives d'attaque par brute force seront très longues, car il est moins facile de venir à bout d'un code de 32 caractères que de 64 caractères !

Pourtant, ils finiront toujours pas perdre en efficacité au fil du temps, dans la mesure où plus un algorithme est utilisé, plus les dictionnaires de mots de passe deviennent fournis.

Schéma présentant les principaux algorithmes de cryptage.

Pour résumer : MD5, SHA1, SHA256, SHA512, Whirlpool... Au final, ce n'est pas tant l'algorithme qui pose problème, mais c'est plutôt les limites de la technique inhérente au cryptage. C'est pourquoi il est intéressant de mettre en place une méthode supplémentaire pour protéger les mots de passe sur un site.

Les grains de sel statiques

L'idée, pour améliorer la sécurité des mots de passe, c'est donc d'utiliser un grain de sel (aussi appelé « salt »).

Kezako ? Lors de l'enregistrement de votre mot de passe dans la base de données, le script d'enregistrement effectue deux actions avant de stocker vos informations dans la base de données :

1. Il va ajouter un « code secret » après le mot de passe, commun à tous les utilisateurs et stocké dans le code PHP. Par exemple, il va ajouter le grain de sel « _NA » après le mot de passe, ce qui donnera : « azerty_NA ».
2. Le script va ensuite effectuer l'étape du cryptage du mot de passe modifié. Ici, il va crypter « azerty_NA » en MD5 et l'enregistrer dans la base de données, ce qui donnera : « ed50abc53d3f1b481bfc6641349afbb4 », au lieu de « ab4f63f9ac65152575886860dde480a1 » sans sel.

Schéma présentant le processus de fonctionnant des grains de sel statiques.

Quel intérêt ? Les bénéfices, ici, sont nombreux, car ils pallient presque tous aux défauts des méthodes de cryptage que j'avais soulevés précédemment :

1. Même si l'un des sites sur lesquels vous étiez inscrit avec ce même mot de passe utilisait le même type de cryptage, le mot de passe enregistré dans sa base de données saine ne serait plus identique à celui récupéré sur la base piratée. Par conséquent, même si le site non piraté utilisait la méthode d'identification par cookies, le pirate ne pourrait pas y accéder à l'aide d'un cookie fabriqué.
2. L'utilisation de dictionnaires inversés de mots de passe devient plus compliquée. En effet, il est moins probable que ceux-ci possèdent l'occurrence « azerty_NA » que « azerty ». Avec un grain de sel original, la possibilité que le dictionnaire dispose de ce mot de passe est donc diminuée.
3. Dans le cas d'attaque par brute force ou si le mot de passe est présent dans le dictionnaire, le pirate obtiendrait le mot de passe tel que modifié : « azerty_NA ». Le problème pour lui, c'est qu'il ne saurait pas quel est le grain de sel, donc il ne pourrait pas utiliser le mot de passe, sauf s'il arrivait à localiser et à supprimer le salt.
4. Enfin, les grains de sel permettent de lutter contre les lacunes de vos propres mots de passe, qu'il soient trop communs ou trop courts. Par dictionnaire inversé, « azerty » est en effet trouvé sans problème, alors que « azerty_NA» ne le sera pas forcément.

Pour résumer : D'une efficacité effarante, le grain de sel est pourtant assez peu utilisé, car peu connu. Bien sûr, si le pirate accède également au fichier côté serveur qui contient le sel, il aura connaissance de celui-ci, donc la protection offerte sera moins efficace.

Les grains de sel dynamiques

Avec les grains de sel, on peut même aller encore plus loin ! L'arme ultime, c'est en effet d'utiliser un second grain de sel, dynamique cette fois. C'est-à-dire qu'on va utiliser un code secret propre à chacun des utilisateurs qui sera apposé au mot de passe. On peut, par exemple, en générer un automatiquement, ou alors utiliser la date d'inscription de l'utilisateur, puis le stocker dans la base de données.

Lors de l'enregistrement de votre mot de passe dans la base de données, le script d'enregistrement va alors effectuer trois actions avant de stocker vos informations dans la base de données :

1. Il va ajouter un « code secret » après le mot de passe, commun à tous les utilisateurs et stocké dans le code PHP. Ainsi, comme tout à l'heure, il va ajouter le grain de sel « _NA » après le mot de passe, ce qui donnera : « azerty_NA » (« ab4f63f9ac65152575886860dde480a1 »)
2. La nouveauté, c'est qu'il va ensuite apposer le second grain de sel avant le mot de passe. Ici, supposons que mon grain de sel personnel soit « BoGoss », le mot de passe deviendra : « BoGossazerty_NA ».
3. Le script va maintenant effectuer l'étape du cryptage de ce mot de passe modifié. Ici, il va donc crypter « BoGossazerty_NA » et l'enregistrer dans la base de données, ce qui donnera : « 56570953e016a8cdcde313bfe8152ff4 ».

Schéma présentant le processus de fonctionnant des grains de sel dynamiques.

Je vous vois venir : c'est inutile, puisque si le pirate réussit à accéder à la base de données, il découvre le sel dynamique ! Certes, mais ça complique lourdement sa tache, et c'est une raison suffisante pour le maître en place : on ne va quand même pas lui simplifier la tâche, à cette tâche !

En plus des avantages offerts par le sel statique, il en offre d'autres (ou les améliore) :

1. Ici, l'utilisation d'un dictionnaire de mots de passe est inefficace dans 95% des cas. En effet, du fait de l'accumulation d'un grain de sel statique et d'un autre dynamique atypique, il y a très peu de chances qu'il possède une entrée répondant au hash piraté.
2. Le pirate est obligé de mettre en place une procédure spécifique à chaque utilisateur s'il veut décrypter le mot de passe. Vous imaginez la galère !
3. Ce salt dynamique permet de faire en sorte qu'aucun membre n'ait le même mot de passe crypté que vous. En effet, avec ces fonctions de cryptage, si deux utilisateurs ont choisi le même mot de passe, le hash des deux utilisateurs sera identique. Ca ne pose pas forcément de gros problèmes de sécurité, mais ce n'est pas forcément très appréciable, dans la mesure où, si vous connaissez le mot de passe non crypté de l'un des deux membres, vous êtes en mesure de connaître celui du second ! Ici, dans la mesure où le grain de sel est propre à chaque utilisateur, chacun a un hash différent. Il est même quasiment impossible que deux membres aient le même hash !

Pour résumer : L'utilisation de grains de sel associée au cryptage du mot de passe représente une arme redoutable pour assurer la sécurité de vos données.

Comment les protéger, de votre côté

De votre côté, vous disposez de quelques options qui vous permettront de limiter la casse et d'assurer au maximum votre sécurité dans l'hypothèse où l'une des bases de données d'un site sur lequel vous êtes inscrit venait à être piraté.

D'une part, il est primordial d'essayer de ne pas utiliser le même mot de passe partout. Je sais que c'est plus facile à dire qu'à faire, et je sais de quoi je parle : si on le faisait vraiment, on en finirait plus ! L'idée, c'est donc d'avoir trois mots de passe : un premier destiné aux sites critiques (banque, compte mail), un mot de passe « poubelle » pour les sites où vous ne comptez pas repasser ou qui ne vous inspirent pas confiance, et un dernier pour les sites avec une importance ni nulle, ni critique (Net-Actuality par exemple ).

D'autre part, choisissez un mot de passe original (pas le nom de votre chien, votre date de naissance), ni trop court, ni trop long. En outre, n'utilisez surtout pas de mot de passe commun (« azerty », « 123 », « hello »...). L'arme ultime reste d'associer chiffres et lettres, le summum étant d'y ajouter des caractères spéciaux (*, ^, @, #...), voire même de varier majuscules et minuscules dans le genre parano, on ne fait pas mieux

J'ai d'ailleurs hésité à lister ces dernières mesures dans la section précédente, car elles peuvent parfois même être mises en place du côté serveur. En effet, certains sites vous obligent parfois à choisir un mot de passe associant chiffres et lettres, ou faisant un minimum de caractères. Ca agace parfois lorsque l'on doit trouver un nouveau mot de passe, mais c'est pourtant pour notre bien !

Enfin, cela va de soi, mais évitez de vous inscrire sur des sites que vous ne pensez pas dignes de confiance, ou alors, confiez leur un mot de passe poubelle, comme conseillé tout à l'heure.

Pour résumer : Un mot de passe original et différent selon les sites est une solution idéale pour rendre vos mots de passe plus sécurisés.

Leur protection est-elle vraiment possible ?

Vous l'aurez donc compris, même en prenant toutes les précautions pour avoir un mot de passe solide, l'inscription sur un site ne sécurisant pas correctement vos données peut être fatale. Il faut savoir que beaucoup de sites n'utilisent qu'un simple hachage en MD5, qui n'est pourtant plus très fiable. Pire, certains sites (des boutiques parfois, même !) ne cryptent pas vos mots de passe ! Ainsi, n'hésitez pas à mener votre propre investigation, grâce à la méthode décrite tout à l'heure (formulaire de récupération de mot de passe). Vous pouvez également vous amuser à deviner quel type d'encodage le site utilise en passant en revue votre cookie, et plus particulièrement le champ mot de passe qui s'y trouve (s'il fait 32 caractères, c'est du SHA1/MD5, 64 caractères : SHA256, 128 caractères : SHA512/Whirlpool).

Schéma présentant comment décoder un cookie.

Malgré toutes les précautions à prendre du côté serveur et utilisateur, il faut prendre conscience que la sécurité de vos mots de passe sera toujours faillible. En effet, si un individu malintentionné n'arrive pas à récupérer les mots de passe depuis la base de données, il utilisera fatalement d'autres méthodes. Par exemple, il est possible que quelqu'un puisse accéder à votre mot de passe lorsqu'il transite, de manière non cryptée, de votre navigateur vers le serveur, lors de l'inscription ou de la connexion par exemple (il est néanmoins possible de s'en prémunir avec un tunnel SSH).

De même, de nombreux sites (pour ne pas dire la quasi totalité) envoient votre mot de passe en clair par email lorsque vous vous inscrivez. Là aussi, votre mot de passe pourrait être récupéré lors du transit du mail.

Pire encore, il est même possible que des webmestres peu scrupuleux décident de se servir de leurs bases de données pour tenter de récupérer la mine d'or. Imaginez un méchant webmestre. Supposez qu'un de ses membres s'inscrive sur son site avec son compte Yahoo et le même mot de passe : c'est le jackpot, car il peut alors accéder au compte mail de sa victime avec une facilité déconcertante !

Vous l'aurez donc compris, la protection des mots de passe, sur Internet, se fait à tous les niveaux. Il faut surtout retenir que l'arme ultime n'existe pas et que c'est là même le propre de l'informatique : aucun système n'est infaillible. La prudence est donc de mise.