Suggestions sur le stockage des mots de passe dans la base

Question

est ici la situation - est un peu différent des questions base de données/mot de passe sur StackOverflow.com

J'ai deux groupes d'utilisateurs. L'un sont les utilisateurs "primaires". Les autres sont les utilisateurs "secondaires". Chacun a un identifiant/mot de passe sur mon site (disons mysite.com - ce n'est pas important). Contexte: Les utilisateurs principaux ont accès à un troisième site (par exemple www.quelquechose.com/PrimaireUtilisateur1). Chaque utilisateur secondaire "appartient" à un utilisateur principal et souhaite accéder à une sous-partie de cet autre site (par exemple, www.something.com/PrimaryUser1/SecondaryUser1). Sur mysite.com, les utilisateurs principaux doivent me fournir leurs informations d'identification qu'ils utilisent pour accéder à www.something.com/PrimaryUser1, et ils spécifient les «sous-parties» auxquelles les utilisateurs secondaires de leur choix ont accès.

Mysite.com aide à gérer le sous-accès des utilisateurs secondaires au site de l'utilisateur principal. Les utilisateurs secondaires ne peuvent pas "voir" le mot de passe de leur utilisateur principal, mais via mon site, ils peuvent accéder aux "sous-parties" de l'autre site - mais SEULEMENT à leur sous-partie restreinte.

D'une manière grossière, j'implémente OAuth (ou quelque chose comme ça).

La question ici est - comment dois-je stocker les informations d'identification de l'utilisateur principal à l'autre site? Le point clé ici est que mysite.com utilise ces informations d'identification pour fournir un accès aux utilisateurs secondaires, donc il DOIT être capable de le lire. Cependant, je veux le stocker de telle manière, que les utilisateurs primaires sont rassurés que je (en tant que propriétaire du site) ne peut pas lire leurs informations d'identification. Je suppose qu'il s'agit davantage d'une question d'approche théorique. Y a-t-il quelque chose dans le monde de la cryptographie qui puisse m'aider avec ça?

---

Texte ajouté:

Comme la plupart ppl sont complètement absents de la question, voici tentative # 2 à l'expliquer.

PrimaryUser1 a un nom d'utilisateur/mot de passe pour www.something.com/PrimaryUser1Site

Il souhaite donner sous-accès à deux personnes- SecondaryUser1 et SecondaryUser2 au www.something.com/PrimaryUser1Site/SecondaryUser1 folders- et www.something.com/PrimaryUser1Site/SecondaryUser2

Mysite.com s'occupe de la gestion de ces sous-utilisateurs, ainsi PrimaryUser1 s'y rend et fournit ses informations d'identification à Mysite.com. MySite.com utilise en interne les informations d'identification fournies par PrimaryUser1 pour donner aux sous-utilisateurs un accès limité. Maintenant, SecondaryUser1 et SecondaryUser2 peuvent accéder à leurs dossiers respectifs sur www.something.com/PrimaryUser1Site via MySite.com

Maintenant, la question se pose, comment dois-je stocker les informations d'identification fournies par PrimaryUser1?

Answer 1

Cela dépend du type d'authentification sur lequel votre site principal et le site secondaire sont d'accord. Est-ce l'authentification par formulaire, HTTP Basic ou HTTP Digest? Si est des formulaires ou de base, alors vous n'avez pas le choix, vous devez stocker le mot de passe, de sorte que votre seul choix est de le crypter. Vous ne pouvez pas stocker un hachage de mot de passe car vous devez présenter le texte en clair pendant l'authentification pour les formulaires et HTTP Basic. Les problèmes qui découlent du stockage du mot de passe crypté sont dus soit à l'utilisation incorrecte de la cryptographie (vous n'utilisez pas d'IV ou de sel ou vous n'utilisez pas correctement un cryptage de flux), mais plus important encore, vous aurez la gestion des clés problèmes (où stocker la clé utilisée pour crypter les mots de passe et comment y accéder à partir d'un service/démon non interactif).

Si le site 3ème partie accepte HTTP Digest, alors vous êtes plus de chance, vous pouvez stocker la HA1 hash partie du hachage Digest (ie. MD5 de username:realm:password) parce que vous pouvez construire la réponse Digest à partir de HA1 droite.Je n'ai pas expliqué comment l'utilisateur fournit les informations d'identification secondaires (c'est-à-dire comment obtenir le nom d'utilisateur et le mot de passe du site secondaire en premier lieu), je suppose que vous avez sécurisé un canal protégé. site). Par conséquent, cela suppose que l'authentification se produit entre votre site principal et le site secondaire et que le contenu du site secondaire est mis en tunnel via une requête HTTP effectuée sur le site principal. Si ce n'est pas le cas et que le site secondaire est effectivement accessible depuis le navigateur, le site secondaire doit prendre en charge une sorte d'autorisation basée sur des jetons pré-authentifiés de tiers comme OAuth. S'appuyer sur l'authentification des informations d'identification et stocker les informations d'identification sur le site principal lorsque les informations d'identification sont réellement requises par le navigateur a tellement de problèmes que cela ne vaut même pas la peine d'en parler.

