WEBVTT 00:00:06.800 --> 00:00:07.900 Bonjour alors moi c'est Mathieu 00:00:10.950 --> 00:00:17.080 et je vais vous parler des mots de passe parce que je trouve qu'à Sud Web 00:00:17.080 --> 00:00:22.965 comme à Paris Web finalement, il y a beaucoup trop de sujets front 00:00:22.965 --> 00:00:29.373 Donc c'est un sujet qui devrait concerner tout le monde en fait parce que 00:00:29.373 --> 00:00:32.680 quel que soit votre rôle dans un projet web 00:00:32.680 --> 00:00:37.480 vous êtes généralement les premiers utilisateurs du site et vous devriez vous souciez de 00:00:37.480 --> 00:00:43.760 comment vos développeurs, si vous êtes pas développeur ont stocké le mot de passe 00:00:43.760 --> 00:00:48.160 que probablement vous réutilisez de toute façon ailleurs ou pas 00:00:48.160 --> 00:00:50.640 si vous faites les choses très bien mais 00:00:50.640 --> 00:00:52.480 j'en connais pas mal 00:00:52.480 --> 00:00:55.600 qui réutilisent les mêmes mots de passe 00:00:55.600 --> 00:00:58.886 Donc le principe de base quand on parle de sécurité des mots de passe 00:00:58.886 --> 00:01:01.200 c'est de se dire que l'attaquant il a eu accès à votre base de données 00:01:01.200 --> 00:01:04.080 ll a tout le système à sa disposition 00:01:04.080 --> 00:01:08.615 Ensuite le principe de départ c'est de se dire comme je viens de dire 00:01:08.615 --> 00:01:10.920 que nos utilisateurs ils réutilisent les mêmes mots de passe partout 00:01:10.920 --> 00:01:14.840 et qu'on veut quand même les protéger un petit peu 00:01:14.840 --> 00:01:17.720 Donc conclusion, on peut pas vraiment arrêter 00:01:17.720 --> 00:01:20.600 l'attaquant qui a déjà eu accès à votre serveur 00:01:20.600 --> 00:01:23.440 mais on peut essayer de le ralentir 00:01:23.440 --> 00:01:28.160 Tout le principe du stockage de mot de passe c'est ça. 00:01:28.160 --> 00:01:33.040 Donc là je vais grosso modo expliquer les différentes méthodes qu'il ne faut pas appliquer 00:01:33.040 --> 00:01:35.120 pour stocker les mots de passe 00:01:35.120 --> 00:01:37.560 du plus simple au plus compliqué 00:01:37.560 --> 00:01:41.840 et on verra que même les méthodes compliquées sont pas forcément adaptées 00:01:41.840 --> 00:01:45.302 Donc la première c'est juste le stockage en clair, c'est simple il faut pas le faire 00:01:45.302 --> 00:01:48.560 J'espère que tous les développeurs sont au courant 00:01:48.560 --> 00:01:50.920 N'importe qui avec un accès à la base de données peut voir les mots de passe directement 00:01:50.920 --> 00:01:52.640 y compris vos propres développeurs et administrateurs 00:01:52.640 --> 00:01:55.680 ce qui pose quand même un grave problème de vie privée 00:01:55.680 --> 00:02:01.400 surtout si vous avez un site avec beaucoup d'utilisateurs, des profils très complets, etc. 00:02:01.400 --> 00:02:06.920 Deuxième méthode : stockage chiffré ou crypté si on veut faire du franglais 00:02:06.920 --> 00:02:11.920 C'est pas mieux non plus car vous avez forcément une clef de decryptage du mot du passe 00:02:11.920 --> 00:02:15.680 qui est forcément stockée à un endroit où on considère que l'attaquant y a eu accès 00:02:15.680 --> 00:02:23.120 donc c'est pareil, c'est à proscrire aussi. 00:02:23.120 --> 00:02:26.480 Alors là on commence à rentrer dans les trucs compliqués et j'ai fait plein de texte 00:02:26.480 --> 00:02:30.883 surtout pour ceux qui sont pas là et qui n'ont pas la chance d'être ici 00:02:30.883 --> 00:02:33.800 et qui pourront après regarder les slides 00:02:33.800 --> 00:02:37.480 Grosso modo c'est utiliser des algos qui sont fait pour faire des signatures 00:02:37.480 --> 00:02:40.200 donc MD5, SHA-1, etc. 00:02:40.200 --> 00:02:46.080 Ça donne une illusion de sécurité parce qu'on a l'impression que on a plus le truc en clair 00:02:46.080 --> 00:02:50.720 mais en fait c'est des algos qui sont fait pour être calculés très rapidement 00:02:50.720 --> 00:02:56.480 et vu que la puissance des machines qu'on a augmente à une vitesse folle 00:02:56.480 --> 00:02:59.280 au final c'est qu'une illusion de sécurité 00:02:59.280 --> 00:03:01.720 ça devient "craquable" très très rapidement, très très facilement 00:03:01.720 --> 00:03:04.560 donc là j'ai donné des exemples de chiffres, mais ils seront plus valable demain 00:03:04.560 --> 00:03:08.560 donc ça sert à rien, mais c'est juste pour vous donner une idée 00:03:08.560 --> 00:03:17.240 La méthode quatre qu'il faut pas faire et là ça commence à rentrer dans le troll 00:03:17.240 --> 00:03:20.551 c'est ce que à peu près tout le monde qui pense faire les choses bien fait 00:03:20.551 --> 00:03:24.280 c'est à dire utiliser les mêmes algos de hash mais avec ce qu'on appelle un salt 00:03:24.280 --> 00:03:32.000 qu'est un espèce de petit bout qu'on rajoute en plus avant généralement ce qu'on veut stocker 00:03:32.000 --> 00:03:34.280 donc le mot de passe 00:03:34.280 --> 00:03:37.664 c'est déjà beaucoup mieux mais vous êtes en train de réinventer la roue 00:03:37.664 --> 00:03:42.400 quand vous faîtes ça en système de stockage de données sécurisées 00:03:42.400 --> 00:03:44.920 il existe des méthodes qu'on va voir dans la slide d'après 00:03:44.920 --> 00:03:47.240 et ça reste vulnérable aux attaques de brute force au final 00:03:47.240 --> 00:03:52.920 ce que ça empêche c'est un truc que j'ai vaguement abordé dans la slide d'avant sans vous le dire 00:03:52.920 --> 00:03:59.583 c'était les rainbow tables, mais ça devient juste un détail tellement les ordinateurs de nos jours 00:03:59.583 --> 00:04:02.080 sont super puissants quoi. 00:04:02.080 --> 00:04:04.280 Donc on peut faire encore mieux que ça, même si c'est déjà pas mal 00:04:04.280 --> 00:04:08.040 si vous êtes là, c'est déjà sympa hein 00:04:08.040 --> 00:04:13.840 Donc le truc sympa c'est de garder le principe du salt,vous en mettez un par mot de passe 00:04:13.840 --> 00:04:21.735 comme ça vous empêchez l'attaquant de pouvoir recalculer avec un même salt 00:04:21.735 --> 00:04:25.822 Et vous utilisez des implémentations spécifiques dont le but est de ralentir la génération 00:04:25.822 --> 00:04:29.760 C'est à dire qu'au lieu d'avoir un truc, une empreinte du mot de passe 00:04:29.760 --> 00:04:32.960 qui se génère en 0,000x secondes 00:04:32.960 --> 00:04:36.640 vous avez un truc qui se génère en 500ms voire 1s 00:04:36.640 --> 00:04:40.040 En fait vous pouvez choisir avec ces types d'algorithmes 00:04:40.040 --> 00:04:44.400 la vitesse que vous voulez, donc vous choisissez ça avec un iteration count 00:04:44.400 --> 00:04:47.920 et vous vous choisissez ça, enfin ça dépend de l'algo mais vous choisissez un nombre 00:04:47.920 --> 00:04:51.280 qui vous semble correct pour ralentir suffisamment 00:04:51.280 --> 00:04:57.080 et vous avez vaguement une garantie que ça va être suffisamment compliqué à calculer 00:04:57.080 --> 00:04:59.200 pour que ça soit pas automatisable par un attaquant 00:04:59.200 --> 00:05:02.742 Donc au pire il va prendre des années à calculer un mot de passe 00:05:02.742 --> 00:05:04.669 et vous êtes tranquilles. 00:05:04.669 --> 00:05:09.120 Et le raffinement ultime c'est scrypt 00:05:09.120 --> 00:05:13.960 c'est une version encore améliorée de ça qui en plus d'être coûteuse en temps CPU 00:05:13.960 --> 00:05:17.040 elle est aussi coûteuse en mémoire car il commence à y avoir 00:05:17.040 --> 00:05:26.040 du hardware spécifique pour calculer même des algos genre bcrypt, etc. 00:05:26.040 --> 00:05:30.240 et donc au final le seul moyen qui nous reste pour lutter contre ça 00:05:30.240 --> 00:05:34.320 c'est en plus d'être coûteux en CPU, d'être coûteux aussi en mémoire 00:05:34.320 --> 00:05:37.440 pour empêcher ces matériels spécifiques de fonctionner 00:05:37.440 --> 00:05:40.360 Là on entre dans un raffinement vraiment extrême 00:05:40.360 --> 00:05:44.000 et pour l'instant y'a suffisament peu d'implémentations contrairement aux 3 autres que j'ai cité 00:05:44.000 --> 00:05:46.120 qui sont les gros trucs 00:05:46.120 --> 00:05:47.800 Y'a relativement peu d'implémentations 00:05:47.800 --> 00:05:52.665 Juste sachez que tous ces algos, ils se retrouvent dans des Operating System 00:05:52.665 --> 00:05:56.920 par exemple Linux utilse SHA-512 je pense 00:05:56.920 --> 00:05:59.360 FreeBSD ... non OpenBSD ils utilisent scrypt 00:05:59.360 --> 00:06:04.902 non OpenBSD utilise bcrypt et je sais plus qui veut utiliser scrypt 00:06:04.902 --> 00:06:07.084 si c'est openBSD ou un autre mais bref 00:06:07.084 --> 00:06:11.080 c'est des trucs qui sont éprouvés, qui sont fait pour stocker des mots de passe 00:06:11.080 --> 00:06:13.080 et c'est comme ça qu'ils sont utilisés. 00:06:13.080 --> 00:06:17.920 Donc ils sont beaucoup plus fiables que faire votre truc à la main avec un salt ou je ne sais quoi 00:06:17.920 --> 00:06:23.320 Et voilà j'ai plus le temps mais bonus n'oubliez pas d'éduquer vos utilisateurs 00:06:23.320 --> 00:06:27.200 Parce que s'ils n'utilisaient pas les mêmes mots de passe partout, on aurait pas les mêmes problèmes 00:06:27.200 --> 00:06:31.480 Incitez les si possibles à utiliser des mots de passe longs avec des caractères spéciaux, etc, etc. 00:06:31.480 --> 00:06:36.574 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" 00:06:36.574 --> 00:06:39.840 c'est pas vrai, ça donne l'impression que c'est plus facile mais en fait 00:06:39.840 --> 00:06:43.000 quand il se fera piquer son mot de passe à cause de vous 00:06:43.000 --> 00:06:46.760 c'est vous qu'il ira venir voir et il ira emmerder votre support 00:06:46.760 --> 00:06:48.960 voilà et faîtes du HTTPS.