31

I noticed in some cases when I get a verification code from Google it may say something along the line of:

"You should not share this code with anyone else and no one from Google will ever ask for this code."

OK, this seems like it's for security reasons, but the code is only a one use code so if you give someone it after it was used then it will not work. (May not apply to giving someone the code before use, however even if someone knows your username and password and was able to get an unused code and that person were to login a new code should be generated for the new session. Right?)

Am I missing something, is there any reason not to share the one time code, especially the part about some random stranger calling and asking for it? Also it should have long self expired before someone had the chance to call you and ask for it in the future.

Improve this question
10
  • 108
    Why do you think they say "don't look down the barrel of a gun" instead of "don't look down the barrel of a gun unless it's empty"? Or "don't try to stick your fingers into the power outlet" instead of "don't try to stick your fingers into the power outlet unless they're too big to go in or unless you've shut off the power"? etc.
    – user541686
    May 13, 2019 at 23:46
  • 5
    @Mehrdad You do know the saying "Better be safe than sorry", right? They tell you that to make sure you are always careful around anything that could possibly be risky.
    – Henry WH Hack v3.0
    May 14, 2019 at 0:01
  • 73
    Time to post an answer to your own question!
    – user541686
    May 14, 2019 at 0:33
  • 2
    I'm not an expert, so I'm not going to make this an answer. Imagine if someone somehow managed to copy the content on just the right servers at the right time. They could then use the old code to access your private data. At least, this is one of the reasons why you shouldn't share old passwords. (Correct me if I'm wrong.)
    – Kapten-N
    May 14, 2019 at 10:07
  • 7
    People who are this literal drive me insane. Please chill, OP.
    – user91988
    May 14, 2019 at 18:49

6 Answers 6

Reset to default
126

They're not being precise because they don't have to, and precise language might confuse some users.

They could say, for example, "You should not share unused codes that are less than an hour old with anyone else and no one from Google will ever ask for this code."

You and I would know what they mean. My father in law and grandpa won't know why, though. My father in law is a specific example of a person who would see that there are times when he can share codes, and someone scamming him out of his social security check will get access to his email as well. (Yes, most of his inbox is about mind control chemicals added to contrails and how solar flares cause earthquakes, but it might also give someone access to his bank account.)

As has been pointed out in comments, there are other examples of situations that are conditionally dangerous, but people just don't include the exceptions. For example: "Never look down the barrel of a firearm [unless you have cleared the chamber]," or "never stick your finger in a light socket [unless you have turned off the power to that socket]."

Since a used or expired token is useless to everyone, there's no point in keeping it, sharing it, protecting it, deleting it, or adding exceptions to general security advice.

I can tell from personal experience that there are users who will do stupid things when you let them know that there are edge cases and nuances to security. Knowing that, if I were to write such a warning to my users, I'd make my statement as broad and general as possible.

Improve this answer
6
  • 61
    Also simple. Simple rules are easy to remember. Nested conditions increase Cyclomatic Complexity.
    – Aron
    May 14, 2019 at 5:31
  • 3
    (...) a specific example of a person who would see that there are times when he can share codes. This is a very good point. Giving too much details means that one can (completely logically) assume something unexpected.
    – WoJ
    May 14, 2019 at 9:15
  • 26
    Note that the gun case is example of the same approach—everybody will tell you to treat every gun as loaded and about to misfire at any time even if you just cleaned it and are absolutely sure it isn't loaded (it will save you next time your muscle memory also inserts the cartridge while your mind fails to notice). Because if you don't need to do the exception, it's better not to.
    – Jan Hudec
    May 14, 2019 at 20:43
  • Chemtrails? Waft 'em this way, man - I love those things!!! :-)
    – Bob Jarvis - Слава Україні
    May 14, 2019 at 22:59
  • And keep in mind that, not knowing how the codes are generated, we can't know for certain that they don't contain sensitive information that someone with the right knowledge and interest can't extract and use to do harm. E.g. I've seen algorithms for such codes that contain an encoded username, which alone'd give a potential intruder information he didn't have before.
    – jwenting
    May 15, 2019 at 6:43
36

It's to prevent social engineering attacks against you. Imagine, for example you logged into your two-factor gmail account on a shady public computer where a keylogger recorded your email address and password (but weren't able to use it while you were logged in), but you have two factor authentication enabled and remembered to sign out at the end of your session. Your account is still safe (though again, it's best not to sign in to your systems using sketchy public computers; because even with two-factor auth someone sophisticated could still potentially do malicious things on your account in the window while you were signed in).

Attackers now have your email address and password. To access your account (say to use your email address to reset passwords for other systems, like order stuff online, access bank accounts, send out spam, or other havoc), they need to get past the two factor authentication system. So they contact you, pretend to be Google, and try and trick you to answer to them with the actual authentication code, so they can fully login to your account. Maybe they call you on the phone (spoofed number that looks like something associated with Google Inc) and say "we see you have 2-factor auth setup, before we can proceed I need you to tell us the code just texted to you", etc.

Expired or already used tokens don't matter, but they just want to get you in the habit of not giving away this information to third parties.

Improve this answer
4
  • 11
    Alternatively, someone with the target's username, land line, and mobile numbers could phone the land line, pretending to be auditing the accuracy of their phone number information, use the "lost password" function on the account, and ask the target for the code their mobile should be receiving. Under such circumstances, many victims might not bother to read the message containing the code to see why it was sent.
    – supercat
    May 13, 2019 at 21:59
  • I think the OP understands already the points in paragraphs 1 and 2. Paragraph 3 is really the part the answers his question.
    – Jon Bentley
    May 15, 2019 at 12:23
  • 2
    @JonBentley: I disagree. Paragraphs 1 and 2 raise a point that I don't think the OP had thought of. (The premise of the question is "I legitimately requested this code and am about to use it -- why not share it afterward?"; this answer points out "This same notification is also what's sent when you didn't legitimately request this code. Don't share it with whoever caused you to get notified.")
    – ruakh
    May 15, 2019 at 22:41
  • @ruakh: Another way of looking at it: the only reason anyone would want such a code would be if they were hoping to use it to impersonate you before you use it, so the only reason you should give someone such a code would be if you wanted them to be able to impersonate you. Given many sites' lack of support for proxy accounts, one might sometimes want to assist a trusted person with such impersonation (e.g. someone in a place with voice-only phone service might want a trusted person to check their email), but not a phony google employee.
    – supercat
    May 16, 2019 at 15:31
12

May not apply to giving someone the code before use, however even if someone knows your username and password and was able to get an unused code and that person where to login a new code should be generated for the new session. right?

Wrong. I assume you're talking about a TOTP code generated for example by the Google Authenticator app. TOTP works by storing a shared secret on the client and server (your phone and Google's servers). To authenticate, both the client and server use the secret as an HMAC key to hash the current time, then truncate it to an n digit value (often 6 digits, sometimes longer).

