Hachage de mot de passe sur le frontend ou le backend?
J'ai un Java serveur avec Spring Boot et un frontend JS dans AngularJS.
Mon professeur m'a dit d'utiliser HTTPS pour les mots de passe, car je ne peux pas les hacher suffisamment en toute sécurité, afin que personne ne puisse les pirater.
Avec HTTPS, si je comprends bien, je n'ai pas besoin de le hacher en plus. Ma source: J'envoie simplement le nom d'utilisateur et le mot de passe via https. Est-ce correct?
Alors maintenant à ma question: je stocke le pw dans une DB bien sûr. Où dois-je les hacher? Frontend ou Backend?
- Si je le hache sur le frontend, je n'ai pas besoin de faire autre chose sur le backend; mais si le certificat HTTPS expire, je suis non sécurisé.
- Si je le fais sur le backend, je n'ai pas besoin de faire autre chose sur le frontend; mais si le certificat HTTPS expire, je suis non sécurisé.
J'utiliserais Scrypt, qui est fait pour le hachage de mot de passe.
@ John a déjà très bien décrit le passage du mot de passe sur le réseau (utilisez HTTPS).
Pour répondre à ta question:
Où dois-je les hacher? Frontend ou Backend?
Le backend . Si vous ne les hachez que dans le frontend, vous êtes vulnérable au passage de l'attaque de hachage.
La raison pour laquelle vous hachez des mots de passe dans votre base de données est d'empêcher un attaquant qui a déjà compromis votre base de données d'utiliser ces mots de passe.
Si vous hachez les mots de passe dans le backend, un attaquant doit d'abord les cracker pour les utiliser sur votre site Web. mais si vous les hachez dans le frontend, un attaquant n'a pas besoin de le faire, il peut simplement passer le hachage tel qu'il est stocké dans la base de données.
Vous confondez deux choses: la sécurité des transports et la sécurité des bases de données. HTTPS utilisant TLS protège uniquement le transport des données du client vers le serveur. Cela signifie qu'un espion ne sait pas ce que le client et le serveur s'envoient (simplifié). Le stockage des mots de passe est un sujet entièrement différent. Vous voulez vous assurer que même si un attaquant a accès à votre base de données, il ne peut pas accéder aux mots de passe en clair.
Peu importe la façon dont vous stockez les mots de passe, vous devez toujours utiliser TLS. Sinon, un espion peut enregistrer ce que le client envoie au serveur pour s'authentifier. Dans ce cas, peu importe que vous utilisiez le HACHAGE de mot de passe côté client ou côté serveur. L'attaquant pourrait simplement enregistrer ce qui se passe sur le fil et rejouer la communication pour y accéder, se faisant passer pour le client.
(Notez que vous voulez faire du HACHAGE de mot de passe, pas du cryptage. Le hachage est unidirectionnel, le cryptage ne l'est pas)
Le hachage doit être fait en back-end. Le back-end est sous votre contrôle, vous pouvez donc faire en sorte que le hachage se déroule comme il se doit. De plus, vous pouvez avoir un hachage côté client. Vous ne devez pas utiliser le hachage côté client seul, comme le ferait par exemple être fait en JavaScript que l'utilisateur pourrait bloquer ou manipuler. Cela peut ne pas sembler être une menace raisonnable, mais vous ne devez jamais faire confiance aux données fournies par l'utilisateur. Par conséquent, vous ne devez pas supposer que le client effectue correctement le hachage. Cela implique que vous devez absolument le faire en back-end.
HTTPS assure la sécurité de la couche transport uniquement. Cela n'a rien à voir avec les mécanismes de sécurité nécessaires au stockage.
Vous ne devez pas crypter les mots de passe. Vous devez les hacher afin de ne pas pouvoir les décrypter plus tard (ni un attaquant).
Et l'étape de hachage se fait toujours sur le backend, car le faire côté client permettrait à un attaquant ayant accès à vos hachages une méthode pour se connecter sur chaque compte.
HTTPS (HTTP sur TLS/SSL) assure la sécurité des données en transit/données en mouvement, il ne fournit pas de cryptage sur les données au repos (base de données, fichiers sur un disque dur) -> crypté avec AES, 3DES, BlowFish, etc.
Vous pouvez fournir un cryptage sur la base de données, mais pas sur la base de données entière, car cela consommera vos ressources (les fichiers cryptés sont plus volumineux que ceux non cryptés). Cryptez simplement un champ spécifique, c'est-à-dire le PII du client -> Informations sur la carte de crédit.
Ce n'est pas une bonne pratique de crypter les mots de passe des utilisateurs, juste HASH et SALT.
Lorsque votre certificat HTTPS expirera, il est normal que l'attaquant puisse renifler les mots de passe en texte brut, il suffit de fournir la couche de sécurité sur votre code.
Lorsque l'utilisateur fournit le mot de passe, votre code doit avoir une procédure stockée (SQL) pour correspondre à la valeur HASHED + SALT du mot de passe de l'utilisateur dans votre base de données. Si la valeur HASH + SALT ne correspond pas, c'est évidemment un mauvais mot de passe.
Remarque: les hachages assurent l'intégrité.
La fonction SALT atténuera le risque que l'attaquant exécute une attaque de table Rainbow, car l'attaquant ne connaît pas la valeur SALT.
La clé: HASH + SALT