Question:
Quels sont les principaux avantages et inconvénients de webid par rapport à browserid?
Hendrik Brummermann
2011-07-18 03:39:35 UTC
view on stackexchange narkive permalink

Quels sont les principaux avantages et inconvénients de webid par rapport à browserid?

Cette question est inspirée de cette réponse qui a obtenu un certain nombre de votes positifs en dépit d'être très vague sur le sujet de cette question.

Webid est fondamentalement un nom sophistiqué pour les certificats côté client SSL avec une URL de profil.

Quelques sujets:

  • Comment les clés compromises sont-elles invalidées?
  • Comment fonctionne la prise en charge de plusieurs appareils / navigateurs? Si celles-ci aboutissent à plusieurs clés publiques, comment sont-elles liées? Le lien doit-il être fait pour chaque consommateur?
  • Quelle est la compatibilité avec les navigateurs actuels? L'interface utilisateur est-elle suffisamment simple pour être comprise par les utilisateurs moyens (y compris la création, la sélection, la révocation de l'ordinateur actuel et la révocation globale d'une identité)?
  • Existe-t-il une organisation centralisée capable de suivre les utilisateurs? Existe-t-il des organisations décentralisées qui peuvent suivre les utilisateurs? Dans quelle mesure le suivi peut-il être détaillé?
  • Dans quelle mesure est-il facile pour un consommateur de mettre en œuvre correctement? (Lisez quelle est la probabilité qu'une implémentation paresseuse contienne des problèmes de sécurité?)
  • Comment fonctionne-t-elle sur les terminaux Internet sur lesquels vous ne disposez pas des autorisations pour installer le logiciel (en supposant que vous acceptiez le risque qu'il soit compromis)?
très intéressant. Comment cela se rapporte-t-il par exemple à CardSpace?
Trois réponses:
bblfish
2011-07-18 18:27:52 UTC
view on stackexchange narkive permalink

note: beaucoup de ces questions du côté WebID sont traitées dans la FAQ Foaf + ssl.

BrowserID contre WebID: la distinction est-elle réelle?

BrowserId ( spec détaillée) est une expérience chez Mozilla labs, est très nouvelle, pas entièrement définie ( la manière exacte de trouver la clé publique des serveurs de messagerie n'est pas spécifiée par exemple) et n'est pas complètement implémentée (elle nécessite le support du navigateur pour être réellement distribuée). Le protocole WebId est en cours de développement dans un groupe d'incubateurs du W3C, en s'appuyant sur le protocole anciennement connu sous le nom de foaf + ssl. Il évolue donc également. Ces deux protocoles ont été présentés lors de l'atelier W3C Identity in the Browser Workshop au bureau de Mozilla en Californie en mai 2011

De plus, il n'est pas clair que les deux projets soient incompatibles - ou plutôt n'est qu'une question de sémantique si elles le sont. On peut distinguer deux dimensions dans lesquelles elles diffèrent: une authentification et une sérialisation.

  • vérification d'identité : vérification de la signature de certificat (BrowserId) ou vérification de la clé publique du sujet (WebId / foaf + ssl)
  • format de certificat : formats JSON (BrowserId) ou X509 (foaf + ssl) pour les certificats

Actuellement, BrowserId a été défini par la paire (vérification de la signature du certificat, certificat JSON) et WebID / foaf + ssl par la paire (vérification de la clé publique de l'utilisateur, certificat X509) comme décrit dans cet e-mail

Mais il n'y a pas de raison logique pour que l'on ne puisse pas aussi avoir les deux autres combinaisons:

  • (vérification de signature de certificat, cert X509) - c'est-à-dire une authentification BrowserId faite avec TLS
  • (vérification de la clé publique de l'utilisateur, certificat JSON) - c.-à-d. authentification WebID effectuée avec des certificats JSON.

On pourrait également avoir les deux stratégies pour chaque type de certificat. C'est-à-dire que l'on pourrait d'abord vérifier la signature du certificat, puis, si nécessaire, également vérifier le WebID. Cela peut être utile pour obtenir plus d'informations sur l'utilisateur (un échange d'attributs RESTful) et il peut également être utile de vérifier que la clé n'a pas été révoquée.

La question que nous traitons ici est vraiment: quels sont les avantages et les inconvénients de l'authentification BrowserId "pure" par rapport à un WebID "pur" - également appelé authentification foaf + ssl. Veuillez garder cela à l'esprit pour le reste de cette réponse.

Comparaison de Pure BrowserId et WebId / foaf + ssl

Réponse en indiquant la situation en juillet 2011.

Comment les clés compromises sont-elles invalidées?

Dans WebID, elles sont supprimées de la page de profil. Une bonne interface utilisateur en ferait une affaire en un seul clic. L'utilisateur accède à son réseau social après s'être connecté - peut-être avec une clé unique qui lui est envoyée via son téléphone portable - et supprime la clé publique compromise, qu'il pourrait reconnaître par son nom, l'ordinateur sur lequel il l'a générée ou un autre manière qui rend les choses faciles à retenir.

BrowserId utilise actuellement un certificat JSON avec une période de validité, que le protocole souhaite actuellement limiter à très court terme. La raison pour laquelle le certificat | (JSON) doit être de très courte durée est que la partie de confiance dans la spécification BrowserID actuelle ne peut vérifier le certificat qu'en vérifiant sa signature avec la clé publique du fournisseur de messagerie. Plus le certificat est valide, plus il est probable que quelque chose ait mal tourné dans le sens - par exemple, l'ordinateur de l'utilisateur aurait pu être volé.

Mais si BrowserId devait être combiné avec WebID (ie : le certificat JSON devait contenir un nom de sujet http (s)), alors des clés plus durables pourraient être utilisées: les parties utilisatrices pouvaient vérifier que les clés n'avaient pas été compromises en vérifiant le profil public de l'utilisateur.

Comment fonctionne la prise en charge des navigateurs multi-appareils?

WebID et BrowserId peuvent avoir plusieurs clés publiques.

Avec WebID / foaf + ssl, chaque clé publique est publiée dans la page de profil, comme on peut le voir dans la vidéo "Création et utilisation de WebId en 4 minutes". Chaque appareil / navigateur peut avoir son propre certificat pour le même WebID. L'authentification de l'utilisateur se fait en vérifiant que la clé publique dans le certificat correspond à l'une des clés publiques publiées sur la page de profil WebID.

BrowserId enregistrera la clé dans le trousseau du navigateur / OS une fois que cette partie sera intégré dans le navigateur. La partie utilisatrice vérifie un certificat en vérifiant que l'émetteur a vraiment signé le certificat, et non par une comparaison octet par octet des certificats. Ainsi, n'importe quel certificat peut être utilisé, tant que la signature est authentique.

Si ceux-ci aboutissent à plusieurs clés publiques, comment sont-elles liées?

Dans BrowserId, la clé publique de l'utilisateur Le certificat est uniquement utilisé pour vérifier que le client dispose de la clé privée correspondante dans le processus d'authentification. Il n'y a pas de lien en cours.

Avec WebID, les différentes clés publiques peuvent être publiées sur la page Profil et peuvent-elles y être liées. Certaines de ces clés pourraient être décrites comme durables et donc également utilisées pour la signature et le décryptage.

Le lien doit-il être fait pour chaque consommateur?

Dans le WebID pur, chaque profil a besoin pour publier chaque clé publique. Le profil peut n'être rien de plus que la publication de cette clé.

BrowserID ne nécessite que le serveur de messagerie pour publier sa clé publique.

Comment est le support dans les navigateurs actuels?

Tous les navigateurs de bureau supportent la sélection de certificat X509 depuis 1998 environ. (à quelques exceptions près comme les premières versions de Chrome) Les téléphones portables sont plus inégaux. page wiki

Pour que BrowserId fonctionne de manière décentralisée, il a besoin du support du navigateur. Ceci est actuellement absent, mais il a une chance d'être déployé car il est pris en charge dans les laboratoires Mozilla.

L'interface utilisateur est-elle suffisamment simple pour être comprise par les utilisateurs moyens (y compris la création, la sélection, la révocation de l'ordinateur actuel et la révocation globale d'une identité)?

  • Création : Dans les deux cas, c'est une affaire d'un seul clic. Avec WebID X509, les certificats peuvent être générés à l'aide de l'élément keygen html5 et d'une solution de contournement IE ActiveX. L'utilisateur a juste besoin de cliquer sur un gros bouton - voir la vidéo WebID & Browsers ou celle ci-dessus "création et utilisation d'un identifiant Web". Les interfaces utilisateur pourraient être améliorées bien sûr avec de meilleurs concepteurs Web.
  • Sélection :
    • WebId: la sélection est excellente sur Chrome, Safari, Opera et IE mais moche - mais pas impossible à utiliser dans Firefox. Pourquoi ils ne se donnent pas la peine de résoudre ce problème est un mystère. Veuillez voter pour le bug 396441 - Amélioration de l’interface utilisateur d’authentification client SSL. Il y a beaucoup à faire pour améliorer l'interface utilisateur, mais des navigateurs imparfaits n'ont jamais empêché les internautes créatifs de l'utiliser de manière créative.
    • BrowerId: la sélection peut être conçue par le site Web, bien que cela puisse en créer davantage. risques de sécurité, et ne fournira pas une interface utilisateur d'authentification cohérente sur tous les sites (d'où un risque de physching possible)
  • Révocation de l'ordinateur actuel
    • WebID: la suppression des certificats X509 de l'ordinateur actuel est quelque chose qui devrait être évité, et l'interface utilisateur devrait certainement être améliorée.
    • BrowserId: la révocation de l'ordinateur actuel n'est pas encore définie comme elle l'a fait pas été mis en œuvre.
  • Révocation globale de l'identité
    • WebID: cela nécessite simplement que la page de profil renvoie l'un des codes d'erreur HTTP si le l'identité doit être complètement supprimée, ou une redirection HTTP si le profil est déplacé, ou une relation d'identité sémantique entre l'ancienne et la nouvelle identité, ou simplement la suppression d'une des clés publiques du profil si un certificat a été volé.
    • BrowserId se protège avec des certificats de courte durée (basés sur JSON)

Existe-t-il une organisation centralisée capable de suivre les utilisateurs?

  • WebID: il peut être complètement décentralisé. Vous pouvez placer votre WebId sur votre FreedomBox, ainsi que tous vos amis. Vous pouvez également le placer sur un serveur anonyme si vous avez fait confiance à ce service.
  • BrowserId: lorsque le magasin de certificats JSON est intégré au navigateur - et que l'on n'a plus besoin d'utiliser browserid.org, chaque e-mail le fournisseur pourrait participer. Comme les Freedom Boxes peuvent également être des fournisseurs de messagerie électronique, elles peuvent également être des autorités.

Existe-t-il des organisations décentralisées qui peuvent suivre les utilisateurs?

Des exemples de ce à quoi cela ressemblerait ?

Dans quelle mesure le suivi peut-il être détaillé?

Avec BrowserId, la partie utilisatrice récupère la clé publique du fournisseur de messagerie. Tout ce que le fournisseur doit savoir, c'est qu'un serveur a fait une requête GET. C'est quelque chose qui peut valoir la peine d'être intégré dans WebID. D'un autre côté, la partie utilisatrice se retrouve avec une adresse e-mail qui pourrait être utilisée à des fins de spam.

Avec WebID - une demande de la partie utilisatrice est effectuée sur la page de profil. Cette demande peut être effectuée de manière anonyme, via un proxy ou même un proxy IP.

Est-il facile pour un consommateur d'obtenir la bonne implémentation?

WebID sur TLS nécessite plus pour configuré pour la partie de confiance, y compris un serveur SSL. Ce serveur ne doit pas effectuer l'authentification habituelle des certificats côté client. En revanche, il est plus sûr, car il force TLS. Il existe de nombreux outils TLS qui ont été testés au fil du temps, et qui continuent à être testés.

BrowserId ne nécessite pas TLS sur la partie de confiance, il est donc plus facile à configurer. D'autre part, il y a des attaques de l'homme au milieu possibles si TLS n'est pas configuré.

(Mais à ce stade, il faut remarquer qu'il n'y a aucune raison profonde pour laquelle BrowserID et WebID ne peuvent pas à la fois utiliser le nouveau format de certificat JSON proposé et combiner leurs forces. > Comment ça marche sur les terminaux Internet sur lesquels vous ne disposez pas des autorisations pour installer le logiciel (en supposant que vous acceptiez le risque de compromission)?

Les terminaux Internet sont toujours dangereux. Seules les clés cryptographiques pourraient rendre le risque acceptable. En plaçant complètement la clé dans le matériel, le risque de vol de la clé privée est supprimé. voir WebId et le Crypto Stick. Sinon, les clés de très courte durée sont une solution de limitation des dommages si WebID ou BrowserId doit être utilisé. Les deux protocoles peuvent fonctionner avec des clés à court terme.

Peut-être qu'OpenId est mieux combiné ici avec des mots de passe uniques transmis par un téléphone portable.

Réponse très bonne et détaillée.
Vous avez une section de résumé tl; dr?
Semble que BrowserID a été renommé en "Persona" et est en version bêta publique.
D.W.
2011-07-18 06:52:25 UTC
view on stackexchange narkive permalink

Voici la sagesse conventionnelle que j'ai toujours entendue à propos des certificats côté client: les certificats côté client ne sont pas bien pris en charge par les navigateurs actuels. L'interface utilisateur n'est pas facilement compréhensible pour les utilisateurs ordinaires. Par conséquent, ce n'est pas vraiment une option viable pour les masses.

le problème est que la sagesse conventionnelle ne tient pas compte de WebID. C'est-à-dire: cela vient d'un type de réflexion qui suppose qu'un certificat est précieux, doit être déplacé d'un client à un autre et ne peut être utilisé qu'avec un seul site Web, à moins que l'on soit dans l'armée. Toutes ces hypothèses sont fausses. Mais il est vrai que Firefox a une interface utilisateur assez moche. Cela peut être corrigé. [Images de quelques boîtes de sélection de certificats] (http://www.w3.org/wiki/Foaf%2Bssl/Clients/CertSelection)
Merci @bblfish,. Oui, l'interface utilisateur laide et déroutante est la partie à laquelle je faisais référence. La partie "déroutante" est sans doute plus problématique que la partie "laide".
oui, l'implémentation laide est celle de Firefox. Ils pourraient résoudre ce problème en environ 1 jour de codage.
il existe également de nombreux pièges dans lesquels on peut tomber avec les certificats côté client. Par exemple, un serveur peut refuser l'accès si l'utilisateur n'est pas autorisé, sans donner aucune explication. Si un serveur est configuré de cette façon, ce ne sera pas une bonne expérience. Le serveur doit permettre à l'utilisateur 1. de voir quelle identité il a utilisée s'il s'est connecté même s'il n'est pas autorisé à voir cette ressource 2. d'expliquer ce qu'il doit faire pour être autorisé (devenir l'ami de quelqu'un peut-être), 3. changer de certificat sur demande et pas avant d'avoir vu le premier site Web. Le WebID XG rédigera quelques directives à ce sujet.
Daniel
2012-09-26 20:36:00 UTC
view on stackexchange narkive permalink

Exigences de sécurité, de confidentialité et d'utilisabilité pour l'identité fédérée par Michael Hackett et Kirstie Hawkey fournit une comparaison entre WebID et Mozilla Persona, qui à l'époque était encore appelé BrowserID.

Les principales différences notées (dans le tableau 1) sont:

  • Les clés personnelles sont de courte durée et devraient être protégées par un mot de passe. Les clés WebID ont une longue durée de vie, mais peuvent facilement être désactivées à partir d'un profil protégé par mot de passe.
  • L'implémentation actuelle de Persona utilise des fenêtres de navigateur standard, il est donc difficile de détecter l'usurpation d'identité (cela peut changer une fois que les navigateurs bénéficient du support natif de Persona). WebID utilise l'interface utilisateur de sélection de certificat native du navigateur, donc aucune chance d'hameçonnage.
  • Les identités Persona et WebID peuvent être compromises si le contrôle sur l'adresse e-mail / URI du propriétaire est perdu.
  • Les IdP de Persona ont aucune connaissance des SP qui utilisent une identité. Les IdP WebID connaissent chaque SP qui utilise une identité.
  • Si un SP Persona a un cache de la clé publique de l'IdP et que le navigateur a toujours un certificat valide, il devrait toujours être possible de vérifier les identités. Les profils WebID doivent être accessibles, sinon les identités ne seront pas utilisables.
  • Persona a une bonne conception UX, alors que WebID est le contraire.

Je suggère de lire l'article pour plus de détails . Il est disponible gratuitement en ligne, aucun accès à la bibliothèque numérique n'est nécessaire.

Bon résumé - vous pourriez envisager de partager ceci sur certaines des autres questions qui m'ont conduit ici: http://security.stackexchange.com/questions/5323/what-are-the-downsides-of-browserid-compared-to-openid -oauth-facebook / 5390 # 5390 et http://stackoverflow.com/questions/6712897/is-browserid-secure?rq=1
N'hésitez pas à le partager vous-même :-)
C'est comme voler les votes positifs que j'attends de vous. Je suppose que si vous n'êtes pas intéressé par le partage ...
Vous avez fait le travail pour mettre deux et deux ensemble, je ne l'aurais pas fait si ce n'était pas pour vous! Ce sont tous des Creative Commons sous licence, alors allez-y.


Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...