Quelle est la meilleure façon de garder en toute sécurité les mots de passe clairs?
Je travaille sur un projet Web qui vous connectera à une base de données. Pour cela, Je devrai stocker le login/mot de passe de cet utilisateur de la base de données en clair (crypté de manière symétrique) afin de pouvoir reconnecter toutes les actions (comme création de table, ajouter des entrées, etc.) sans avoir à demander ces informations d'identification à chaque fois.
Je suis conscient que stocker le mot de passe en clair est trop peu sûr et hors de mes possibilités.
Voici ce que je pensais, pourriez-vous me dire si ce serait correct ou/et s'il y a une meilleure possibilité? Merci :)
L'application sera divisée dans deux parties indépendantes: le frontend et le backend.
Lorsque l'utilisateur se connecte via Frontend, le login et le mot de passe sont envoyés en clair (je recommanderai l'utilisation de HTTPS). Le backend tentera de se connecter à la base de données, si cela réussira, il sera chiffrer le login et le mot de passe à l'aide de Blowfish , et retournez-les à la facette.
Pour toute demande ultérieure, le frontend devra envoyer le login/mot de passe crypté, sans jamais connaître le claire, juste le crypté.
Si quelqu'un a accès aux données de cet utilisateur (XSS par exemple), il ne pourra accéder que les informations d'identification cryptées, et non le clair.
Si un attaquant peut faire un MITM, seule la connexion initiale est risquée, toutes les demandes suivantes seront avec les informations d'identification cryptées.
J'ai pensé à utiliser des cookies/une session, mais c'est la même chose: les valeurs sont stockées dans Clear ou Base64 codé. Pas vraiment sécurisé!
L'idée de Blowfish provient de la manière dont la phpmyadmin l'utilise (aka, identique). De plus, même sur phpmyadmin, la partie de connexion est également envoyée en clair.
Pensez-vous que ma mise en œuvre est correcte ou avez-vous quelque chose de mieux à suggérer? J'aimerais vraiment faire quelque chose aussi sécurisé que possible. Jusqu'à présent, seule la partie de connexion me dérange: /
Merci pour vos idées.
Edit :
Apparemment, ma question n'est pas assez claire, je vais essayer d'être plus explicite :
Je veux construire une alternative à phpmyadmin. PhpMyAdmin est un middleware qui se connecte à un serveur MySQL en donnant le nom d'utilisateur/mot de passe de tout utilisateur dans cette base de données. Les informations d'identification posées sur le formulaire Web sont celle utilisée pour la base de données MySQL.
Donc, pendant toute la session après l'enregistrement de l'utilisateur, PHPMYADMIN stocke le login/mot de passe de la session en cryptant le mot de passe en utilisant Blowfish.
Ceci ne peut pas être évité, car chaque fois que l'utilisateur apporte une demande (comme créer une table, insérer des données, la mise à jour ou la suppression de données), phpmyadmin doit se reconnecter à cette base de données à l'aide des informations d'identification données à la connexion, et ensuite faire l'action que l'utilisateur a demandé.
C'est alors pas possible Pour PHPMYADMIN de stocker uniquement un hachage des informations d'identification, car il ne sera pas en mesure de renouer à la base de données lors de demandes ultérieures effectuées par ce même utilisateur.
Je suis conscient de stocker le mot de passe qui peut être récupéré en clair est pas une bonne solution du tout, et c'est la raison de this Question: Ne me dis pas que ce hachage est meilleur , parce que c'est absolument inutile Dans mon cas, mais savoir s'il y a une meilleure alternative que le cryptage symétrique + https pour garder un mot de passe nécessaire pour chaque action.
Maintenant que la question a été révisée, je comprends ce que vous essayez de faire beaucoup mieux.
La réponse courte est la suivante: Stockez simplement le mot de passe de la base de données dans l'objet Clear, dans l'objet de session (côté serveur). Vous ne pouvez rien faire mieux.
Si vous le souhaitez, vous pouvez chiffrer le mot de passe de la base de données et stocker le mot de passe crypté de l'objet de session, mais il n'y a vraiment aucun point, car où allez-vous stocker la clé? Il n'y a aucun endroit où vous pouvez stocker la clé beaucoup plus sécurisée que l'objet de session. Vous pouvez stocker la clé dans un fichier de configuration ou une variable globale, mais je ne suis pas sûr que cela ajoute une sécurité contre une menace réaliste. Il est difficile de voir pourquoi se déranger - ça me semble théâtre de sécurité.
Donc, il suffit de saisir l'utilisateur de saisir le mot de passe de la base de données au début de la session, stockez le mot de passe de la base de données dans l'état de la session et être effectué avec. Il n'y a rien de mieux que vous puissiez faire.
Et pour l'amour du ciel, utilisez de bonnes pratiques de programmation d'applications Web. Découvrez les ressources OWASP. Assurez-vous de connaître les vulnérabilités Web communes observées dans le World Web. Ecrivez votre code attentivement, en utilisant de bonnes pratiques de sécurité. Et demandez à quelqu'un d'autre qui connaît quelque chose à propos de la sécurité pour effectuer un examen de sécurité de votre code. S'il y a une vulnérabilité de sécurité dans votre code, de mauvaises choses vont se passer.
Vous ne devriez pas avoir besoin de garder des informations d'identification dans un format récupérable, même si elles sont cryptées. Si votre demande de backend pourrait déchiffrer quelque chose, tout le monde pourrait alors pirater votre demande de backend. Vraiment, vous devez supposer que tôt ou tard, votre demande de backend sera compromise et concevoir cela à l'esprit.
La méthode la plus sécurisée serait probablement de stocker les mots de passe comme salé et haché à l'aide d'un algorithme comme BCRYPT ou PBKDF2 . Ces jours-ci, la hachage régulière/salage à l'aide de quelque chose comme MD5 ou SHA1 n'est pas assez sécurisée. Des programmes tels que HASHCAT peuvent rattraper des fichiers de mots de passe de craquage vraiment rapides. Cet article sur Hashcat est une excellente lecture .
C'est bien que vous soyez inquiet pour que quelqu'un ait accès au magasin de cookies. Les cookies sont essentiellement des équivalents de mot de passe, donc si vous les stockez, ils devraient probablement être salés.
Et vraiment, cela semble très facile, mais il y a beaucoup de cas d'angle. Si votre demande Famwork a déjà un moyen de faire la gestion de la session, vous devriez probablement simplement utiliser cela au lieu de rouler le vôtre.
Découvrez le Feuille de triche de la gestion de la session Owasp pour voir de bonnes recommandations.
Premièrement: êtes-vous sûr? Commencez par vérifier si vous vraiment besoin de stocker des mots de passe dans clairtexte ou sous forme récupérable. Votre question n'a pas expliqué pourquoi cela est nécessaire. Si vous avez une violation de sécurité, tout le monde sera de la deuxième-devoir de votre décision, et s'il s'avère que vous avez enregistré des mots de passe stockés au format récupérable, votre organisation peut subir une perte de réputation. Alors, assurez-vous que cela est vraiment nécessaire.
Suivant: Définissez le problème. Donc, qu'est-ce que vous essayez exactement de faire? La question n'était pas très claire, alors je vais faire des suppositions. Si ces suppositions ne sont pas exactes, modifiez la question après avoir donné cela une certaine pensée.
Assomption: les utilisateurs se connectent à votre application Web, appelons-le CyrilApp, en utilisant un nom d'utilisateur et un mot de passe pour votre application. Vous voulez que votre code puisse accéder à un autre compte de la leur - dire, leur email via IMAP - vous leur demandez donc de saisir leur nom d'utilisateur et votre mot de passe de courrier électronique, pour que votre code serveur soit utilisé ultérieurement. Maintenant, vous voulez savoir comment stocker le mot de passe de messagerie aussi fermement que possible. Est-ce à propos de l'idée?
Si tel est le problème, vous avez plusieurs problèmes à prendre en compte: Comment stocker les mots de passe de messagerie? Lors de la récupération des mots de passe de messagerie, comment l'utiliser de manière sécurisée? Comment restreindre l'accès au mot de passe de messagerie?
Stockage. Une option consiste à stocker les mots de passe dans un module de sécurité matérielle (HSM) ou crypté sous une clé gérée par un HSM. Cependant, HSMS coûte très cher, cela peut donc ne pas être réalisable.
Une solution plus pragmatique consiste à créer un service séparé, appelons-le à l'adresse e-mailpasswordstore, qui effectue une fonction étroite et simple, est soigneusement codée et fait confiance pour stocker de manière sécurisée de mots de passe par courrier électronique. Il peut offrir une API qui permet au code CyrilApp de stocker un mot de passe de messagerie d'un utilisateur (lorsqu'il est entré dans) et une API qui permet au code CyrilApp de demander l'utilisation du mot de passe (par exemple, l'e-mailpasswordstore peut ouvrir une connexion IMAP à Le serveur IMAP, envoyez le nom d'utilisateur du courrier électronique et le mot de passe de messagerie de l'utilisateur, puis des bytes de relais entre Cyrilapp et le serveur IMAP.
Dans cette architecture, les mots de passe de messagerie ne quitteraient jamais le courrier électronique de Motswordstore et le travail de messageriePasswordstore consiste à s'assurer que cela reste le cas - même si CyrilApp est compromis ou que le reste de vos serveurs est pwned par un attaquant, le courrier électronique doit empêcher. l'attaquant d'obtenir les mots de passe email. Vous pouvez exécuter l'e-mailpasswordstore sur une machine distincte (ou éventuellement dans une machine virtuelle séparée), avec un VPN entre CyrilApp et EmailpasswordStore et effectuer une revue de sécurité minutieuse du code e-mailpasswordstore.
Utilisez. Il ne suffit pas de stocker correctement les mots de passe de messagerie, car à un moment donné, vous voulez les utiliser. Si vous stockez simplement les mots de passe de messagerie dans un formulaire crypté, puis les déchiffrer lorsque vous souhaitez les utiliser, vous n'obtenez pas beaucoup de prestation de sécurité: un attaquant qui compromet votre application Web pourrait s'asseoir tranquillement et voler chaque mot de passe comme il est utilisé. , ou éventuellement même déchiffrer tous les mots de passe elle-même. Donc, vous avez besoin de contrôles d'utilisation.
L'architecture de messagerie électronique proposée énumérée ci-dessus fournit ces contrôles. Il utilise le mot de passe email lui-même et ne révèle jamais le mot de passe à votre application Web CyrilApp. Essayez de voir si vous pouvez faire quelque chose comme ça dans votre réglage.
restreindre l'accès. Enfin, vous voudrez peut-être limiter qui peut demander à EmailPasswordStore d'utiliser le mot de passe. Un bon point de départ est destiné à l'e-mailpasswordstore pour authentifier le service qui s'y connecte; Par exemple, vous pouvez configurer un VPN entre CyrilApp et e-mailpasswordStore et vous assurer que le courrier électroniquePasswordStore rejette toutes les autres tentatives de connexion.
Une architecture plus sophistiquée peut vérifier que l'identité de l'utilisateur actuellement connectée et restreindre l'accès à celui de ce mot de passe de messagerie. Par exemple, l'e-mailpasswordstore pourrait stocker une liste des mots de passe hachés que les utilisateurs utilisent pour vous connecter à CyrilApp et que CyrilApp envoie le mot de passe de connexion de l'utilisateur à e-mailpasswordstore pour une vérification avant de déverrouiller le mot de passe de l'email de l'utilisateur. Cependant, cela peut être inutile dans certains contextes.
lecture supplémentaire. Voir aussi Où puis-je stocker de manière sécurisée la clé d'un système sur lequel la source est visible? et Où stocker une clé pour le cryptage .
- Lorsque l'utilisateur se connecte via Frontend, le login et le mot de passe sont envoyés en clair (je recommanderai l'utilisation de HTTPS). Le backend essaiera de se connecter à la base de données, si cela réussit, il crypté le login et le mot de passe en utilisant Blowfish et les renvoyera vers le frontend.
Vous devriez plutôt utiliser un hachage salé.
- Pour toute demande ultérieure, le frontend devra envoyer le login/mot de passe crypté, sans jamais connaître le claire, juste le crypté. Si quelqu'un a accès aux données de cet utilisateur (XSS par exemple), il ne pourra accéder que les informations d'identification cryptées, et non le clair.
En implémentation de Blowfish en JavaScript? Si un attaquant connaissait le mot de passe crypté, il pouvait simplement désactiver JavaScript et envoyer cela sans connaître l'original.
- Si un attaquant peut faire un MITM, seule la connexion initiale est risquée, toutes les demandes suivantes seront avec les informations d'identification cryptées.
Si une personne tente de mitm https, vous obtiendrez un avertissement de certificat invalide (sauf qu'ils ont réussi à obtenir votre clé privée ou à la forger, cela est très improbable) auquel cas vous arrêtez simplement d'essayer de charger la page et aucun dommage n'est fait.
Votre serveur avant doit traiter de l'authentification et stocker des mots de passe cryptés. Le mot de passe haché sera comparé au hachage sur ce serveur.
Assurez-vous que votre mot de passe crypté est salé. De cette façon si les données sont volées, il sera plus difficile de se fissurer et des tables arc-en-ciel seront moins efficaces.
Le serveur Back End contiendra les mots de passe de texte clairs et n'acceptera que les connexions de votre réseau interne. Tout changement de mot de passe sera mis à jour ici d'abord, puis mis à jour sur le serveur avant.
Assurez-vous d'écrire des règles de pare-feu strictes pour ce serveur. Autoriser uniquement les mises à jour de ce serveur, déposer tous autres paquets.
Ce serveur ne devrait pas être en mesure d'être accès à partir d'Internet et devrait probablement être mis à jour par vos serveurs locaux.
Quant à Mitm, il n'y a rien d'efficacité pour empêcher cela.
J'ai vu une configuration où les mots de passe ont été cryptés avec RSA dans la DB backend avec leurs représentations de hachage et leur sel. La clé de déchiffrement a été conservée sur une machine séparée sans Internet. Il pourrait récupérer les mots de passe du backend les déchiffrer et les repousser crypté. Le serveur Backend pourrait alors appuyer sur les hachages sur le serveur avant. Le serveur FronTend était le seul à faire face à Internet.
Tout d'abord, [~ # ~] no [~ # ~ ~]. Il y a généralement une meilleure façon.
Par exemple, vous stockez votre mot de passe en tant que hachage et lorsque l'utilisateur se connecte et authentifie avec succès contre le hachage, vous détenez le mot de passe en mémoire de la session uniquement à l'aide de toutes les connexions à effectuer, puis oubliez le mot de passe. Dès que vous n'en avez plus besoin. Il n'est jamais stocké.
Deuxièmement, si vous besoin Pour stocker le mot de passe de certaines exigences absurdes, un bon moyen de le rendre semi-non désverrible consiste à utiliser Crypto de clé publique (par ex. E.G. RSA). Cryptage avec une clé publique (pour laquelle aucune clé privée n'est présente) n'est pas tout à fait différente de la hachage. Ce n'est pas aussi bon que le hachage, mais c'est Hella Beau meilleur que le cryptage symétrique (telle que Blowfish, AES, etc.), car le mot de passe pour le déchiffrer n'est pas présent. Ce qui me rappelle: la clé privée ne doit pas être accessible depuis l'environnement public, non sur le même serveur, pas sur le même réseau, etc. La clé privée ne doit être utilisée que pour toute urgence idiote que votre conception nécessite.
Mais notez que la crypto de clé publique comme couramment implémentée est une cryptographie symétrique avec une wrapper RSA. Sachez quels protocoles vous utilisez réellement.