Pourquoi ne puis-je pas partager un code à usage unique avec quelqu'un d'autre?
J'ai remarqué que dans certains cas, lorsque j'obtenais un code de vérification de Google, cela pouvait dire quelque chose comme:
"Vous ne devez pas partager ce code avec quelqu'un d'autre et personne de Google ne le demandera jamais."
OK, cela semble être pour des raisons de sécurité, mais le code n'est qu'un code à usage unique, donc si vous le donnez à quelqu'un après son utilisation, cela ne fonctionnera pas. (Peut ne pas s'appliquer à donner à quelqu'un le code 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 devait se connecter, un nouveau code devrait être généré pour la nouvelle session. N'est-ce pas?)
Suis-je en train de manquer quelque chose, y a-t-il une raison de ne pas partager le code à usage unique, en particulier la partie concernant un inconnu aléatoire appelant et demandant? De plus, il aurait dû expirer longtemps avant que quelqu'un ait la chance de vous appeler et de le demander à l'avenir.
Ils ne sont pas précis parce qu'ils n'ont pas à le faire, et un langage précis peut dérouter certains utilisateurs.
Ils pourraient dire, par exemple, "Vous ne devez pas partager des codes inutilisés datant de moins d'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 pas pourquoi, cependant. Mon beau-père est un exemple spécifique d'une personne qui verrait qu'il peut parfois partager des codes, et quelqu'un qui le fait sortir de son chèque de sécurité sociale aura également accès à son courrier électronique. (Oui, la majeure partie de sa boîte de réception concerne les produits chimiques de contrôle mental ajoutés aux traînées de condensation et comment les éruptions solaires provoquent des tremblements de terre, mais cela pourrait également donner à quelqu'un accès à son compte bancaire.)
Comme cela a été souligné dans les commentaires, il existe d'autres exemples de situations qui sont conditionnellement dangereuses, mais les gens n'incluent tout simplement pas les exceptions. Par exemple: "Ne regardez jamais le canon d'une arme à feu [à moins que vous n'ayez nettoyé la chambre]", ou "ne mettez jamais votre doigt dans une prise de lumière [à moins que vous n'ayez éteint cette prise]."
Étant donné qu'un jeton utilisé ou expiré est inutile pour tout le monde, il est inutile 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 dire par expérience personnelle qu'il y a des utilisateurs qui feront des choses stupides lorsque vous leur faites savoir qu'il y a des cas et des nuances Edge à la sécurité. Sachant que, si j'écrivais un tel avertissement à mes utilisateurs, je ferais ma déclaration aussi large et générale que possible.
C'est pour empêcher les attaques d'ingénierie sociale contre vous. Imaginez, par exemple, que vous vous connectiez à votre compte Gmail à deux facteurs sur un ordinateur public ombragé où un enregistreur de frappe a enregistré votre adresse e-mail et votre mot de passe (mais que vous ne pouviez pas les utiliser lorsque vous étiez connecté), mais vous avez activé l'authentification à deux facteurs et n'oubliez pas de vous déconnecter à la fin de votre session. Votre compte est toujours en sécurité (encore une fois, il est préférable de ne pas vous connecter à vos systèmes à l'aide d'ordinateurs publics sommaires; car même avec une authentification à deux facteurs, quelqu'un de sophistiqué pourrait encore potentiellement faire des choses malveillantes sur votre compte dans la fenêtre pendant que vous étiez connecté) .
Les attaquants disposent désormais de votre adresse e-mail et de votre mot de passe. Pour accéder à votre compte (par exemple, utiliser votre adresse e-mail pour réinitialiser les mots de passe d'autres systèmes, comme commander des trucs en ligne, accéder à des comptes bancaires, envoyer des spams ou d'autres ravages), ils doivent dépasser le système d'authentification à deux facteurs. Donc, ils vous contactent, font semblant d'être Google et essaient de vous piéger pour leur répondre avec le code d'authentification réel, afin qu'ils puissent se connecter complètement à votre compte. Peut-être qu'ils vous appellent au téléphone (numéro usurpé qui ressemble à quelque chose associé à Google Inc) et disent "nous voyons que vous avez une configuration d'authentification à 2 facteurs, avant que nous puissions continuer, j'ai besoin que vous nous disiez le code qui vient de vous être envoyé par SMS", 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 à quelqu'un le code 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ée pour la nouvelle session. droite?
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 une clé HMAC pour hacher l'heure actuelle, puis la tronquer à un chiffre n valeur (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, y a-t-il une raison de ne pas partager le code à usage unique, en particulier la partie concernant un inconnu aléatoire appelant et demandant? De plus, cela devrait expirer 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 pour des escroqueries lorsque quelqu'un vous demande de leur envoyer le code actuel . Une fois le code utilisé, ou après un délai 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 brut du secret partagé, mais cela nécessite au moins une attaque de pré-image sur SHA-1, qui est encore tout à fait irréalisable (c'est-à-dire que les codes leur permettront de dire si une supposition particulière pour le secret partagé est correcte, mais ils pourraient passer plusieurs vies à deviner et ne jamais la trouver).
Cela s'applique à de nombreux conseils dans la communauté de la sécurité.
La ligne qui sépare "bonne pratique" et "mauvaise pratique" 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 bon non?
Malheureusement, ce n'est pas ainsi que cela fonctionne. En particulier, le côté offensif et le côté défensif dessinent des lignes dans le sable différemment. Bien que la même question brisé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 à beaucoup de questions délicates comme la mienne. favori "Quelle est la gravité de MD5?".
Malheureusement, il n'y a pas de solution simple à ce problème. Il y a beaucoup de zone grise dans la cryptographie en ce qui concerne ce que les gens ne peuvent pas faire, ce qui est presque impossible à prouver ou à éviter. Même lorsqu'il n'y a aucune ambiguïté, combien de temps cela devrait-il prendre, et avec quel kit, pour que quelque chose soit brutal avant qu'il ne soit sûr? Ses minutes claires sur un bureau moyen ne sont pas bonnes et des milliards d'années sur tous les ordinateurs actuels de l'humanité sont probablement suffisantes pour la plupart des choses, mais où se situe la ligne intermédiaire. Il n'y a pas de réponse à cela. La seule façon d'être en sécurité est que le le côté défensif insiste toujours sur des conditions plus strictes que le côté offensif accepterait comme cassable.
Le retour à la maison pour vous est:
Vous ne devriez pas vous attendre à ce que les conseils défensifs correspondent exactement aux attaques viables. Ce n'est pas leur travail et c'est toujours une ligne floue complexe qui est presque impossible à corriger et les erreurs peuvent être pour le moins problématiques.
Par conséquent, pécher par excès de prudence. Surtout si cela fait peu de mal.
dr jimbob est complètement correct. Ingénierie sociale. Spécifiquement une attaque d'ingénierie sociale lorsque l'attaquant a votre mot de passe. Je peux imaginer un scénario dans lequel une base de données utilisateur 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, pourraient même être dans la base de données. Comme les mots de passe sont piratés et un numéro de téléphone associé, envoyez-le à un Twilio IVR. S'ils répondent, l'IVR leur indique 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 êtes dedans. C'est exactement pourquoi il dit que personne ne le demandera jamais. Comme mentionné, ceux qui sont utilisés ne valent rien, mais vous faire abandonner un non utilisé est d'or.