Je suppose qu'il n'y a pas vraiment de bonne solution pour les sites Web de tous les jours (par exemple, les sites peu connus tels que les banques pour lesquels les utilisateurs acceptent et économiques permettent une authentification à deux facteurs). On ne peut choisir qu'une solution qui a le moins d'impact négatif possible.

Malheureusement, les gens ne sont pas doués pour se souvenir d'un grand nombre de mots de passe. Il en résulte soit qu'ils réutilisent le même mot de passe sur différents services, soit qu'ils les écrivent (sur papier ou dans un gestionnaire de mots de passe). Oui, il est conseillé de créer un système de mot de passe incluant le nom du site.

Mais les gens sont paresseux. La réutilisation du mot de passe est pire qu'un compte central car cela signifie qu'une vulnérabilité dans n'importe quelle application révèle le mot de passe.

Dans le jeu Stendhal, la plupart des piratages de compte sont effectués par des membres de la famille. Je suppose que c'est spécial pour les jeux. Le groupe suivant consiste à deviner au hasard les noms d'utilisateur / mots de passe. Mais il existe un petit nombre de tentatives de piratage basées sur l'accès au compte de messagerie . Bien que nous n'autorisions pas la réinitialisation automatique du mot de passe par courrier électronique, de nombreux sites Web le font. La haute direction de Twitter a été piratée en exploitant un compte de messagerie Hotmail expiré et des mots de passe réutilisés.

Donc, si vous envisagez d'autoriser la réinitialisation du mot de passe par e-mail, il y a peu de risque supplémentaire à déléguer le processus d'authentification aux grandes entreprises. Tous ont mis en place des mesures pour rendre la tâche plus difficile pour les attaquants (récupération via les messages du téléphone mobile en cas d'activité suspecte, historique de connexion, avertissements sur les tentatives de connexion d'autres pays, etc.). Les implémenter dans votre propre site demande beaucoup de travail.

Sur une note personnelle, j'aurais préféré l'approche Account Manager ( spécification ) plutôt que de faire confiance à l'une de ces entreprises. De plus, il n'a pas le problème du phishing. Malheureusement, le projet ne semble pas progresser.

En fin de compte, nous avons décidé pour Stendhal de prendre en charge à la fois OpenID et les comptes locaux et de laisser les utilisateurs décider.

Du point de vue de la sécurité, il est presque toujours préférable d'avoir un mécanisme qui a fait ses preuves que de rouler le vôtre. Les erreurs d'implémentation sont l'un des moyens les plus courants de briser un bon concept de sécurité.

Du point de vue de la convivialité, je préfère légèrement oauth, c'est simplement facile à utiliser, donc pour vos utilisateurs finaux, c'est un énorme avantage. Un utilisateur non technique moyen est découragé par la sécurité manifeste, donc minimiser l'intrusion des fonctionnalités de sécurité est une victoire pour les sites avec un grand nombre d'utilisateurs.

Le risque de phishing n'est pas vraiment plus grand - les gens ne le font pas. Ne faites pas attention à la source des e-mails de toute façon :-)

Les avantages de systèmes comme OAuth sont les suivants:

• il y a moins de bases de données dans le monde stockant les informations de connexion d'un utilisateur. Si l'on considère un service comme Twitter, cela signifie que votre nom d'utilisateur et votre mot de passe ne sont connus que de Twitter et non de Favstar, Amazon, LinkedIn, New York Times et toutes les autres applications qui s'ajoutent au service.
• comme le dit @Rory, le système est largement utilisé et a été testé et (espérons-le) sécurisé dans une mesure appropriée.

Ces deux avantages répondent à votre point 1: OK donc tous ces services utilisent le même mot de passe, mais ils le doivent quand même car ils doivent tous utiliser votre compte Twitter, il est donc préférable de s'assurer que ces informations d'identification "universelles" ne sont pas stockées dans divers endroits avec diverses mesures de protection.

