Dans le cadre de la sécurisation de votre compte ou de celui de vos clients, vous devez également prendre le soin de chiffrer le(s) mot(s) de passe de vos utilisateurs. Nous vous recommandons d’utiliser à cet effet le hachage.
Il est évident qu'une protection accrue des mots de passe dans le système doit être mise en place. Le stockage des mots de passe en clair dans le système est alors vivement déconseillé!
Pourquoi ? Prenons le cas typique d'une base de données dans laquelle sont stockés les identifiants des utilisateurs d'un extranet d'une entreprise. Cela sous-entend qu'il y ait une politique de sécurité à plusieurs niveaux de droits.
Un technicien n'aura pas les mêmes privilèges sur l'application que son supérieur hiérarchique. Ce dernier n'aura également pas les mêmes droits que le directeur des ressources humaines ou le PDG. Dans ce genre d'application, le mot de passe est le garant de la sécurité des données. Il faut donc le protéger assidûment. Un recours au chiffrement devient alors indispensable.

Pourquoi crypter les mots de passe ?

La réponse est simple. Il s'agit de garder confidentiel le mot de passe qui a été attribué à l'utilisateur en dehors de l'application. Il y a aussi une part de déontologie dans la mesure où même le responsable de l'application ne devrait pas connaître les identifiants personnels des utilisateurs. Cela ne le regarde pas. Revenons à notre exemple.
Qui dit extranet dit aussi accès à l'application depuis Internet. Il convient alors de chiffrer les données par une connexion sécurisée HTTPS et de protéger l'application contre d'éventuels accès pirates. Admettons que cet extranet ait mal été écrit et qu'il comporte une faille d'injection SQL. Un pirate pourrait alors récupérer les mots de passe enregistrés dans la base de données et pénétrer l'application sans problème avec les identifiants du PDG. Si les mots de passe sont cryptés, le pirate aura bien plus de mal à retrouver leur correspondance en clair. Dans cet exemple, l'attaque provient de l'extérieur mais qu'en est-il si la faiblesse du système se trouve à l'intérieur même de celui-ci ?
En effet, supposons qu'il faille maintenir la base de données en se connectant directement dessus. La société qui a édité l'application envoie son administrateur de base de données en intervention. Ce technicien intervient sur place mais ne fait aucunement partie de la société qui utilise l'application. Pourtant, il va manipuler la base de données. C'est à dire qu'il pourra très probablement consulter tout ce qui s'y trouve à l'intérieur y compris les identifiants de connexion. Si les mots de passe avaient été enregistrés en clair, il aurait pu s'approprier les accès de n'importe quel utilisateur sur l'application extranet. Malgré tout, rien ne l'empêche de se créer un nouvel utilisateur avec tous les droits directement dans la base de données. Nous verrons donc par la suite qu'un cryptage traditionnel ne suffit pas pour renforcer la sécurité d'un mot de passe.

Protection de mot de passe par hachage

C’est une méthode de cryptage permettant de chiffrer une chaîne de caractères sans possibilité d’inverser cette opération. Le résultat du hash produit généralement une chaîne unique et de longueur fixe. C'est le cas par exemple des algorithmes MD5 et SHA1. Ainsi, lors d'une phase d'authentification, on ne compare plus deux mots de passe en clair mais deux haches du mot de passe.

Pourquoi les hashs simples ne suffisent plus ?

Cette méthode permet de chiffrer les chaînes efficacement mais restent « crackables » parce qu’il existe sur Internet des « rainbow tables » (dictionnaires) capables de vous retourner la chaîne en clair d'un md5(), d'un sha1() ou d'un autre algorithme standard de hash.
Nul besoin de rappeler que les mots de passe classiques du type root, superadmin, toto... existent dans ces dictionnaires. Pour peu que le mot de passe original soit un mot du dictionnaire, il est fort probable que l'on puisse le retrouver dans une rainbow table à partir de son hash.

Hasher les mots de passe avec des « salts »

Cette technique consiste en la concaténation d'une ou plusieurs clés (appelées aussi « salt », «seed» ou «graine») avec le mot de passe, puis le hachage de la chaîne ainsi créée. Bien entendu, la ou les clé(s) doivent rester secrètes dans un fichier de configuration de l'application. Elle permet de ne pas pouvoir récupérer facilement le mot de passe d'origine en clair dans une rainbow table à partir du MD5. La sécurité du mot de passe réside alors dans la complexité et la confidentialité des clés choisies.

Choix du mot de passe

Pour la sécurité de votre compte marchand, respectez ces recommandations en ce qui concerne votre mot de passe:

• utilisez un mot de passe dense pour la création de votre compte FedaPay. C’est-à-dire un mot de passe d’au moins 8 caractères composé de chiffres et de caractères en majuscules et minuscules ;
• évitez d'utiliser le même mot de passe sur plusieurs comptes différents. Si quelqu’un obtient d’une manière ou d’une autre votre mot de passe, il accédera à tous vos comptes en utilisant les mêmes informations d'identification ;
• évitez de communiquer votre mot de passe à qui que ce soit ;
• pensez à changer votre mot de passe aussi souvent que vous le souhaitez.

Définition de questions secrètes

Pour finir, pensez à définir des questions secrètes dont vous serez le seul à connaître les réponses. Ceci vous permet de pouvoir confirmer que vous êtes effectivement l’auteur des requêtes lors de vos demandes de récupération de gains ou dans le cas d’un changement de mot de passe.
Vous pouvez définir vos questions secrètes et même changer votre mot de passe depuis cette partie de votre tableau de bord.

Choisissez vos deux questions secrètes dans la liste et répondez à chacune d'elles puis cliquez sur Enregistrer.