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.