Un fournisseur d'identité peut-il me faire passer pour moi? (Facebook peut-il publier des questions sur Stack Overflow sous mon nom?)
Il existe plusieurs mécanismes (certains maintenant disparus) qui me permettent d'accéder au service A (la partie utilisatrice/RP) à l'aide d'un jeton accordé par le service B (le fournisseur d'identité/IdP). En général, ceux-ci remplacent une connexion par nom d'utilisateur et mot de passe. Exemples de protocoles IdP:
- OpenID 2.0
- OpenID Connect
- IndieAuth
- Mozilla Persona
- Portier
- ... et bien sûr la connexion Google et la connexion Facebook
Qu'est-ce qui empêche l'IdP d'accéder à mon compte sur le RP? Un mauvais acteur disposant de privilèges d'administrateur système sur l'IdP peut sûrement:
- Faites une tentative de connexion au service A
- ... initier une demande de jeton de A à B
- Générer un jeton au service B (sans avoir besoin de mes informations d'identification)
- ... renvoie la réponse valide à A
- Accédez maintenant à mon compte sur A
Je pose une question générale, mais comme exemple concret , qu'est-ce qui empêche un mauvais administrateur Facebook de publier des questions Stack Exchange sous mon nom?
Croquis:
(Croquis adapté de https://developers.google.com/identity/protocols/OAuth2 mais notez que le protocole référencé n'est qu'un exemple .)
Oui, ils peuvent.
Réponse simple: vous vous authentifiez d'une manière ou d'une autre auprès de votre fournisseur d'identité, généralement via un nom d'utilisateur et un mot de passe. Le mauvais administrateur peut stocker les informations d'identification transmises et simplement les réutiliser. Cette attaque ne dépend pas de la façon dont le backend est implémenté.
En général, votre mot de passe pour le fournisseur d'identité n'est pas utilisé du tout pour l'authentification auprès de services tiers, ce qui signifie que votre fournisseur d'identité possède réellement vos clés de connexion (et vous ne les avez pas du tout).
Vous pourriez penser à des schémas qui intègrent votre mot de passe dans le processus d'authentification sans le stocker ensuite non crypté, mais dans la pratique, je ne connais aucun schéma de ce type.
TL; DR : Un mauvais administrateur Facebook qui peut usurper votre connexion Facebook peut publier de mauvaises choses sous votre nom sur Facebook, ce qui est généralement considéré comme pire que la publication une question sur Stack Exchange.
Ma réponse plus détaillée se concentre sur OAuth 2. qui est la norme de l'industrie pour ce cas d'utilisation et se trouve derrière l'esquisse d'autorisation de Google au PO1.
Le cadre OAuth 2.0 n'est pas destiné à l'origine uniquement à l'authentification, mais au cas d'utilisation plus général de l'autorisation: le service A souhaite accéder à certaines ressources appartenant à l'utilisateur du service B.
Par exemple, l'utilisateur possède à la fois un compte sur le service A (une application de retouche photo) et sur le service B (Google Drive). Avec OAuth 2.0, l'utilisateur accorde à l'application l'autorisation d'accéder à ses photos sur Goole Drive. Quelques points d'attention:
- Le service A doit être une application enregistrée sur le service B: dans l'exemple, le développeur a dû enregistrer son application de retouche photo sur Google Developer . Lors de l'initiation du flux d'autorisation, le service A s'identifie auprès du service B via l'ID client et le secret client (si le flux côté serveur) ou l'ID client et le nom d'hôte (si le flux côté client).
- Le service A redirige l'utilisateur vers le point de terminaison d'autorisation du service B, et l'utilisateur doit entrer les informations d'identification de son service B uniquement sur le service B. Le service A ne peut pas usurper la connexion pour le service B, car il ne le fait pas 'contrôlez pas le point de terminaison d'autorisation. Le service B ne peut pas usurper la connexion pour le service A, car elle n'est pas fournie par l'utilisateur.
- La réponse finale du jeton, que le service A peut utiliser pour accéder aux ressources de l'utilisateur sur le service B, est livrée avec une portée. Le service B autorise le service A à accéder uniquement aux ressources qui se trouvent dans la portée autorisée. La portée est expliquée à l'utilisateur dans la fenêtre d'autorisation vers laquelle il est redirigé. Dans l'exemple, la fenêtre d'autorisation de Google Drive expliquera quelque chose comme "Cette application de retouche photo peut voir et modifier vos photos sur Drive". Google autorisera alors l'application à accéder aux photos, mais pas à publier quelque chose sur Google Plus, car cela ne fait pas partie de la portée autorisée.
La connexion à un tiers est un cas spécial très courant, où la ressource détenue par l'utilisateur est ses informations de compte de base sur le service B. Au lieu d'exiger que l'utilisateur S'inscrire sur son service, le développeur a choisi de demander à Google de vérifier l'identité de l'Utilisateur.
Le système ne fonctionne que si
- Le service A fait confiance au service B
- L'utilisateur fait confiance au service B
Ce qui est bien, c'est que l'utilisateur n'a pas à faire confiance au service A.
Si l'utilisateur, cependant, fait plus confiance au service A qu'au service B, il ne doit pas utiliser la connexion tierce et s'inscrire sur le service A (lorsque l'option est disponible).
1 Message d'origine
Oui, ils peuvent. Mario a expliqué comment cela fonctionne techniquement. Je me concentrerai ici sur la partie trust.
Quelle que soit l'action que vous effectuez sur un ordinateur, cela implique la confiance. Vous faites confiance à l'éditeur OS de votre système et de votre téléphone. Vous faites confiance à tous les éditeurs de tous les programmes que vous y avez installés. Vous faites confiance à n'importe quel service en ligne que vous utilisez. Et vous faites confiance à votre banque pour ne rien faire sur votre compte (celui-ci va au-delà de l'informatique ...).
Mais il y a quelques degrés au niveau de la confiance. Je fais suffisamment confiance au système de réservation de vols pour leur acheter quelque chose, mais je ne leur fais pas confiance au point de donner mes informations bancaires. Quoi qu'il en soit, je fais suffisamment confiance à mon programme de coffre-fort pour les mots de passe.
Donc, dans une chaîne de confiance, ce qui compte, c'est: l'un des acteurs de la chaîne ne mérite-t-il qu'un niveau de confiance inférieur à l'action globale? Il est probablement correct d'utiliser un compte Facebook pour SO, le risque d'attaque et les conséquences possibles sont à mon humble avis compatibles avec la confiance que j'ai en Facebook. Mais je n'utiliserais jamais de compte Facebook pour ma banque (ils ne le proposent pas de toute façon). Et bien sûr, faire confiance à un système implique la confiance de l'un de ses administrateurs.