Ils ne sont pas précis car ils ne sont pas obligés de le faire, et un langage précis peut dérouter certains utilisateurs.

Ils pourraient dire, par exemple, "Vous ne devriez pas partager des codes inutilisés inférieurs à une heure avec quelqu'un d'autre et personne de Google ne demandera jamais ce code. "

Vous et moi saurions ce qu'ils signifient. Mon beau-père et mon grand-père ne sauront cependant pas pourquoi. Mon beau-père est un exemple spécifique d'une personne qui verrait qu'il y a des moments où elle peut partager des codes, et quelqu'un qui lui fait escroquer son chèque de sécurité sociale aura également accès à son courrier électronique. (Oui, la plupart de sa boîte de réception concerne les produits chimiques de contrôle de l'esprit ajoutés aux traînées et la façon dont les éruptions solaires provoquent des tremblements de terre, mais cela pourrait aussi donner à quelqu'un accès à son compte bancaire.)

Comme cela a été souligné dans les commentaires, il existe d'autres exemples de situations conditionnellement dangereuses, mais les gens n'incluent tout simplement pas les exceptions. Par exemple: "Ne regardez jamais le canon d'une arme à feu [sauf si vous avez dégagé la chambre]," ou "ne mettez jamais votre doigt dans une douille de lumière [sauf si vous avez coupé l'alimentation de cette prise]."

Puisqu'un jeton utilisé ou expiré est inutile pour tout le monde, il ne sert à rien de le conserver, de le partager, de le protéger, de le supprimer ou d'ajouter des exceptions aux conseils de sécurité généraux.

Je peux le dire personnellement Découvrez qu'il y a des utilisateurs qui feront des choses stupides lorsque vous leur faites savoir qu'il existe des cas extrêmes et des nuances en matière de sécurité. Sachant que, si je devais écrire un tel avertissement à mes utilisateurs, je ferais ma déclaration aussi large et générale que possible.

Il s'agit d'empêcher les attaques d'ingénierie sociale contre vous. Imaginez, par exemple, vous vous êtes connecté à votre compte gmail à deux facteurs sur un ordinateur public louche où un keylogger a enregistré votre adresse e-mail et votre mot de passe (mais que vous n'avez pas pu l'utiliser pendant que vous étiez connecté), mais vous avez activé l'authentification à deux facteurs et rappelé de vous déconnecter à la fin de votre session. Votre compte est toujours en sécurité (bien qu'une fois de plus, il est préférable de ne pas vous connecter à vos systèmes à l'aide d'ordinateurs publics fragmentaires; car même avec une authentification à deux facteurs, une personne sophistiquée pourrait encore potentiellement faire des choses malveillantes sur votre compte dans la fenêtre pendant que vous étiez connecté) .

Les attaquants ont maintenant votre adresse e-mail et votre mot de passe. Pour accéder à votre compte (par exemple, utiliser votre adresse e-mail pour réinitialiser les mots de passe pour d'autres systèmes, comme commander des éléments en ligne, accéder à des comptes bancaires, envoyer du spam ou d'autres ravages), ils doivent passer le système d'authentification à deux facteurs. Alors ils vous contactent, se font passer pour Google et essaient de vous tromper pour leur répondre avec le code d'authentification réel, afin qu'ils puissent se connecter entièrement à votre compte. Peut-être qu'ils vous appellent au téléphone (numéro usurpé qui ressemble à quelque chose associé à Google Inc.) et vous disent "nous voyons que vous avez une configuration d'authentification à 2 facteurs, avant que nous puissions continuer, je dois nous dire le code qui vient de vous être envoyé", etc.

Les jetons expirés ou déjà utilisés n'ont pas d'importance, mais ils veulent juste vous donner l'habitude de ne pas divulguer ces informations à des tiers.

Peut ne pas s'appliquer à donner le code à quelqu'un avant utilisation, mais même si quelqu'un connaît votre nom d'utilisateur et votre mot de passe et a pu obtenir un code inutilisé et que cette personne où se connecter, un nouveau code doit être généré pour la nouvelle session . non?

Faux. Je suppose que vous parlez d'un code TOTP généré par exemple par l'application Google Authenticator. TOTP fonctionne en stockant un secret partagé sur le client et le serveur (votre téléphone et les serveurs de Google). Pour s'authentifier, le client et le serveur utilisent le secret comme clé HMAC pour hacher l'heure actuelle, puis la tronquer à une valeur de n chiffres (souvent 6 chiffres, parfois plus ).

TOTP n'est en aucun cas lié à une session, il est entièrement basé sur un secret partagé et l'heure actuelle.

Suis-je en train de manquer quelque chose, est-ce là une raison de ne pas partager le code temporel unique, en particulier la partie concernant un inconnu au hasard appelant et le demandant? De plus, il devrait expirer depuis longtemps avant que quelqu'un ait la chance de vous appeler et de le demander à l'avenir.

J'imagine qu'ils essaient d'empêcher les gens de tomber dans les escroqueries lorsque quelqu'un vous le demande pour leur envoyer le code actuel . Une fois le code utilisé, ou après un temps suffisant pour qu'il ne soit plus valide, le code est inutile.

Plusieurs anciens codes peuvent contenir suffisamment d'informations pour permettre le forçage brutal du secret partagé, mais qui nécessite au moins une attaque de pré-image sur SHA-1, ce qui est encore tout à fait irréalisable (c'est-à-dire que les codes leur permettront de dire si une estimation particulière du secret partagé est correcte, mais ils pourraient passer plusieurs vies deviner et ne jamais le trouver).