Answer 2

Avez-vous pensé à accepter OpenID comme Stack Overflow? De cette façon, vous n'êtes pas responsable du stockage des mots de passe.

Answer 3

il a obtenu une meilleure façon d'expliquer ce :(

mais si vous voulez juste savoir comment stocker les mots de passe en toute sécurité faire ceci:

Nom d'utilisateur: john, mot de passe: passe

key = '!! @ ijs09789 ** & *';

md5 (username.password.key);

quand ils se connecter simplement vérifier pour voir si md5 (username.password.key) = est égal à celui de la base de données - vous pouvez également utiliser sha1 et/ou toute autre méthode de cryptage.

http://us.php.net/md5 & http://us.php.net/sha1

Answer 4

Il n'y a qu'une seule façon de le faire, et il est probablement trop burdomesome pour les utilisateurs.

Vous pouvez crypter le mot de passe des utilisateurs avec une clé publique/privée, l'utilisateur conserve sa clé afin que le mot de passe ne puisse être déchiffré que lorsque la clé est renvoyée à votre serveur. La seule façon de rendre cela simple serait d'avoir des plugins de navigateur Web qui soumettent automatiquement les informations.

Et de toute façon, vous pouvez toujours renifler la communication vers/depuis le serveur, donc c'est toujours inutile.

Answer 5

Si vous souhaitez stocker le mot de passe vous-même, la meilleure solution consiste à utiliser un algorithme de hachage unidirectionnel tel que MD5 ou SHA-1. L'avantage de cette approche est que ne peut pas dériver le mot de passe de la valeur hachée.

L'algorithme que vous choisissez dépend précisément des produits que vous utilisez. Certains outils frontaux offrent ces fonctions, tout comme certains produits de base de données. Sinon, vous aurez besoin d'une bibliothèque tierce.

Modifier

Les utilisateurs secondaires doivent avoir leurs propres passowrds. Pourquoi ne le feraient-ils pas?

Answer 6

Ne stockez jamais les mots de passe dans une base de données mais stockez une salée et hachée version de chaque mot de passe.

Cochez cette case article si c'est chinois pour vous.

Answer 7

Première règle: Jamais, jamais stocker des mots de passe! Deuxième règle: Calculez un mot de passe avec un mot de passe supplémentaire, et stockez-le dans votre base de données. Troisième règle: Un nom d'utilisateur (majuscule) peut être utilisé comme sel, mais de préférence ajouter un peu plus de sel! (Quelques textes supplémentaires, de préférence quelque chose de long.) Quatrième règle: Peu importe la sécurité d'un algorithme de hachage, ils seront tous piratés tôt ou tard. Tout ce qu'il faut c'est du temps! Cinquième règle: La sécurité de votre site dépend de la valeur de ce qui se cache derrière. Plus la valeur du contenu est élevée, plus vous risquez d'être attaqué! Sixième règle: Vous découvrirez, tôt ou tard, que votre site est piraté mais pas par un mot de passe piraté, mais par une échappatoire ailleurs dans votre code. Le plus gros risque est que votre site soit sécurisé maintenant que vous avez mis en place une sécurité renforcée. Septième règle: Toute sécurité peut être brisée, tous les sites peuvent être piratés, tous vos secrets peuvent être découverts, si seulement les gens sont prêts à investir suffisamment de temps pour le faire.

