Wiki SIO Chaptal

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== Sécurité des mots de passe ======
Disposer d'une gestion de mots de passe sécurisés consiste à traiter les points suivants :
===== Politique des mots de passe ===== 
Commencer par définir une politique de gestion des mots de passe cohérente et complète :
  * __Longueur__ : définir la longueur minimale d'un mot de passe. Aujourd'hui 12 caractères est considéré comme une valeur satisfaisante ; 
  * __Complexité__ : obliger à composer son mot de passe selon différents types. Aujourd'hui, au moins un numérique, au moins une majuscule, au moins une minuscule et au moins un caractère spécial sont considérés comme une composition satisfaisante ; 
  * __Durée de vie__ : obliger à changer son mot de passe régulièrement. Aujourd'hui, changer son mot de passe une à deux fois par an est considéré comme satisfaisant ;
  * __Seuil de blocage__ sur échecs répétés : limiter en nombre les tentatives d'authentification en échec. Aujourd'hui, bloquer un compte enregistrant 3 à 5 tentatives infructueuse successives est considéré comme satisfaisant ;
  * __Réinitialisation__ : définir un processus permettant ou imposant de réinitialiser son mot de passe. Fixer les conditions d'accès et les délais maximum laissés à l'utilisateur à chaque étape ;   
===== Communication des mots de passe =====
L'identifiant et le mot de passe d'un utilisateur doivent lui être communiqués à la création de son compte. Considérant que ces informations sont d'une importance fondamentale qu'il convient de protéger, il sera bon de raisonner avec sérieux les moyens employés pour leur communication. 
\\ Bonnes pratiques :
  * Ne JAMAIS communiquer ensemble un identifiant et son mot de passe associé ;
  * Si on ne peut pas éviter de communiquer les deux informations, utiliser deux canaux distincts (SMS + mail ou SMS + WhatsApp, etc.) en privilégiant un canal chiffré de bout-en-bout pour le mot de passe ;
  * Lorsque l'on transmet un <color blue>mot de passe</color>, faire en sorte que celui-ci soit <color blue>temporaire</color> avec obligation de le changer à la première connexion ;
  * A toute autre méthode, <color blue>préférer l'envoi d'un lien temporaire d'activation qui intègrera une étape de choix du mot de passe</color>.

===== Stockage des mots de passe =====
==== Hachage des mots de passe ====
Afin de garantir la sécurité des mots de passe, les points suivants devront être traités :
  * Hacher les mots de passe au moyen d'un <color blue>algorithme actualisé</color> (actuellement hash-code à 256 bits) ;
  * Hacher les mots de passe au moyen d'un <color blue>algorithme le plus lent possible</color> (actuellement BCrypt) ;
  * Hacher les mots de passe <color blue>le plus tôt possible</color> dans le traitement et <color blue>supprimer définitivement et le plus tôt possible toute trace du mot de passe en clair</color> ;
  * Mémoriser les mots de passe sous leur seule forme hachée ;
  * Pour l'authentification, <color blue>ne JAMAIS utiliser SQL pour comparer le mot de passe saisi avec celui stocké en base de données</color>. Le risque est d'amener le mot de passe en clair dans le SGBD où il sera enregistré dans les Logs ;
  * Dans le cas général, pour l'authentification, <color blue>comparer dans le langage de programmation le mot de passe saisi et fraichement haché avec le mot de passe haché stocké en base de données</color> ;
  * <color blue>Une variable qui mémorise un mot de passe en clair doit avoir une durée de vie la plus courte possible</color>. Ce qui signifie que la donnée doit être explicitement détruite ou effacée au plus vite.



==== Salage des mots de passe ====
Le hachage des mots de passe a beau être un procédé à haut niveau de sécurité lorsqu'il est convenablement mis en place (non-réversibilité, taille du hash-code élevée, algorithme lent, etc.), il n'en reste pas moins que l'ensemble comporte une fragilité particulière dans l'hypothèse du vol d'une base de données complète. Dans ce cas, un individu malveillant disposant de beaucoup de temps et d'un outillage spécialisé (**tables arc-en-ciel**) pourrait compromettre de nombreux mots de passe en s'appuyant sur l'homogénéité du hachage appliqué.

Pour contrer cette capacité, on appliquera un **salage** des mots de passe. Le [[https://fr.wikipedia.org/wiki/Salage_%28cryptographie%29|salage]] consiste à ajouter une information aléatoire (le sel) au mot de passe avant son hachage. __Le sel étant variable d'un hachage à l'autre, on aura un hash-code différent pour le hachage du même mot de passe à deux moments différents__. Dans, ce cas, les tables arc-en-ciel deviennent inopérantes. \\ \\ 
Exemple de hash-code produit avec l'algorithme BCrypt :
{{:bloc3:bcrypt.png?600|Format d'un hash-code BCrypt}}

A titre d'exemple, PHP propose une fonction **password_hash** qui intègre un hachage BCrypt et le salage automatique. 

===== Accompagner les utilisateurs =====
Les utilisateurs ne perçoivent pas nécessairement tous les enjeux liés aux mots de passe. La multiplication des comptes et les différences qui existent d'une politique de mots de passe à une autre peuvent engendrer des pratiques contre-productives. Il est donc important de réaliser un travail d'accompagnement qui s'orientera sur deux axes :
  * Sensibilisation sur les dangers et les pratiques à bannir (<color blue>affiches et webinaires</color>);
  * Incitation à utiliser un <color blue>coffre-fort</color> de mots de passe.