Nouveau système de connexion Gmail - contraire à la sagesse conventionnelle?
J'ai remarqué que la nouvelle connexion gmail demande d'abord le nom d'utilisateur, puis confirme si ce nom d'utilisateur existe, avant de demander la saisie du mot de passe.
Cela ne va-t-il pas à l'encontre de la sagesse de sécurité conventionnelle de ne pas divulguer d'informations sur l'existence d'un nom d'utilisateur, de contrecarrer la classe d'attaques qui essaie de nombreux noms d'utilisateur possibles?
Je suppose que Google sait ce qu'ils font, cela signifie-t-il donc qu'ils ont un moyen de se protéger contre ce qui est généralement considéré comme une vulnérabilité?
Pour les petits sites, vous ne voulez pas autoriser les pirates à énumérer vos listes d'utilisateurs, mais pour Google, le site est si grand que l'on peut supposer que presque tout le monde a un ou plusieurs comptes. Ainsi, le risque est minimisé après un seuil d'ubiquité.
C'est toujours une bonne idée pour la plupart des sites de ne pas divulguer l'existence d'un nom d'utilisateur, mais le risque doit être mis en balance avec le nouveau processus d'enregistrement des utilisateurs. Ce que vous voulez empêcher, c'est un processus automatisé d'énumération de vos listes. Le nouveau processus d'enregistrement des utilisateurs doit inclure une certaine forme de délai ou de porte afin qu'un script ne puisse pas essayer rapidement un dictionnaire d'utilisateurs. Ceci est souvent réalisé en envoyant un e-mail avec les résultats du processus d'inscription non réussi. Oui, on pourrait encore énumérer, mais il y a un délai et une étape supplémentaire.
Une autre chose à considérer est la différence entre un site public et un site privé. Google est un service public dont les noms d'utilisateur sont également publics (divulgués avec chaque e-mail envoyé par un compte). D'un autre côté, un site d'entreprise interne, auquel seuls les employés actuels peuvent accéder, est privé et nécessite des contrôles plus stricts pour empêcher l'énumération.
Jeff Atwood, lors de la connexion à Discourse, avait ceci à dire sur le sujet:
Ce fut la source d'une longue discussion sur Discourse pour savoir s'il était logique de révéler à l'utilisateur, lorsqu'il saisit une adresse e-mail dans le formulaire "mot de passe oublié", si nous avons cette adresse e-mail dans le dossier . Sur de nombreux sites Web, voici le type de message que vous verrez après avoir entré une adresse e-mail dans le formulaire de mot de passe oublié:
Si un compte correspond à [email protected], vous devriez recevoir un e-mail avec des instructions sur la façon de réinitialiser votre mot de passe sous peu.
Notez le timide "si" là-bas, qui est un couverture contre toutes les implications de sécurité de révéler si une adresse e-mail donnée existe sur le site simplement en la tapant dans le formulaire de mot de passe oublié.
Nous sommes extrêmement sérieux au sujet de choisir des valeurs par défaut sûres pour Discourse, donc hors de la boîte, vous ne serez pas exploité ou abusé ou envahi par des spammeurs. Mais après avoir fait l'expérience du monde réel "quel e-mail avons-nous utilisé ici à nouveau?" état de connexion sur des dizaines d'instances Discourse nous-mêmes, nous avons réalisé que, dans ce cas spécifique, être convivial est bien plus important que sécurisé.
Pour Gmail, vous pouvez déterminer si un compte existe simplement en envoyant un e-mail à un @gmail.com adresse. S'il rebondit, ce compte n'existe pas.
Cela est vrai pour de nombreux fournisseurs de messagerie. Ici, les noms d'utilisateur ne sont pas considérés comme secrets. Si un utilisateur possède l'adresse e-mail [email protected] tout le monde sait que foo possède un compte sur example.com avec nom d'utilisateur [email protected].
Cependant, pour la plupart des autres systèmes, il s'agit d'une violation de la vie privée de révéler les noms d'utilisateur. Si quelqu'un peut découvrir que [email protected] possède un compte sur nostringsattacheddating.example.org et la femme de Bob, Alice, peuvent essayer de s'enregistrer avec le nom d'utilisateur [email protected] sur le site Web et il leur dit que le nom d'utilisateur est déjà utilisé, alors c'est une violation massive de la vie privée.
N'oubliez pas que l'adresse e-mail a ses racines chez le fournisseur de messagerie. Il n'y a aucune intimité perdue si [email protected] est connu pour avoir un compte sur example.com, car il n'y a pas de référence pour qui [email protected] est. La même chose n'est pas vraie pour un autre système utilisant le courrier électronique comme nom d'utilisateur - un utilisateur avec un nom d'utilisateur [email protected] sur un site Web autre que le courrier électronique sera le même [email protected] tel qu'enregistré sur d'autres sites Web. Il y a une confidentialité pour protéger les comptes de Mallory.
De plus, révéler des noms d'utilisateur peut être utile à un attaquant. Ceci est connu comme une vulnérabilité d'énumération de nom d'utilisateur. Si un attaquant sait quels noms d'utilisateurs existent, il peut alors lancer une attaque de devinette de mot de passe .
En tant qu'attaquant, si je peux utiliser votre page de connexion ou de mot de passe oublié pour réduire ma liste de 10000 cibles à 1000 cibles, je le ferai.
Il permet également aux attaquants de cibler les utilisateurs du système via le phishing.
Il est facilement possible de concevoir un système où l'énumération des utilisateurs ne peut pas être exécutée. Par exemple, les processus d'inscription et de mot de passe oublié sont identiques.
Les étapes sont les suivantes:
- Le système demande leur nom d'utilisateur (email) sur une seule page, sans aucun autre champ de saisie.
- Lorsque le formulaire est soumis, le système demande à l'utilisateur de vérifier son compte de messagerie.
- Si le compte existe, l'e-mail contient un lien de réinitialisation de mot de passe.
- Si le compte n'existe pas, l'e-mail contient un lien d'inscription.
En prime, vous avez validé leur adresse e-mail lors de l'inscription au cas où ils auraient besoin de réinitialiser leur mot de passe à une date ultérieure. Toute faute de frappe signifie que l'utilisateur ne peut pas s'inscrire du tout - ce qui est bien car un utilisateur n'utilise pas accidentellement un compte enregistré sur une autre adresse e-mail.
Le mot de passe et les liens d'inscription contiennent un ID aléatoire cryptographiquement sécurisé, ils ne peuvent donc pas être suivis sans recevoir l'e-mail. Seule une personne ayant accès au compte peut savoir si un nom d'utilisateur est enregistré ou non (Bob ferait mieux de garder secrets ses mots de passe de messagerie et d'ordinateur portable d'Alice - il serait sage pour lui de désactiver tous les sons de notification au cas où Alice essaierait ce processus quand ils suis dans la même pièce aussi).
Voir certaines de mes autres réponses pour des sujets connexes:
- Comment empêcher la découverte d'e-mails dans les formulaires?
- Est-il sûr d'avoir une fonctionnalité "e-mail n'est plus disponible" sur votre formulaire d'inscription?
- La vérification par e-mail doit-elle être suivie d'une connexion par mot de passe? Pourquoi?
- Meilleure pratique pour la forme de mot de passe oublié, ok pour divulguer qu'un e-mail donné n'est pas valide
- Est-il sûr de générer un mot de passe pour un utilisateur lors de son inscription dans une application Web?
Je suis sûr que cette règle s'est développée à l'époque du "gros fer", lorsque tous les comptes appartenaient à de grandes entreprises ou à des systèmes gouvernementaux. Étant donné que le système a distribué les noms de compte, l'utilisation d'une page d'inscription pour rechercher les noms de compte n'était pas un problème. Ainsi, conserver la liste des noms de compte était faisable et utile.
Maintenant que nous avons affaire à des sites d'auto-inscription, il est impossible de garder secrète la liste des noms de compte. De plus, de nos jours, de nombreuses personnes rendent leur nom de compte public. Dans ces conditions, il est inutile d'essayer de cacher le fait que c'est le nom qui a échoué au lieu du mot de passe.
Il y a une raison plus importante pour demander d'abord le nom d'utilisateur puis le mot de passe: cela permet à Google d'offrir une interface utilisateur différente pour les comptes qui utilisent authentification sans mot de passe ou d'autres mécanismes de connexion expérimentaux sans révéler au préalable quels comptes utilisent il.
Cela ressemble à la façon dont l'interface utilisateur 2Factor de Google n'est affichée qu'après la saisie du mot de passe: un attaquant ne saura même pas qu'un deuxième facteur est impliqué avant d'avoir craqué le premier facteur.
Combiné avec ce que d'autres réponses disent ici sur le non-risque relatif de fuite de noms d'utilisateurs, cela me semble être une amélioration de la sécurité.
Il n'est pas important de savoir quel nom d'utilisateur existe ou non, car un attaquant peut également le vérifier à partir de la page d'inscription. Google n'autorise pas un attaquant à exécuter une attaque telle qu'une attaque par force brute pour obtenir une liste de noms d'utilisateurs.
Les adresses e-mail ne sont pas les mêmes que les noms d'utilisateur. Un nom d'utilisateur est une information semi-privée (potentiellement), mais une adresse e-mail peut être divulguée et routée publiquement. Pensez au courrier postal, l'adresse postale si elle est souvent bien connue, mais la liste actuelle des destinataires valides n'est pas nécessairement conçue pour être publique, bien qu'il existe souvent des moyens de rechercher cela en ligne également. Dans le cas de quelque chose comme Google, ils ont Google+, YouTube, Google Groupes, etc., ce qui rend la plupart des adresses déjà bien connues.
Il est également trivial d'interroger un serveur de messagerie et de déterminer si une adresse e-mail donnée existe, en utilisant telnet ou de nombreux sites Web le feront pour vous . Il y a peu à gagner à protéger les informations qui sont facilement accessibles par d'autres moyens. C'est pourquoi certains sites séparent l'adresse e-mail du nom d'utilisateur. Dans le cas d'un fournisseur de messagerie, cela n'a pas vraiment de sens d'avoir un nom de connexion différent, puis une adresse e-mail pour l'utilisateur moyen (peut-être que ceux d'entre nous qui sont plus paranoïaques de sécurité aimeraient cette fonctionnalité).
Le passage à une connexion en deux étapes réduit la probabilité que le mot de passe d'un utilisateur soit entré dans un champ de recherche ou dans le champ du nom d'utilisateur. Ces champs sont souvent enregistrés et les journaux sont corrélés partout et sont moins susceptibles d'être sécurisés. Donc, si les journaux sont attaqués par un pirate ou un État-nation, l'attaquant peut être en mesure de corréler l'adresse IP de l'utilisateur avec son nom d'utilisateur, puis de remarquer quelque chose comme "m7p @ 55w0rd !!!!" qui ressort et assume son mot de passe.
En termes de gestion des risques, le risque d'exposition au mot de passe est beaucoup plus élevé que le risque d'énumération des noms d'utilisateur. Google dispose probablement d'un suivi anti-fraude et des anomalies plus robuste pour faire face aux risques associés aux noms d'utilisateur connus.
Je pense qu'un bon moyen de comprendre cela est l'exemple de la rotation des pneus dans le FAIR introduction (pdf) . Le calcul du risque d'un nom d'utilisateur connu est affecté par les autres contrôles et facteurs. Arrêtez-vous les attaques par force brute, exigez une authentification multifacteur, comment pourrait-on obtenir ces informations autrement? Dans le scénario, vous échangez efficacement entre un risque sur lequel vous avez le contrôle (surveillance de toutes les connexions) et quelque chose sur l'ancien formulaire qui est plus difficile à contrôler (mot de passe saisi par l'utilisateur dans la mauvaise zone).
Je vais aller de l'avant et dire qu'ils ont probablement des mécanismes en place pour s'assurer que ce n'est pas un référentiel ouvert d'utilisateurs.
Nous avons implémenté un système similaire sur notre petit site en utilisant une solution sauvegardée de nouveau.
Les utilisateurs sont initialement présentés avec un simple email/pass avec un bouton pour se connecter et s'inscrire. En entrant leur e-mail et en continuant, il est vérifié pour une correspondance et s'il correspond, le bouton d'enregistrement est supprimé. Sinon, ils sont présentés avec le formulaire d'inscription complet.
Nous suivons le nombre de tentatives par sous-réseau IP et liste noire après un seuil donné. La mise sur liste noire n'a pas d'impact sur leur capacité à utiliser le site, elle revient simplement au comportement standard des options de connexion/enregistrement.
Oui, ils ont des systèmes en place pour prévenir les abus. Google dispose de mécanismes de "détection d'anomalies" étendus, qui servent des erreurs ou des captchas lorsque votre activité est suspecte: les exemples les plus connus sont les blocs de recherche Google et le NoCaptcha ReCaptcha.
Le fait que vous ait été autorisé à savoir si ce compte existe ne signifie pas que tout le monde le ferait ni que vous seriez en mesure de deviner le nom d'utilisateur de quelqu'un d'autre. Essayez de nous faire savoir combien de temps avant d'être bloqué, c'est un test intéressant.
Presque tout le monde déjà fait ça
J'ai remarqué que la nouvelle connexion gmail demande d'abord le nom d'utilisateur, puis confirme si ce nom d'utilisateur existe, avant de demander la saisie du mot de passe.
Google a déjà cette fonctionnalité. Lorsque vous essayez de vous inscrire à un nouveau compte Google, il doit vérifier si le nom d'utilisateur existe déjà ou non.
Cela ne va-t-il pas à l'encontre de la sagesse de sécurité conventionnelle de ne pas divulguer d'informations sur l'existence d'un nom d'utilisateur, de contrecarrer la classe d'attaques qui essaie de nombreux noms d'utilisateur possibles?
S'ils ne vérifient pas, comment vous authentifieriez-vous correctement? Plusieurs personnes avec le même nom d'utilisateur sont de mauvaises nouvelles pour l'intégrité du site Web. Bien sûr, dans de nombreux cas, vous pouvez utiliser des adresses e-mail uniques et permettre à plusieurs personnes d'avoir le même nom.
Comme je l'ai déjà dit, presque tout le monde le fait déjà d'une manière ou d'une autre. Il n'y a rien à craindre ici. Si vous voulez ralentir énumération massive des noms d'utilisateurs, incluez simplement un captcha après quelques tentatives.
Les captchas ne peuvent pas vraiment empêcher les astuces de publipostage
Les spammeurs envoient fréquemment gros quantités de spam à des adresses e-mail. Bien que Google puisse placer l'e-mail dans le dossier spam, cela n'empêche pas l'énumération via des e-mails non rebondissants.
Il est trivial de créer un publipostage de masse qui utilise des milliers d'adresses IP différentes, puis d'essayer d'énumérer en ne recevant pas d'e-mail renvoyé. Vous pouvez même envoyer des ordures au hasard. N'oubliez pas, si votre objectif est de vérifier si une adresse e-mail existe ou non, il suffira de ne pas recevoir d'e-mail d'erreur après quelques jours.