Introduction

Cela ne devrait pas vous avoir échappé qu’on ne doit jamais stocker des mots de passes en clair dans une base de donnée, pour deux raisons :

• si vous ré-employez ce mot de passe ailleurs, vous venez de donner aux administrateur l’accès à tous vos comptes ;
• si la base de donner fuite, tout le monde aura accès à votre compte sur ce site (et potentiellement les autres où vous utilisez ce mot de pas).

Ça n’est pas idéal.

Pour cette raison est née une solution : hacher les mots de passe. C’est à dire les transformer en une chaîne de caractère qui rend difficile la transformation inverse. Ainsi si on nous présente le bon mot de passe on retrouvera le hash et on pourra laisser l’utilisateur se connecter à son compte.

Sauf que ça pose deux problème :

• si deux personnes ont le même mot de passe elles auront le même hash, si l’un est deviné l’autre aussi ;
• les rainbow tables : des tables de correspondances qui associent des hashes à des chaînes en clair (pas idéal en cas de fuite, une fois de plus…)

En plus d’utiliser un algorithme de hachage on doit aussi utiliser un algorithme de salage. On va hacher le mot de passe et une valeur aléatoire, appelée sel (salt en anglais), pour que chaque hash soit différent, même s’il est généré à partir de la même valeur. On ajoute à chaque hash des informations sur comment il a été salé pour qu’il soit tout de même possible de vérifier qu’un mot de passe en clair corresponde au hash.

À date d’écriture, l’algorithme de hachage et de salage de mots de passe actuellement conseillé par l’OWASP (Open Worldwide Application Security Project) est argon2 dans sa variante argon2id.

Exercice : repository

Utilisez le paquet : https://www.npmjs.com/package/argon2 pour hacher les mots de passer lors de l’ajout d’un utilisateur en base de données dans votre Repository. Respectez les conseils de : https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html

Sur votre repository : écrivez une fonction qui reçoit un mot de passe en clair et un nom d’utilisateur, vérifie le mot de passe contre le hash de l’utilisateur et renvoie true s’il est bon, false s’il ne l’est pas.

Exercice : routes

Assurez-vous d’avoir une route qui permet la création d’utilisateur sans être connectés.

Assurez-vous d’avoir une route qui permet à un administrateur de changer les rôles d’un autre utilisateur.

Écrivez une route qui permet de se login et d’obtenir un access_token avec les bonnes permissions et le bon sub de définis.

Conclusion

Mots de passes, jetons, base de données, routes, etc. Il semblerait que vous ayez tous les outils nécessaire à l’implémentation d’une API. Certains éléments sont peut être encore brouillon, notamment sur l’aspect procédures de sécurités où nous sommes assez lax, mais vous avez suffisamment d’éléments pour vous concentrer sur le métier et y ajouter des fonctionnalités.

Notes internes

Jusque là ils ont des routes pour :

• utilisateurs
• événements
• activités