TOTP is not tied to a session in any way, it is entirely based on a shared secret and the current time.

Am I missing something, is there any reason not to share the one time code, especially the part about some random stranger calling and asking for it? Also it should of long self expired before someone had the chance to call you and ask for it in the future.

I imagine they're trying to prevent people falling for scams where someone asks you to send the current code to them. After the code is used, or after enough time has passed to make it no longer valid, the code is useless.

Multiple old codes may contain enough information to allow for brute-forcing of the shared secret, but that requires at least a preimage attack on SHA-1, which is still quite infeasible (ie the codes will allow them to tell if any particular guess for the shared secret is correct, but they could spend several lifetimes guessing and never find it).

Improve this answer
3
  • it.slashdot.org/story/19/05/13/2255229/…
    – ivanivan
    May 14, 2019 at 14:49
  • @ivanivan That's still a collision attack. A preimage attack is much harder. There aren't even any practical preimage attacks against MD5 yet.
    – AndrolGenhald
    May 14, 2019 at 14:51
  • I'm not actually sure a preimage attack on the hash would even break HMAC, though as fgrieu says, it's probably best to assume it's broken at that point.
    – AndrolGenhald
    May 14, 2019 at 14:57
4

This applies to a lot of advice in the security community.

The line that divides 'good practice' and 'bad practice' should be consistent, but often isn't. Either you can break it and it's bad or you can't and it's good right?

Unfortunately that not how it tends to work. In particular the offensive side and defensive side draw lines in the sand differently. Although the same broken or not question is the heart of the matter in practice it ignores a lot of grey area in between the 'good' and 'bad' that neither side want to deal with, which leads to a lot of awkward questions like my favorite "How bad is MD5?".

Unfortunately there is no easy way around this. There's a lot of grey area in cryptography as is pertains to what people can't do which is next to impossible to prove or avoid. Even when there is no ambiguity at all, how long would it have to take, and with what kit, for something to be brute force before it's safe? Its clear minutes on a average desktop is no good and billions of years on all of humanity's current computers is probably good enough for most things but where in between is the line. There's no answer to that. The only way to be safe is if the defensive side always insists on more strict conditions than the offensive side would accept as breakable.

The take home for you is:

You shouldn't expect the defensive advice to line up exactly with viable attacks. It's not their job and its invariably a complex blurry line that's almost impossible to get right and mistakes can be problematic to say the least.

Hence err on the side of caution. Especially if that does little harm.

Improve this answer
1
  • Honestly that last line should be header 1, at the top of your answer. When it comes to security that's the perfectly correct advice.
    – Wayne Werner
    May 16, 2019 at 19:22
1

dr jimbob is completely correct. Social engineering. Specifically a social engineering attack when the attacker has your password. I can envision a scenario where a insecure user database is being brute forced. I imagine a fair number of users could be associated with a phone number, might even be in the database. As passwords are cracked and a phone number associated, send it off to a Twilio IVR. If they answer, the IVR tells them their account may have been compromised, and will be deactivated unless they enter the confirmation code that they should be receiving. Then trigger a login and if they respond with the code, you are in. This exactly why it says nobody will ever ask for it. As mentioned used ones are worthless, but getting you to give up an unused one is golden.

Improve this answer
-1

My answer is wrong.

These codes are generated by "some algorithm". Even if someone knows this algorithm they don't know the starting point or the current position in the sequence of calculatable codes at which the algorithm is currently at.

If someone had enough codes AND they know the algorithm they could, in theory, work out where in the sequence the algorithm is and start calculating new codes.

Although, I think this might only apply to those hardware tokens you get for example, logging into your favorite MMORPG

Highly unlikely that anyone could work out both required pieces of information to break the system though.

Improve this answer
3
  • 1
    Simply having enough codes and knowing what algorithm was used is not enough to break it, if it were it would be considered insecure. The most common 2FA algorithms are standard and public.
    – AndrolGenhald
    May 15, 2019 at 16:33
  • I realised once I read my own comment after posting that it was wrong lol. I did edit it but it is still wrong and may "delete" it.
    – Tony
    May 15, 2019 at 16:35
  • The attacker can easily sing up themselves and get all the codes they want. No need to trick a third party into sharing a code.
    – Dmitry Grigoryev
    May 16, 2019 at 7:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .