Question:
Nouveau système de connexion Gmail - va-t-il à l'encontre des idées reçues?
ataftoti
2015-05-08 21:06:28 UTC
view on stackexchange narkive permalink

J'ai remarqué que la nouvelle connexion gmail demande d'abord le nom d'utilisateur, puis confirme si un tel nom d'utilisateur existe, avant de demander la saisie du mot de passe.

Cela ne va-t-il pas à l'encontre de la sagesse conventionnelle en matière de sécurité de ne pas divulguer un nom d'utilisateur existe, pour contrecarrer la classe d'attaques qui tente de nombreux noms d'utilisateur possibles?

Je suppose que Google sait ce qu'ils font, cela signifie-t-il qu'ils ont un moyen de se protéger contre ce qui est traditionnellement considéré comme une vulnérabilité ?

Est-ce que essayer de vous inscrire avec un nom d'utilisateur ne révèle pas les mêmes informations?
J'ai remarqué que les sites Web de pâtisserie le faisaient également. Je m'attends à ce que cela force plusieurs requêtes, donc le clic jack est plus difficile, mais je suis curieux de voir quelqu'un écrire tous les avantages et les cas d'utilisation
Certes, l'inscription révèle les mêmes informations. Mais maintenant je me demande pourquoi on m'a toujours dit de ne pas renvoyer le message "nom d'utilisateur n'existe pas" pour une meilleure sécurité .... est-ce juste une idée fausse alors?
Je renvoie plutôt un message disant "nom d'utilisateur ou mot de passe est incorrect" de cette façon qu'une personne ne sait pas laquelle est mauvaise. Leur dire qu'un nom d'utilisateur est mauvais donne une autre information
Dans le cas d'un fournisseur de messagerie, je pense qu'il est déjà possible de numéroter les noms d'utilisateur en les envoyant par courrier électronique et en regardant ceux qui sont livrés (même s'ils sont signalés comme spam) et ceux qui rebondissent, donc c'est un peu moins un problème.
Connectez-vous via telnet à gmail et essayez d'envoyer un e-mail à un identifiant aléatoire. Vous saurez facilement si cet identifiant existe ou non. Il existe de nombreuses autres façons similaires de connaître l'existence des identifiants.
Cette "sagesse conventionnelle" est du point de vue de l'utilisabilité de l'idiotie absolue - je dois me rappeler laquelle de mes 4 ou 5 adresses e-mail j'ai utilisé * et * essayer toutes les variantes de mes dix mots de passe pour me connecter? Eh bien, j'ai mieux à faire que d'essayer de me connecter 50 fois donc je devrai simplement réinitialiser mon mot de passe à nouveau ...
Désolé, "sites de cuisson" @amccormack? Terminologie qui me manque, ou sites de cuisine? : /
Aurait dû être bancaire, désolé.
Le nom d'utilisateur n'a pas besoin d'être secret, c'est pourquoi nous avons des mots de passe.
Tout à fait d'accord avec Steve. Il faut tenir davantage compte des aspects de convivialité de la sécurité. Sans cela, les utilisateurs prennent de mauvaises décisions en matière de sécurité pour leur faciliter la vie. Nos systèmes doivent leur faciliter la vie pour les aider à prendre de bonnes décisions en matière de sécurité! Mon autre frustration avec des systèmes comme celui-ci est de ne pas répéter les règles de mot de passe (longueur, caractères acceptés, etc.) lors de la connexion; ce sont des informations publiques (lors de l'inscription), alors pourquoi faire en sorte que l'utilisateur le cherche?
La sagesse conventionnelle en matière de sécurité est que rien n’importe sauf la sécurité. Ce qui est évidemment stupide.
Je viens de remarquer qu'Adobe semble faire cela également. Lors de la saisie de votre Adobe ID lors de la connexion à Adobe Acrobat DC. Le nom d'utilisateur / l'adresse e-mail semble être validé (reçoit une coche verte) avant de saisir le mot de passe.
@SteveDL - Je suis d'accord avec vous: * «du point de vue de l'utilisabilité» *. Parfois, j'essaye aussi différents couples (nom d'utilisateur; mot de passe), c'est ennuyeux. Mais les sites Web le font pour une bonne raison. Comme souvent, la convivialité entre en conflit avec la sécurité.
@NicolasBarbulesco Je doute sincèrement que 90% des sites faisant cela aient quelque chose de proche d'un modèle de menace. :-)
Maintenant, je dois cliquer sur deux boutons pour me connecter. Le nouveau système de connexion n'est pas convivial.
@SteveDL Non, vous devez utiliser un gestionnaire de mots de passe.
@SteveDL De plus, vous n'avez que 10 mots de passe? Je suppose que vous réutilisez le même mot de passe sur plusieurs sites, alors. C'est un risque horrible pour la sécurité. Pourquoi n'utilisez-vous pas simplement un gestionnaire de mots de passe, qui n'a pas vraiment d'inconvénients?
@nyuszika7h il y a de nombreuses raisons valables pour lesquelles quelqu'un ne voudrait pas utiliser un gestionnaire de mots de passe ...
Il n'y a cependant aucune raison valable de réutiliser le même mot de passe plusieurs fois, à part la paresse. Aussi, quelle est ** votre ** raison de ne pas vouloir utiliser de gestionnaire de mots de passe?
Discussion connexe: [Est-ce que les champs de nom d'utilisateur et de mot de passe sur différentes pages sont plus sécurisés?] (Https://security.stackexchange.com/q/85160/32746)
Dix réponses:
#1
+65
schroeder
2015-05-08 23:28:31 UTC
view on stackexchange narkive permalink

Pour les petits sites, vous ne voulez pas permettre aux pirates d'é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 compte 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 révéler si un nom d'utilisateur existe, mais le risque doit être mis en balance avec le processus d'enregistrement des nouveaux utilisateurs. Ce que vous voulez éviter, c'est un processus automatisé d'énumération de vos listes. Le processus d'enregistrement des nouveaux utilisateurs devrait inclure une 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 et 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.

En fait, les noms d'utilisateur ne sont pas divulgués dans les adresses e-mail. Une adresse e-mail peut apparaître sous la forme [email protected], mais le nom d'utilisateur de cet utilisateur peut être [email protected] Avec Gmail, les points n'ont pas d'importance dans les adresses e-mail, mais ils sont essentiels pour valider les identifiants de connexion.
@AndrewLeach Google me permet de me connecter si je laisse de côté les points, ils semblent également être analysés pour la connexion.
@EricG alors il y a ça ...
Cela a donc changé; ils faisaient la différence. Peut-être que les gens ne pouvaient pas faire face à la différence. Cela m'a semblé raisonnable, et je ne me souviens pas d'une annonce concernant le changement (mais je ne suppose pas qu'ils annonceraient une réduction de la sécurité, même si ce n'est que la sécurité par l'obscurité en premier lieu.)
Lorsqu'il s'agit de formulaires de connexion, masquer l'exactitude du nom d'utilisateur / de l'adresse e-mail d'un utilisateur rend également la tâche exponentielle difficile pour les utilisateurs de se souvenir du mot de passe qu'ils ont utilisé sur le site.
Il est sûrement également possible qu'ils vérifient (dans la mesure du possible) un tel dénombrement automatisé? Si un «utilisateur» essaie plus qu'un nombre (assez faible) de noms d'utilisateur, il y a fort à parier qu'il ne soit pas un véritable utilisateur.
#2
+47
Michael
2015-05-09 01:18:02 UTC
view on stackexchange narkive permalink

Jeff Atwood, lors de la connexion à Discourse, avait ceci à dire sur le sujet:

Ce fut la source d'une longue discussion à Discours sur l'opportunité 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 nos fichiers. Sur de nombreux sites Web, voici le type de message que vous verrez après avoir saisi 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 timbre "si" là-bas, qui est une 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 le saisissant dans le formulaire de mot de passe oublié.

Nous sommes extrêmement sérieux au sujet de la sélection des valeurs par défaut sûres pour Discourse, donc dès le départ, vous ne serez pas exploité, abusé ou dépassé par les spammeurs. Mais après avoir fait l'expérience du monde réel "quel email avons-nous utilisé ici encore?" état de connexion sur des dizaines d'instances Discourse nous-mêmes, nous avons réalisé que, dans ce cas précis, être convivial est bien plus important que d'être sécurisé.

Conclusion très intéressante. Fondamentalement, ils préfèrent faire face automatiquement aux utilisateurs qui ne se souviennent pas du nom de connexion qu'ils ont utilisé, plutôt que de protéger leur liste d'utilisateurs contre le forçage brutal. Je ne peux pas parler en leur nom, mais il semble qu'ils disent: «minimiser le volume d'assistance est bien plus important que d'être sécurisé».
La réduction du volume de support est également (généralement) plus conviviale - être suffisamment difficile à utiliser pour qu'un nombre significatif d'utilisateurs ait besoin de contacter le support est le contraire d'une bonne convivialité.
La sécurité ne consiste pas à appliquer des règles arbitraires et des meilleures pratiques. Il s'agit de comprendre comment tous vos contrôles et contre-mesures fonctionnent ensemble et la valeur relative, en tenant compte de la fourniture du service réel. La valeur de risque de l'énumération du nom d'utilisateur diminue si vous disposez de contrôles atténuants qui traitent de l'utilité de connaître le nom d'utilisateur (par exemple, la surveillance de l'adresse IP pour les tentatives de connexion, les échecs de verrouillage des tentatives, la liste noire des attaquants, etc.)
@JeffMeden voir la réponse de Tom Leek [ici] (http://security.stackexchange.com/questions/42872/user-name-enumeration) - la "sécurité" fournie par le masquage des noms d'utilisateur est au mieux minime.
#3
+36
SilverlightFox
2015-05-09 14:21:57 UTC
view on stackexchange narkive permalink

Pour Gmail, vous pouvez déterminer si un compte existe simplement en envoyant un e-mail à une adresse @ gmail.com . S'il rebondit, ce compte n'existe pas.

C'est le cas de nombreux fournisseurs de messagerie. Ici, les noms d'utilisateur ne sont pas considérés comme secrets. Si un utilisateur a l'adresse e-mail [email protected] , tout le monde sait que foo a un compte sur example.com avec le nom d'utilisateur foo @ example.com .

Cependant, pour la plupart des autres systèmes, révéler les noms d'utilisateur constitue une violation de la vie privée. Si quelqu'un peut découvrir que [email protected] a un compte sur nostringsattacheddating.example.org et que la femme de Bob, Alice, peut essayer de s'enregistrer avec le nom d'utilisateur bob @ example. com sur le site Web et qu'il leur indique que le nom d'utilisateur est déjà utilisé, il s'agit d'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 pas de perte de confidentialité si [email protected] est connu pour avoir un compte sur example.com , car il n'y a pas de point de référence pour qui eve @ example.com est. Il n'en va pas de même pour un autre système utilisant l'e-mail comme nom d'utilisateur - un utilisateur avec le nom d'utilisateur [email protected] sur un site Web autre que la messagerie électronique sera le même [email protected] comme enregistré sur d'autres sites Web. Il y a une confidentialité à protéger sur les comptes dont dispose Mallory.

De plus, révéler les noms d'utilisateur peut être utile à un attaquant. C'est ce qu'on appelle une vulnérabilité d'énumération de nom d'utilisateur. Si un attaquant sait quels noms d'utilisateur existent, alors il peut lancer une attaque de devinettes de mot de passe.

En tant qu'attaquant, si je peux utiliser votre page de connexion ou mot de passe oublié pour restreindre liste de 10000 cibles à 1000 cibles, je le ferai.

Cela 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:

  1. Le système demande son nom d'utilisateur (e-mail) sur un seul page, sans autres champs de saisie.
  2. Lorsque le formulaire est soumis, le système demande à l'utilisateur de vérifier son compte de messagerie.
  3. Si le compte existe, l'e-mail contient un lien de réinitialisation du mot de passe .
  4. 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 signifiera que l'utilisateur ne pourra pas s'inscrire du tout - ce qui est bien car un utilisateur n'utilise pas accidentellement un compte enregistré à une adresse e-mail différente.

Le mot de passe et les liens d'inscription contiennent un identifiant aléatoire sécurisé cryptographiquement, de sorte qu'ils ne peuvent 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 ses mots de passe de courrier électronique et d'ordinateur portable secrets d'Alice - il serait sage pour lui de désactiver les sons de notification au cas où Alice essaierait ce processus quand ils sont également dans la même pièce).

Voir quelques-unes de mes autres réponses sur des sujets connexes:

"Pour Gmail, vous pouvez déterminer si un compte existe simplement en envoyant un e-mail": ce n'est pas vrai en général.Si vous envoyez trop d'e-mails à des adresses inexistantes, vous serez bloqué.
#4
+9
Jerry B
2015-05-09 03:52:41 UTC
view on stackexchange narkive permalink

Je suis sûr que cette règle s'est développée à l'époque du «grand fer», lorsque tous les comptes étaient sur 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, garder la liste des noms de compte était possible & utile.

Maintenant que nous avons affaire à des sites d'auto-inscription, il est impossible de garder la liste des noms de compte secrète. De plus, tant de personnes de nos jours rendent le nom de leur compte public de toute façon. Dans ces conditions, il est inutile d'essayer de cacher le fait que c'est le nom qui a échoué à la place du mot de passe.

#5
+8
Ali
2015-05-08 22:34:45 UTC
view on stackexchange narkive permalink

Savoir quel nom d'utilisateur existe ou non n'est pas important, car un attaquant peut également le vérifier depuis la page d'inscription. Google n'autorise pas qu'un attaquant exécute une attaque comme une attaque par force brute pour obtenir une liste de noms d'utilisateur.

Donc, fondamentalement, la règle "ne pas retourner" l'utilisateur n'existe pas "à la connexion" est un mythe? Cela a-t-il déjà fait une différence en matière de sécurité?
Cela fait une différence en matière de sécurité. Par exemple, j'ai une instance Jira à laquelle les gens se connectent. J'ai créé les comptes de mon équipe, ce n'est pas une auto-inscription. Ainsi, le seul moyen de divulguer le nom d'utilisateur est le processus d'inscription. Tout se résume à des compromis d'utilisabilité. Sur les sites publics, il est souvent nécessaire de dire aux gens si un nom d'utilisateur existe ou non, mais cela ne signifie pas que l'exposition de ces informations n'est pas un risque. Les concepteurs doivent comprendre ce qu'ils exposent et mettre d'autres limites techniques pour s'assurer que cela ne peut pas conduire à des abus généralisés.
La possibilité de vérifier à partir d'un signe supérieur n'est pas universelle. La meilleure pratique consiste à dire qu'un e-mail a été envoyé à cette adresse même si elle existe déjà et à alerter la personne que quelqu'un a essayé de se réinscrire avec son compte ou simplement de ne plus envoyer l'e-mail. En outre, il est important de faire la distinction entre une adresse e-mail et un compte utilisateur. Un compte d'utilisateur sur quelque chose comme la banque en ligne n'est généralement pas public et devrait être protégé par rapport à quelque chose qui, par définition, doit être public.
Cette "sagesse conventionnelle" est principalement [tag: security-theatre].
#6
+8
user76196
2015-05-10 05:55:06 UTC
view on stackexchange narkive permalink

Il y a une raison plus importante pour demander d'abord le nom d'utilisateur, puis le mot de passe: cela permet à Google de proposer une interface utilisateur différente pour les comptes qui utilisent l ' authentification sans mot de passe ou d'autres mécanismes de connexion expérimentaux sans révéler au préalable lequel les comptes l'utilisent.

C'est similaire à la façon dont l'interface utilisateur d'authentification 2Factor de Google ne s'affiche 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'utilisateur, cela me semble être en fait une amélioration de la sécurité.

#7
+5
Eric G
2015-05-09 21:21:04 UTC
view on stackexchange narkive permalink

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 publiquement et routable publiquement. Pensez au courrier postal, l'adresse postale 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 la rechercher en ligne également. Dans le cas de quelque chose comme Google, ils ont Google+, YouTube, Google Groupes, etc. qui font que de nombreuses adresses sont déjà bien connues.

Il est également simple d'interroger un serveur de messagerie et de déterminer si un e-mail donné adresse 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 et une adresse e-mail différents pour l'utilisateur moyen (peut-être que ceux d'entre nous qui sont plus paranoïdes en matière 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 saisi dans un champ de recherche ou le champ de 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 informatique ou un État-nation, l'attaquant peut alors être en mesure de corréler l'adresse IP de l'utilisateur avec son nom d'utilisateur, puis remarquer quelque chose comme "m7p @ 55w0rd !!!!" qui dépasse et suppose que c'est un mot de passe.

En termes de gestion des risques, le risque d'exposition du mot de passe est beaucoup plus grand que le risque d'énumération du nom d'utilisateur. Google dispose probablement d'un système anti-fraude et de suivi 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 Tire Swing dans l ' introduction FAIR (pdf). Le calcul du risque d'un nom d'utilisateur connu est influencé par les autres contrôles et facteurs. Arrêtez-vous les attaques par force brute, exigez-vous une authentification multifacteur, comment cette information pourrait-elle être obtenue autrement? Dans le scénario, vous faites effectivement un échange 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 tapé par l'utilisateur dans la mauvaise zone).

#8
+4
andrew.carpenter
2015-05-09 05:32:51 UTC
view on stackexchange narkive permalink

Je vais prendre des précautions et dire qu'ils ont probablement mis en place des mécanismes pour s'assurer qu'il ne s'agit pas d'un référentiel ouvert d'utilisateurs.

Nous avons implémenté un système similaire sur notre petit site utilisant une solution redisposé.

Les utilisateurs reçoivent d'abord un simple e-mail / 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'inscription est supprimé. Sinon, ils reçoivent 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 liste noire n'a pas d'impact sur leur capacité à utiliser le site, elle revient simplement au comportement standard des options de connexion / inscription.

Un spammeur qui souhaite créer une liste de comptes peut louer un botnet pour contourner le blocage par sous-réseau IP.
Vrai. Cela étant dit, si Google le souhaitait (bien que d'autres réponses suggèrent de nombreuses raisons valables pour lesquelles ils ne s'en soucient peut-être pas), ils pourraient utiliser d'autres mécanismes de prévention des abus. Par exemple, suivre les écarts par rapport aux taux de défaillance standard et inverser le comportement à l'échelle mondiale
#9
+4
Nemo
2015-05-09 11:11:25 UTC
view on stackexchange narkive permalink

Oui, ils ont des systèmes en place pour empêcher les abus. Google dispose de mécanismes étendus de "détection d'anomalies", qui diffusent des erreurs ou des captchas lorsque votre activité est suspecte: les exemples les plus connus sont les blocages de la recherche Google et du NoCaptcha ReCaptcha.

Le fait que vous ont été autorisés à 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 votre blocage, c'est un test intéressant.

#10
  0
Mark Buffalo
2016-02-08 23:57:18 UTC
view on stackexchange narkive permalink

Presque tout le monde fait déjà cela

J'ai remarqué que la nouvelle connexion Gmail demande d'abord un nom d'utilisateur, puis confirme si un tel nom d'utilisateur existe, avant de demander saisie du mot de passe.

Google dispose déjà de 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 conventionnelle en matière de sécurité de ne pas divulguer d'informations sur l'existence d'un nom d'utilisateur, pour contrecarrer la classe d'attaques qui tente de nombreux noms d'utilisateurs possibles?

S'ils n'ont pas vérifié, 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 autoriser plusieurs personnes à porter le même nom.

Comme je l'ai déjà dit, à peu près tout le monde le fait déjà d'une manière ou d'une autre. Il n'y a rien à craindre ici. Si vous souhaitez ralentir l'énumération massive des noms d'utilisateurs, ajoutez simplement un captcha après quelques tentatives.


Les captchas ne peuvent pas vraiment empêcher les astuces de publipostage de masse

Les spammeurs envoient fréquemment de grandes quantités de spam à des adresses e-mail. Bien que Google puisse pousser l'e-mail dans le dossier spam, cela n'empêche pas l'énumération par le biais d'e-mails non renvoyés.

Il est trivial de créer un courrier électronique de masse qui utilise des milliers d'adresses IP différentes, puis d'essayer d'énumérer en ne recevant pas d'e-mail rebondi. Vous pouvez même envoyer des ordures au hasard. N'oubliez pas que 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.

Ils «font déjà ça» depuis que Google a commencé.Avant Google, peu le faisaient.


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...