Bonjour alors moi c'est Mathieu et je vais vous parler des mots de passe parce que je trouve qu'à Sud Web comme à Paris Web finalement, il y a beaucoup trop de sujets front Donc c'est un sujet qui devrait concerner tout le monde en fait parce que quel que soit votre rôle dans un projet web vous êtes généralement les premiers utilisateurs du site et vous devriez vous souciez de comment vos développeurs, si vous êtes pas développeur ont stocké le mot de passe que probablement vous réutilisez de toute façon ailleurs ou pas si vous faites les choses très bien mais j'en connais pas mal qui réutilisent les mêmes mots de passe Donc le principe de base quand on parle de sécurité des mots de passe c'est de se dire que l'attaquant il a eu accès à votre base de données ll a tout le système à sa disposition Ensuite le principe de départ c'est de se dire comme je viens de dire que nos utilisateurs ils réutilisent les mêmes mots de passe partout et qu'on veut quand même les protéger un petit peu Donc conclusion, on peut pas vraiment arrêter l'attaquant qui a déjà eu accès à votre serveur mais on peut essayer de le ralentir Tout le principe du stockage de mot de passe c'est ça. Donc là je vais grosso modo expliquer les différentes méthodes qu'il ne faut pas appliquer pour stocker les mots de passe du plus simple au plus compliqué et on verra que même les méthodes compliquées sont pas forcément adaptées Donc la première c'est juste le stockage en clair, c'est simple il faut pas le faire J'espère que tous les développeurs sont au courant N'importe qui avec un accès à la base de données peut voir les mots de passe directement y compris vos propres développeurs et administrateurs ce qui pose quand même un grave problème de vie privée surtout si vous avez un site avec beaucoup d'utilisateurs, des profils très complets, etc. Deuxième méthode : stockage chiffré ou crypté si on veut faire du franglais C'est pas mieux non plus car vous avez forcément une clef de decryptage du mot du passe qui est forcément stockée à un endroit où on considère que l'attaquant y a eu accès donc c'est pareil, c'est à proscrire aussi. Alors là on commence à rentrer dans les trucs compliqués et j'ai fait plein de texte surtout pour ceux qui sont pas là et qui n'ont pas la chance d'être ici et qui pourront après regarder les slides Grosso modo c'est utiliser des algos qui sont fait pour faire des signatures donc MD5, SHA-1, etc. Ça donne une illusion de sécurité parce qu'on a l'impression que on a plus le truc en clair mais en fait c'est des algos qui sont fait pour être calculés très rapidement et vu que la puissance des machines qu'on a augmente à une vitesse folle au final c'est qu'une illusion de sécurité ça devient "craquable" très très rapidement, très très facilement donc là j'ai donné des exemples de chiffres, mais ils seront plus valable demain donc ça sert à rien, mais c'est juste pour vous donner une idée La méthode quatre qu'il faut pas faire et là ça commence à rentrer dans le troll c'est ce que à peu près tout le monde qui pense faire les choses bien fait c'est à dire utiliser les mêmes algos de hash mais avec ce qu'on appelle un salt qu'est un espèce de petit bout qu'on rajoute en plus avant généralement ce qu'on veut stocker donc le mot de passe c'est déjà beaucoup mieux mais vous êtes en train de réinventer la roue quand vous faîtes ça en système de stockage de données sécurisées il existe des méthodes qu'on va voir dans la slide d'après et ça reste vulnérable aux attaques de brute force au final ce que ça empêche c'est un truc que j'ai vaguement abordé dans la slide d'avant sans vous le dire c'était les rainbow tables, mais ça devient juste un détail tellement les ordinateurs de nos jours sont super puissants quoi. Donc on peut faire encore mieux que ça, même si c'est déjà pas mal si vous êtes là, c'est déjà sympa hein Donc le truc sympa c'est de garder le principe du salt,vous en mettez un par mot de passe comme ça vous empêchez l'attaquant de pouvoir recalculer avec un même salt Et vous utilisez des implémentations spécifiques dont le but est de ralentir la génération C'est à dire qu'au lieu d'avoir un truc, une empreinte du mot de passe qui se génère en 0,000x secondes vous avez un truc qui se génère en 500ms voire 1s En fait vous pouvez choisir avec ces types d'algorithmes la vitesse que vous voulez, donc vous choisissez ça avec un iteration count et vous vous choisissez ça, enfin ça dépend de l'algo mais vous choisissez un nombre qui vous semble correct pour ralentir suffisamment et vous avez vaguement une garantie que ça va être suffisamment compliqué à calculer pour que ça soit pas automatisable par un attaquant Donc au pire il va prendre des années à calculer un mot de passe et vous êtes tranquilles. Et le raffinement ultime c'est scrypt c'est une version encore améliorée de ça qui en plus d'être coûteuse en temps CPU elle est aussi coûteuse en mémoire car il commence à y avoir du hardware spécifique pour calculer même des algos genre bcrypt, etc. et donc au final le seul moyen qui nous reste pour lutter contre ça c'est en plus d'être coûteux en CPU, d'être coûteux aussi en mémoire pour empêcher ces matériels spécifiques de fonctionner Là on entre dans un raffinement vraiment extrême et pour l'instant y'a suffisament peu d'implémentations contrairement aux 3 autres que j'ai cité qui sont les gros trucs Y'a relativement peu d'implémentations Juste sachez que tous ces algos, ils se retrouvent dans des Operating System par exemple Linux utilse SHA-512 je pense FreeBSD ... non OpenBSD ils utilisent scrypt non OpenBSD utilise bcrypt et je sais plus qui veut utiliser scrypt si c'est openBSD ou un autre mais bref c'est des trucs qui sont éprouvés, qui sont fait pour stocker des mots de passe et c'est comme ça qu'ils sont utilisés. Donc ils sont beaucoup plus fiables que faire votre truc à la main avec un salt ou je ne sais quoi Et voilà j'ai plus le temps mais bonus n'oubliez pas d'éduquer vos utilisateurs Parce que s'ils n'utilisaient pas les mêmes mots de passe partout, on aurait pas les mêmes problèmes Incitez les si possibles à utiliser des mots de passe longs avec des caractères spéciaux, etc, etc. et ne cédez pas aux sirènes du "mais c'est plus facile d'avoir le mot de pase en clair pour l'utilisateur" c'est pas vrai, ça donne l'impression que c'est plus facile mais en fait quand il se fera piquer son mot de passe à cause de vous c'est vous qu'il ira venir voir et il ira emmerder votre support voilà et faîtes du HTTPS.