J'ai un site web que j'ai créé avec un back-end Nodejs et je suis actuellement coincé avec un problème de sécurité.
Pour que mon site Web fonctionne, je dois vous connecter à l'aide d'un service 3ème partie qui nécessite un nom d'utilisateur, un mot de passe et un code de sécurité. Je dois être capable de vous connecter à plusieurs comptes plusieurs fois automatiquement tout au long de la journée pour que mon site Web fonctionne. Je ne stocke aucune information utilisateur, ceci est mes propres informations de compte.
Il est donc évident que tout en stockant tout en texte clair dans l'une de mes classes est une mauvaise idée, alors quelle serait la meilleure façon de stocker mes informations de connexion? Avoir une base de données qui ne peut être accessible que localement avec les données à l'intérieur être une bonne option? Comme je l'ai déjà dit, il doit être capable de vous connecter automatiquement de sorte que je ne suis pas sûr que le hachage Ça fonctionnerait car le code devra la déchiffrer de toute façon, si mon code est jamais exposé, cela importera-t-il vraiment?
Merci d'avance pour toute aide.
3 Réponses :
Ce n'est probablement pas une bonne idée de stocker un mot de passe, car même si vous le cryptez, La clé de cryptage est toujours quelque part sur le serveur. Avez-vous vérifié si le service tiers propose un flux d'authentification comme Oauth ou équivalent?
Oui, il n'y a pas d'autre moyen d'auth. Doit être nom d'utilisateur, mot de passe et une clé d'autorisation. Vraiment aucun moyen autour de cela malheureusement: /
Vous demandez essentiellement «Comment puis-je stocker des secrets sur mon backend?».
localement, vous utiliseriez un fichier .env, qui n'est pas engagé dans la commande de version, qui stocke vos secrets (c'est-à-dire «Nom d'utilisateur = JBALLIN»).
Vous utiliseriez ensuite quelque chose comme dotenv pour extraire ces valeurs dans des variables d'environnement et les utiliser sur votre backend.
En production, vous stockez ces variables d'environnement sur le serveur (les instructions dépendent de l'environnement de déploiement).
L'utilisation des variables environnementales semble être une bonne idée, merci pour l'aide!
Il existe une nouvelle technologie - protocole de cryptage durci de mot de passe (PHE) - une technologie cryptographique puissante et révolutionnaire qui fournit une sécurité plus forte et plus moderne, qui sécurise les données des utilisateurs et réduit les risques de sécurité associés à des mots de passe faibles.
Virgil Purekit permet développeurs à Interagissez avec le service PHE Virgil pour protéger les mots de passe des utilisateurs et les informations personnelles sensibles (données PII) dans une base de données d'attaques hors ligne / en ligne et rend les mots de passe / données volés inutiles si votre base de données a été compromise. Ni Virgil ni les attaquants ne savent rien des mots de passe / données des utilisateurs.
Je vous ai fourni le lien où vous pouvez trouver des extraits de code pour de tels langues comme suit: Go, PHP, C #, Java
Ceci est mes propres informations personnelles comme je l'ai mentionnée, pas les données de mon utilisateur. Je dois être capable de me connecter avec mes propres références à une tierce partie. Les utilisateurs se connectent avec une 3ème partie différente, nous n'obtenons aucune donnée utilisateur que ce soit
Oups, mon erreur, désolé. Vous dites donc que votre application doit obtenir des informations d'autres services en utilisant vos informations d'identification sur le service tiers?
Je pense que ce que vous demandez est équivalent à la question de savoir où stockez-vous les touches API sur votre serveur afin que votre serveur puisse accéder à des données de tiers à l'aide de leurs API. Meilleur de la recherche sur le Web "Comment puis-je stocker les clés de l'API" lorsque votre IAME / PWD est essentiellement une clé API. Il y a beaucoup d'avis sur le Web, alors soyez prudent :)
Ouais, cela semble être à peu près la configuration que j'avais précédemment. On dirait que ce que tu et Jallin ont suggéré sont les meilleures options. Merci