L'inconvénient principal n'est pas différent de l'inconvénient affectant toutes les interfaces utilisateur de connexion: n'importe qui peut créer une interface utilisateur qui ressemble à cela et l'utiliser pour obtenir vos informations d'identification.

Sans un scénario et un modèle de menace spécifiques à l'esprit, il est difficile de répondre à votre question.

Mais une victoire claire est le cas d'utilisation OAuth classique. Il s'avère que les utilisateurs sont incroyablement disposés à donner à un site Web leur mot de passe pour un autre site Web, par exemple. leur mot de passe Google vers un site de réseautage social comme Shelfari. Et comme Kalsey le note, ils étaient parfois horriblement surpris de ce que Shelfari faisait avec ce mot de passe, et comme Shelfari pouvait totalement se faire passer pour eux, Google ne pouvait pas facilement arrêter les abus.

Maintenant, avec OAuth, une application comme Shelfari n'obtiendrait qu'un accès partiel via une API à la base de données de contacts de l'utilisateur, et Shelfari utiliserait une clé API que Google pourrait facilement révoquer.

Dans le monde réel, les utilisateurs sont très susceptibles de réutiliser les mots de passe sur plusieurs sites , donc votre attaque en # 1 a une chance de fonctionner à de nombreux endroits comme elle est. En fait, nous pouvons espérer que les utilisateurs utiliseront un meilleur mot de passe pour leur important site OpenID, ou utiliseront un authn à 2 facteurs, ou autre.