Cela s'applique à de nombreux conseils de la communauté de la sécurité.

La ligne qui sépare les «bonnes pratiques» et les «mauvaises pratiques» devrait être cohérente, mais ce n'est souvent pas le cas. Soit vous pouvez le casser et c'est mauvais, soit vous ne pouvez pas et c'est bien non?

Malheureusement, ce n'est pas ainsi que cela a tendance à fonctionner. En particulier, le côté offensif et le côté défensif tracent des lignes dans le sable différemment. Bien que la même question cassée ou non soit au cœur du problème dans la pratique, elle ignore beaucoup de zones grises entre le `` bon '' et le `` mauvais '' qu'aucune des parties ne veut traiter, ce qui conduit à de nombreuses questions délicates comme mon favori "À quel point MD5 est-il mauvais?".

Malheureusement, il n'y a pas de solution facile. Il y a beaucoup de zones grises dans la cryptographie en ce qui concerne ce que les gens ne peuvent pas faire, ce qui est pratiquement impossible à prouver ou à éviter. Même quand il n'y a aucune ambiguïté, combien de temps faudrait-il, et avec quel kit, pour que quelque chose soit de la force brute avant d'être sûr? Ses minutes claires sur un ordinateur de bureau moyen ne sont pas bonnes et des milliards d'années sur tous les ordinateurs actuels de l'humanité sont probablement assez bonnes pour la plupart des choses, mais où se trouve la ligne entre les deux. Il n'y a pas de réponse à cela. La seule façon d'être en sécurité est si le côté défensif insiste toujours sur des conditions plus strictes que le côté offensif accepterait comme cassable .

Le résultat pour vous est:

Vous ne devriez pas vous attendre à ce que les conseils défensifs s'alignent exactement sur des attaques viables, ce n'est pas leur travail et c'est invariablement une ligne floue complexe qui est presque impossible à corriger et les erreurs peuvent être problématiques pour dire le moins.

Par conséquent, faites preuve de prudence. Surtout si cela fait peu de mal.

dr jimbob a tout à fait raison. Ingénierie sociale. Plus précisément, une attaque d'ingénierie sociale lorsque l'attaquant a votre mot de passe. Je peux imaginer un scénario où une base de données d'utilisateurs non sécurisée est forcée brutalement. J'imagine qu'un bon nombre d'utilisateurs pourraient être associés à un numéro de téléphone, voire figurer dans la base de données. Lorsque les mots de passe sont piratés et qu'un numéro de téléphone est associé, envoyez-le à un Twilio IVR. S'ils répondent, l'IVR leur dit que leur compte a peut-être été compromis et sera désactivé à moins qu'ils n'entrent le code de confirmation qu'ils devraient recevoir. Ensuite, déclenchez une connexion et s'ils répondent avec le code, vous y êtes. C'est exactement pourquoi il est dit que personne ne le demandera jamais. Comme mentionné, ceux qui ne sont pas utilisés ne valent rien, mais vous obliger à en abandonner un qui n'est pas utilisé est de l'or.

Ma réponse est fausse.

Ces codes sont générés par "un algorithme". Même si quelqu'un connaît cet algorithme, il ne connaît pas le point de départ ou la position actuelle dans la séquence de codes calculables à laquelle l'algorithme se trouve actuellement.

Si quelqu'un avait suffisamment de codes ET connaît l'algorithme, il pourrait, en théorie, déterminer où se trouve l'algorithme dans la séquence et commencer à calculer de nouveaux codes.

Bien que, je pense que ceci pourraient s'appliquer uniquement aux jetons matériels que vous obtenez, par exemple, en vous connectant à votre MMORPG préféré

Il est fort peu probable que quelqu'un puisse trouver les deux informations nécessaires pour briser le système.