La sécurité est une illusion mais tant que personne ne la brise, vous pouvez continuer à rêver! Soyez toujours prêt pour les éveils qui nécessiteront de reconstruire votre illusion. (En d'autres termes, faites des sauvegardes régulières! (De préférence tous les jours.) Ne remplacez pas les sauvegardes de la semaine dernière et assurez-vous de conserver au moins une sauvegarde par semaine, au cas où vous découvriez que votre site a été piraté il y a des mois. Maintenant, si vous avez vraiment besoin de stocker des mots de passe, utilisez un hash sur le nom d'utilisateur plus le mot de passe, puis hachez de nouveau avec du hash et du sel! Mieux encore, créez une liste de sels (juste une liste de mots) et chaque fois qu'un nouveau compte d'utilisateur est créé, choisissez un mot sel aléatoire à utiliser pour hacher son nom d'utilisateur plus mot de passe.Ranger l'index du sel avec le compte d'utilisateur afin que vous sachiez lequel utiliser quand il se connecte à nouveau

Et: Huit règle: Toujours utiliser HTTPS! Ce n'est pas aussi sécurisé que la plupart des pe chose ople mais ça donne un sentiment de sécurité à vos utilisateurs!

---

Puisque vous avez ajouté du texte, j'ajouterai plus de réponse.

Puisque vous voulez que l'utilisateur1 accorde un accès temporaire à l'utilisateur 2, vous aurez besoin d'une table utilisateur secondaire. (Ou développez la table utilisateur avec un ID utilisateur parent. Ajoutez également un horodatage pour garder une trace de l'âge du compte utilisateur 1 peut créer les informations d'identification, ce qui est fait de la manière normale.Il suffit de stocker un hachage avec nom d'utilisateur combiné et sel. Dans ce cas, utilisez le nom d'utilisateur de l'utilisateur 1 comme sel supplémentaire Assurez-vous de désactiver le compte utilisateur 2 lorsque l'utilisateur 1 se déconnecte ou quand un certain laps de temps s'est écoulé. il a créé, afin de pouvoir réutiliser un compte au lieu de devoir en créer de nouveaux tout le temps

La sécurité ne dépend pas des utilisateurs primaires ou secondaires En général, traitez-les de la même façon! les utilisateurs ont un bonus supplémentaire que vous pouvez utiliser le compte principal comme sel supplémentaire.Le reste de celui-ci n'a plus rien à voir avec l'authentification.Il est l'autorisation que vous avez affaire. d autorisation ont une relation forte, sachez que vous devez les traiter comme deux techniques différentes et autonomes.

Lorsque l'utilisateur 1 se connecte, il a accès au site principal. Lorsqu'il accorde l'accès à l'utilisateur 2, l'utilisateur 2 obtient un ensemble réduit de rôles. Mais cela n'a rien à voir avec le stockage des noms d'utilisateur ou des mots de passe. Vous venez d'avoir un ID utilisateur qui se trouve être membre de certains rôles ou groupes. Ou pas, mais ceux-ci seraient inaccessibles.

Ils sont tous les deux juste des utilisateurs, l'un avec plus de droits que l'autre.

Answer 8

Vous le rendez trop complexe. Vous devez arrêter d'essayer de mélanger l'authentification et l'autorisation.

Ce que vous voulez faire est d'établir des informations d'identification pour tout le monde, ne vous inquiétez pas à ce stade si elles sont des utilisateurs "primaires" ou "secondaires". Ensuite, sur le site principal, où vous gérez les utilisateurs et les relations primaires/secondaires, vous pouvez faire la logique selon laquelle les utilisateurs sont primaires ou secondaires et stocker tout cela dans une table. Vous accordez ou refusez tous les droits et sous-droits que vous souhaitez à chaque utilisateur secondaire lorsque les utilisateurs principaux mettent à jour leurs relations avec eux. Une fois l'opération terminée, vous devez enfin répliquer les informations d'identification utilisateur appropriées du site principal sur le ou les sites secondaires.

Ensuite, lorsqu'un utilisateur secondaire veut se diriger vers n'importe quel site de votre batterie, il ne s'authentifie que comme lui-même - il n'emprunte jamais l'identité de l'utilisateur principal! Et ils n'ont que les droits que vous leur avez accordés lorsque les utilisateurs primaires leur ont donné le statut "secondaire".

-

OK, puisque vous avez tiré cette solution dans le commentaire, considérez ceci:

D'abord, je doute quelque chose sera vraiment sûr. Vous pouvez toujours récupérer le secret si vous surveillez l'activité des utilisateurs.

Maintenant, cela est complètement hors de la manchette, et je ne l'ai pas cryptanalyzed, mais vérifiez dans ce qu'on appelle un schéma secret sharing. Stockez le mot de passe de l'utilisateur principal du site principal "effectif" ou "réel" en tant que secret partagé. Utilisez le hachage salé du mot de passe donné par l'utilisateur principal comme un secret. Utilisez le hash salé du mot de passe donné par le premier utilisateur secondaire comme un autre secret, et ainsi de suite pour chaque utilisateur secondaire supplémentaire. Ne stockez pas les hachages salés! Rangez simplement le sel et le secret partagé protégé. Lorsqu'un utilisateur entre son mot de passe, vous récupérez le secret partagé protégé, utilisez le mot de passe et le hash de son mot de passe pour produire le hachage salé, décryptez le secret partagé protégé et vous avez maintenant le mot de passe principal d'origine.