Quant au n ° 2, le point avec les connexions OpenID est que cela devient inhabituel pour parcourir un site qui pense que vous n'êtes pas connecté, lorsque vous constatez que vous êtes connecté à vos autres sites Web. D'un autre côté, il est déjà simple sans OpenID ou OAuth de faire ressembler un site à Twitter, de créer un lien vers le site et d'espérer convaincre les gens de s'y connecter et de saisir leurs mots de passe. Si les gens sont toujours connectés à Twitter (par exemple pour d'autres sites via OAuth ou OpenID), ils sont susceptibles de demander pourquoi ils ne sont pas déjà connectés.

A écrit ceci à propos de l'ID fédéré.

En gros, vous parlez du problème de risque centralisé ou des clés du royaume. Cela s'applique également aux gestionnaires de mots de passe, mais la sécurisation d'un petit nombre de systèmes d'identité et d'authentification est beaucoup plus facile et plus efficace que d'avoir des centaines de mots de passe faibles (ou le même mot de passe faible cent fois). Les fournisseurs Open-ID comme Google proposent désormais une authentification à deux facteurs; si vous n'aimez pas les jetons logiciels sur votre téléphone, les jetons matériels USB Yubikey sont également pris en charge par de nombreux fournisseurs Open-ID. Le contrôle et l'audit sont également grandement améliorés; connaissez-vous toutes les applications où vous avez utilisé un mot de passe? Moi non plus. Pourtant, de nombreux fournisseurs Open-ID ont tous les sites sur lesquels vous avez accordé l'accès à cette identité, la révocation de l'accès est un processus en un clic

D'un point de vue commercial, l'utilisation de quelque chose comme Facebook oAuth donnera accès à toutes ces données sociales , des analyses et des chances accrues de devenir viral. Ajouter que c'est plus rapide et moins cher que de payer un programmeur pour développer une fonction d'authentification en utilisant une forme d'authentification fédérée me semble une évidence.

J'utilise Google pour mon compte OpenID. Presque tous les sites Web qui n'utilisent pas OpenID me permettent de réinitialiser le mot de passe par e-mail, donc si quelqu'un obtenait le mot de passe de mon compte gmail, je serais quand même foutu.

Avoir 1 mot de passe stocké sur 1000 serveurs est moins sécurisé que 1 mot de passe stocké dans 1 serveur qui authentifie 999 serveurs est moins sécurisé que 1000 mot de passe pour 1000 serveurs .

Cependant, ce dernier n'est pas pratique, les gens ne sont pas capables de se souvenir de 1000 mots de passe pour 1000 serveurs, la seule façon de le faire est d'utiliser des gestionnaires de mots de passe. Et où en est le gestionnaire de mots de passe?

Avoir 1 mot de passe stocké en utilisant le cryptage unidirectionnel sur 1000 serveurs est moins sécurisé que 1 mot de passe principal pour un gestionnaire de mots de passe qui en stocke 1000 mots de passe en texte clair ou cryptage bidirectionnel pour 1000 serveurs est moins sécurisé que 1 mot de passe stocké en cryptage unidirectionnel dans 1 serveur qui authentifie 999 serveurs est moins sécurisé que 1000 mot de passe stocké en utilisant un cryptage unidirectionnel sur 1000 serveurs .

Par conséquent, OAuth / OpenID peut être plus sûr, plus pratique et plus pratique. Utiliser 1000 mots de passe sans gestionnaire de mots de passe n'est pas pratique, et utiliser le gestionnaire de mots de passe est moins sûr car ces mots de passe devraient être stockés en texte brut ou en utilisant un cryptage bidirectionnel.

OAuth et OpenID améliorent la sécurité en vous obligeant à taper votre mot de passe moins souvent. Lier un nouveau compte à OAuth / OpenID, c'est juste que je suis redirigé vers le fournisseur d'identité, et comme je suis déjà connecté au fournisseur d'identité tout le temps, il donne simplement une invite Oui / Non au lieu d'une invite de mot de passe. Aucun mot de passe ne voyage tout au long de cet échange.

Cela vous rend plus conscient de vous-même si vous êtes réellement invité à entrer un mot de passe au lieu de simplement passer.

Donc, le n ° 2 n'est pas vraiment problème.

# 2 est absolument vrai, mais pas principalement un problème d'identité fédérale, mais c'est encore plus critique dans ce cas.

Vous avez des problèmes similaires avec tous les formulaires de connexion intégré dans un contenu (en fait) non approuvé, en particulier parce que l'authentification utilisée est la moins sécurisée (le secret est simplement transmis par le navigateur, et si vous avez de la chance, le serveur place SSL en dessous pour votre commodité ..).

Vous avez besoin de deux choses pour résoudre ce problème et la plupart des autres attaques de phishing:

• interface sécurisée pour l'authentification de l'utilisateur, par exemple boîte de dialogue déroulante de la barre d'URL, et NON partie du contenu du serveur.

• Protocole d'authentification implémenté de manière native (pas par le contenu du serveur, comme JavaScript) qui ne révélera pas le secret à une personne potentiellement malveillante serveur (par exemple, SRP)

BTW, j'ai implémenté SRP pour NSS il y a plusieurs années et d'autres ont même implémenté des extensions GUI. À moins que les cartes à puce ne deviennent omniprésentes, voici la voie à suivre: http://trustedhttp.org/wiki/TLS-SRP_in_NSS

Les humains veulent toujours transférer leurs responsabilités de leurs épaules (pas tout le monde). La sécurité est une grande responsabilité et la plupart des entreprises veulent se concentrer sur leur cœur de métier et donner à leurs clients le meilleur de leur produit plutôt que de se soucier de la sécurité.

Le point de défaillance unique est certainement quelque chose à craindre du point de vue de la sécurité, mais les gens veulent faire confiance aux grandes entreprises parce qu'elles ont beaucoup d'argent et avec de l'argent, de bons ingénieurs en sécurité (pas exactement mais Ouais! ). De bons ingénieurs signifient de bonnes pratiques de sécurité. De plus, ils ne vont pas montrer leur dos aux gens (espérons-le!).

Le phishing est définitivement un énorme problème et la communauté de sécurité travaille sur ce problème depuis un certain temps déjà. Comme @Rakkhi l'a mentionné, des solutions récentes comme Yubikey, Fido U2F pour résoudre le problème du phishing pourraient aider à renforcer la sécurité.

La seule chose que nous pourrions espérer est un nouveau changement de conception où les gens n'ont pas à choisir leurs mots de passe et saisissez-les tout en pouvant les authentifier en toute sécurité.