[HN Gopher] The Rise of One-Time Password Interception Bots
___________________________________________________________________
The Rise of One-Time Password Interception Bots
Author : elorant
Score : 162 points
Date : 2021-10-01 13:09 UTC (9 hours ago)
(HTM) web link (krebsonsecurity.com)
(TXT) w3m dump (krebsonsecurity.com)
| loteck wrote:
| I get a lot of eye rolling when I go around pointing out that
| one-time codes are not, by definition, multi-factor auth. Google
| and some other services properly refer to this auth method as
| "two-step verification."
|
| Something you know. Something you have. Something you are. Known
| passwords of any type are all in the first category, and they
| will always be highly phishable, and using more than one of the
| same factor will never be "multi-factor."
| e12e wrote:
| > Known passwords of any type are all in the first category,
|
| Not really. People don't "know" their totp secret or their RSA
| secret key.
|
| But yes, when these key-style secrets can be transfered - they
| behave more like "know of" than "in possession of".
|
| The simple mitigation is probably fido2 auth tokens.
| bawolff wrote:
| I'd still call it something you have. If someone kidnapped you,
| you wouldn't be able to reveal your TOTP password without your
| device.
|
| The problem is the communication channel isn't bound to the
| authentication context the way it would be with a fido key. But
| that could be a flaw with any type of authenticator (albeit its
| much easier to seamlessly fix with other types) - its not about
| what type of factor it is.
| loteck wrote:
| It is something you have, until it is automatically
| downgraded to something you know. I could create all manner
| of elaborate schemes that involve tokens and biometrics and
| geolocation, but if that scheme simply produces a one-time
| code for you to put in your brain and produce at will, I'm
| still using a knowledge factor at the point of
| authentication.
| glenstein wrote:
| I've always had trouble conceptually with two factor
| authentication conceived of in this way. If a phone is
| something you have, then it gives you a code, and you put in
| that code, so it's really just a code.
|
| If it's something you have, well, probably a key right? A usb
| key? But it's a code on the USB key.
|
| If it's something about you (voice, fingerprint, etc), or a
| location, it's ultimately something represented as information.
|
| That's not to say it's a bad philosophy or less secure. It's
| better, not worse. But it seems to be conceived of and framed
| in a way as though it's appealing to something _other_ than
| stuff that gets turned into computer-accessible information.
|
| The one "hard" category that seems to make sense to me has to
| do with hard-wired networks, and having to be in a physical
| place to access a system that is not online. That creates a
| real distinction that doesn't boil down to some form of
| computer-comprehensible information.
| loteck wrote:
| But you yourself don't know the code on the hardware token,
| nor do you yourself know the information gathering, encoding
| or decoding for biometric information. Those are still pieces
| of information, but they aren't "something you know."
|
| To your later point, some later versions of these original
| authentication factors have added "somewhere you are" to the
| list.
| e12e wrote:
| There's no reason a totp/otp needs to be read/typed in the
| clear - that's merely a convenient way to bridge trust from
| a phone to a desktop etc.
|
| The otp is proof that you "possess" the otp secret.
|
| Then again, it's a shared secret - so if the server side is
| compromised - all bets are off. Here client
| certificates/public key crypto does better.
| loteck wrote:
| Right, the new factor is working fine, but instead of
| providing authentication, it's being used to merely
| attest to the validity of an additionally provided
| randomized knowledge factor, which is what gets actually
| for used for authentication.
| e12e wrote:
| So a hash of an image of a fingerprint isn't "something
| you have"? Leaves few things in that category then?
| upofadown wrote:
| "Oh no! Criminals are phishing our customers to get their
| passwords."
|
| Lets give them a code to enter...
|
| "On no! Criminals are phishing our customers to get their code."
| hoofedear wrote:
| Would a fix to this be to make OTP's 10 seconds rather than 30?
| Or is that not feasible/doesn't make a difference?
| lucb1e wrote:
| Just run through the scenario you have in mind: would the
| attacker not be able to easily automate the forwarding of the
| OTP? Would grandmas still be able to use online banking? It's
| a trade-off, and validity periods so short that the user has
| to race a potential attacker, I don't think that's viable.
| [deleted]
| jszymborski wrote:
| In all fairness, I see OTP/2FAs as more of a solution to
| credential stuffing than anything else.
| CyberRage wrote:
| TOTP is definitely helpful vs phishing.
|
| They only last for 30 seconds, requiring better
| infrastructure(automated logins) which also tremendously
| helps with detection.
|
| The vast majority of phishing is just storing passwords for
| later attempts.
|
| TOTP by design can be stronger than password. the seed can be
| pseudo-randomly generated therefore you cannot guess the code
| without it, even if you have previously generated codes.
| xvector wrote:
| Hopefully banks loose enough money to this that they finally
| allow for WebAuthn only login
| gtirloni wrote:
| It's not intercepting anything. It's classical social engineering
| that got automated with bots.
| hoarad wrote:
| indeed. it s still the user fault
| Finnucane wrote:
| Right. If you want good security, just remove the users.
| 3np wrote:
| So, it sounds like one could use this to legitimately recover an
| account where one has lost the phone number, the service provider
| requires SMS auth to get back in? Using it on yourself and it
| becomes account recovery as a service.
| iou wrote:
| I don't think this is "the rise", inline attacks had been a known
| weakness of these security mechanisms almost since inception.
| IncRnd wrote:
| That's not what the article said. "The rise" doesn't refer to
| the attack but to the increase in the OTP Interception "bots".
| [1]
|
| [1] (The Rise) of (One-Time Password Interception Bots)
| croes wrote:
| Isn't the same way the used to get entry from a TAN list? Pose as
| a valid receiver, ask for authentication, pass it through to
| access whatever you want.
|
| Don't give an answer if you didn't initiate the process.
| hannob wrote:
| Ultimately what this shows is that two factor authentication with
| either TOTP (aka Google Authenticator) or SMS is not ideal. It
| makes phishing harder for the attacker, but it does not prevent
| it.
|
| Unfortunately he fails to mention that there is a way to do 2fa
| that does prevent phishing: Hardware tokens with the webauthn
| protocol.
| toast0 wrote:
| Two factor with a code device (totp, rsa token, sms, etc) isn't
| effective for phishing, but it is effective against non-
| interactive attacks like cracking password files or brute force
| or password reuse.
|
| Something like webauthn that ties the token to the usage
| context and so addresses phishing (until the host security is
| broken) and also addresses non-interactive attacks is clearly
| better from that perspective, but it's not as easy to setup two
| of those as it is to setup TOTP on two devices at the same time
| or be able to put your SIM in another phone or get a new SIM
| (this is, or course, a negative if someone else gets a new SIM
| for your number). And then there's the extra cost (until/unless
| it's more integrated into devices people already have)
| CyberRage wrote:
| the hell are you talking about? why make out wrong "facts"?
|
| 2FA is very useful against phishing:
|
| https://security.googleblog.com/2019/05/new-research-how-
| eff...
| toast0 wrote:
| It doesn't work so well if the phishers also make a 2fa
| phishing page. People confused enough to put in their
| password on the login page will also put it on the 2fa
| entry phishing page.
| CyberRage wrote:
| I work in the industry if it wasn't obvious though for
| years now nothing to do with phishing but I do have some
| experience shall we say.
|
| 1. Building a phishing page and can accept 2FA and in
| real time(remember code is useless after 30 sec) logs in
| to an account is much harder. most attacks are low
| quality junk.
|
| 2. From a detection standpoint, this is awesome. the
| attacker has to log in real-time. he will likely send
| that link to hundreds of people = good telemetry to
| detect anomalies\fraudulent logins.
|
| 3.* Another pain I remember observing was regarding the
| login process itself. Websites tend to change their log
| in UI\processes, different websites have different
| layouts.
|
| This makes it frustrating and tedious maintain, bank
| changes the login prompt, attacker has to modify code to
| accommodate that.
|
| 4. Data doesn't lie, it is not bulletproof but it does
| offer significantly higher level of protection. saw that
| in actual enterprise with my own eyes.
| julianlam wrote:
| I disagree. TOTP-based 2FA is leaps-and-bounds more secure than
| SMS based 2FA and will stop nearly all attempts to access your
| account.
|
| The fault here lies with victims answering a prompt to enter
| their 2FA out of the blue. Just as with passwords and other
| such info, the bank will never request it for no reason.
|
| A hardware token using webauthn protocol is most secure though,
| yes.
| jrochkind1 wrote:
| In the linked article on the words "the scammers can get
| around that, too" [1], there's an account that claims the
| legit bank _did_ in the past ask for the 2FA on a phone call,
| in pretty much exactly the same way the scammers did.
|
| > _Mitch said his financial institution has in the past
| verified his identity over the phone by sending him a one-
| time code to the cell phone number on file for his account,
| and then asking him to read back that code._
|
| The advice from Krebs about phone calls is _never_ talk to
| "the bank" (etc) when _they call you_ , always you have to
| call them back. But the bank _will_ really sometimes contact
| you "out of the blue" to ask you about potential fraud on
| your account. You just have to hang up and call them back,
| you can't tell the difference based on "reasons".
|
| It is very hard for the end-user to tell what 2FA request is
| "for no reason". I think we need to focus not on what the
| "reason" is or if it's "out of the blue", but, the equivalent
| of "call them back" for online too -- don't click on a link
| in an email, etc.
|
| No matter what, it's not easy, especially for less technical
| users. The linked account is a _security professional_ that
| fell for it -- I personally don 't have the hubris to think I
| never would.
|
| There have been times when an actual bank asks me to do
| something I _know_ is insecure, and I consider resisting it,
| but I just didn 't have the energy for it, I figured it
| really was the real bank just being idiotic and I wanted to
| get on with my day (and guess what, it was, I was right).
|
| [1]: https://krebsonsecurity.com/2020/04/when-in-doubt-hang-
| up-lo...
| londons_explore wrote:
| While "call them back" is good practice, you should
| remember that even outgoing telephone calls aren't
| authenticated or encrypted. An advanced enough attacker can
| totally redirect your outbound calls too - it's just a
| little harder without an insider in your phone network.
| rwmj wrote:
| You shouldn't be downvoted because you're right, although
| for a slightly different reason. Scammers definitely have
| been using this trick:
| https://security.stackexchange.com/questions/100268/does-
| han...
| pdonis wrote:
| _> An advanced enough attacker can totally redirect your
| outbound calls_
|
| How?
| londons_explore wrote:
| The attacker rings your phone company up, impersonates
| you, and gets your phone line added to a company plan
| where all dialled phone numbers are first passed to a
| company phone system to allow the mobile phone to act
| like an internal phone - so for example you can dial
| "753" to ring the phone in room 753 of your company
| office. Calls will only go to the external phone network
| if the internal company one rejects them.
|
| Then the attacker can intercept any outgoing call.
| ziml77 wrote:
| Is this even possible? An external number's calls getting
| routed around to the internal side of a PBX without
| explicitly dialing into the PBX?
| bluGill wrote:
| Possible, you need to convince the phone company, but it
| is done just often enough for real reasons that it is
| posisble
| Piskvorrr wrote:
| Feasible. Far more work required, and the plan switch
| should trigger all sorts of red flags (and thus
| verifications) before you even place a single phone call.
| smiley1437 wrote:
| So to be safe, I should call them back on a one-time use
| burner phone? What would you recommend for the call back?
| idiotsecant wrote:
| What, and trust that they didn't compromise the hardware
| manufacturing supply chain? Not today, criminals! I
| design and construct my own one time burner phone from
| silicon I personally extracted and refined, it's the only
| way to be secure!
| jrochkind1 wrote:
| You have to find the address of the call center, and go
| there and ring their bell.
| nucleardog wrote:
| But don't just google the location! The scammers are onto
| this now and have set up fake call centres and banking
| branches to trick you.
|
| You need to start from a reasonable root of trust like
| your local government. Go down to city hall and ask them
| to pull the business license for the organization, and
| visit the address on file there and work your way down
| through the organization to the department you're trying
| to contact.
| mortenjorck wrote:
| Perhaps orders of magnitude more likely than someone
| getting root on your telecom network is someone simply
| convincing you that an attacker's VOIP number is the
| official support number you wanted to call.
| jetpackjoe wrote:
| If your threat vector is someone hacking/infiltrating
| your phone network, you have bigger problems.
| TameAntelope wrote:
| The critical aspect about this is, "What can I do about
| it?"
|
| For most hacks, the answer is, more or less, "Nothing." For
| a social engineering hack like this, you _can_ be aware and
| avoid falling victim to this.
|
| For me, reading this article, that's the meat of it -- I am
| trying to figure out how vulnerable I specifically am to
| this, and what I need to do to stay safe (and what I need
| to recommend to my family and friends). Sometimes it's
| "hope the organizations that have your data are secure",
| but this time it's the same advice I usually give, "Don't
| ever tell anyone anything, and NEVER give out passwords to
| anyone."
| jrochkind1 wrote:
| > but this time it's the same advice I usually give,
| "Don't ever tell anyone anything, and NEVER give out
| passwords to anyone."
|
| OK, but if the legit banks are actually *asking you to
| read back 2FA codes on the phone"... I assume you include
| a 2FA code as a "password" since that's what we're
| talking about... you'd just refuse to talk to them when
| they call you about potential fraud? Find a new bank that
| doesn't do that?
|
| Krebs advice to "never give out personal info or 2FA
| codes when they call you, always call them back at the
| number on your card" seems like a more useful/actionable
| appraoch to me than your "never give them personal info
| or 2FA codes at all".
|
| So, anyway, yeah, krebs advice is "actionable", but...
| it's not easy. To remember, or to do when you're busy and
| trying to get on with your day dealing with banks and
| other bureacracies that routinely "legitimately" ask you
| to do crazy things.
| TameAntelope wrote:
| > OK, but if the legit banks are actually asking you to
| read back 2FA codes on the phone"... I assume you include
| a 2FA code as a "password" since that's what we're
| talking about... you'd just refuse to talk to them when
| they call you about potential fraud? Find a new bank that
| doesn't do that?
|
| You find independent corroboration of what they're
| telling you. If the _only_ evidence you can find in your
| account that something went wrong is what someone is
| telling you over the phone, it 's almost certainly itself
| an attempt at fraud.
|
| If you can't, reveal nothing and reach out to them
| separately (call the bank back) to find out more.
| jrochkind1 wrote:
| I think I'm going to go with krebs advice which is just
| call the bank back right away as first step, not as
| something you do after you on your own try to "find
| independent corroboration." Just hang up call them back
| at the number on the back of your card. Only provide
| personal info when you've called the known number, not
| when you've received a call, period. (which is actually
| different advice than "never provide personal information
| at all", or "only provide personal information after
| doing your own independent investigation for
| corroboration")
| TameAntelope wrote:
| Okay, that sounds great. I'm going to continue to do
| things that include but aren't limited to using a phone
| and human speech to better understand the situation.
|
| I think we'll both be in pretty good shape!
| tshaddox wrote:
| > The advice from Krebs about phone calls is never talk to
| "the bank" (etc) when they call you, always you have to
| call them back. But the bank _will_ really sometimes
| contact you "out of the blue" to ask you about potential
| fraud on your account. You just have to hang up and call
| them back, you can't tell the difference based on
| "reasons".
|
| Don't forget that you have to call them back by looking up
| your bank's phone number yourself from a trusted source
| (perhaps their HTTPS website). Obviously just calling back
| the number they called you from (or provided to you) is
| useless.
| MaxBarraclough wrote:
| This hasn't happened to me personally, but I've read of
| security-conscious people receiving legitimate fraud-
| warning calls from their bank, and then struggling to get
| back in contact with the right people. Not every bank is
| set up to deal with security-conscious customers,
| apparently.
| jfengel wrote:
| It baffles me that their fraud alert texts include a
| callback number. It's like training users to be gullible.
|
| It should say "Call us back at the number on the back of
| your card", or some such.
|
| I'm sure they're afraid that a lot of users won't figure
| that out, but it still seems like a weird tradeoff.
| tinus_hn wrote:
| Unfortunately not having a phone number on the back of
| the card saves a ton of money on customer service calls.
| jfengel wrote:
| My cards all have a toll-free number on the back of the
| card. When I get a call, text, or email from my CC
| company that requires a phone call, I call them at that
| number.
| tinus_hn wrote:
| That's great! Most banks do not have that because it
| might be toll-free for you, it definitely isn't free for
| them.
| gertrunde wrote:
| I have received such a phishing call recently.
|
| The script went something along the lines of:
|
| "Hi, we need to authenticate a recent transaction of
| $high_value_item, well send you a verification code to
| prove we are $company_x." <receipt of OTP code via SMS from
| $company_x> "Can you repeat the verification code to
| authenticate?" "Of course this isn't a scam, we must be
| $company_x, how else could I send you the verification
| code?"
|
| I can definitely see general members of the public falling
| for this sort of scam - because they are being led to
| believe it's not a one-time-password that they're relaying
| at all, and some organisations do use verification codes of
| that sort, although usually it's to verify ownership of a
| particular mobile telephone number when setting up an
| account or pairing an app or similar.
|
| I wouldn't expect non-technically savvy folk to immediately
| spot the difference between a verification code and a one-
| time-password.
|
| It might be good if the OTP SMS message had text along the
| lines of "Do not give this code to anyone under any
| circumstances, regardless of who they claim to be employed
| by." - not that I would expect it to help in all cases.
|
| (tbh - I was actually quite impressed, the English skills
| of the person on the other end of the telephone were
| significantly better than the average tech support call
| center person).
| croes wrote:
| It's always the same. Don't click a link, type it yourself,
| of course your banks address and not the link from the
| mail. Don't answer a phone call, call them back.
| skeeter2020 wrote:
| That's not the same thing! Here the scammer's app is saying
| "enter the one-time token generated by your device", then
| passing that on to the phisher. Your quote is about letting
| the bank know that the device is in the possesion of the
| person they are talking to.
| jrochkind1 wrote:
| From the OP:
|
| > OTP Agency customers would enter a target's phone
| number and name, and then the service would initiate an
| automated phone call that alerts that person about
| unauthorized activity on their account. The call would
| prompt the target to enter an OTP token generated by
| their phone's mobile app ("for authentication purposes")
|
| What are you saying is the distinction that an ordinary
| user should be expected to distinguish, between a phone
| call that says it's from your bank alerting you to fraud
| and asking you to read back a 2FA code, and... a
| different kind of phone call that says it's from your
| bank alerting you to fraud and asking you to enter an OTP
| code in a different way?
|
| It's a pretty similar thing. In these particular cases,
| you and I could realize that a bot asking you to use
| keypad to enter the code is more suspicious than a human
| asking you to read it. But it's not like humans can't
| scam you too, as in the other story I linked to from
| krebs. And it's all a bit subtle and overwhelming for the
| average user (who of course encounter bot voice systems
| all the time when dealing with 'legitimate' businesses
| these days).
| indymike wrote:
| > I disagree. TOTP-based 2FA is leaps-and-bounds more secure
| than SMS based 2FA and will stop nearly all attempts to
| access your account.
|
| At present, you are right. In the future, this may not be
| true, especially the "will stop nearly all attempts" part of
| what you are saying because the weakness in any security
| strategy is people.
| dheera wrote:
| Are there any major US banks that support web'n'auth?
| time0ut wrote:
| Some banks will request a 2FA code. I had Citi call me, then
| send me a code via SMS, then ask for the code on the phone.
| The SMS looked identical to the one I would get when logging
| in. My spider sense started tingling and I declined and hung
| up. Called them back directly and sure enough it was really
| them.
| hamburglar wrote:
| Unfortunately, both Microsoft and Apple have conditioned
| users to just provide their credentials out of the blue when
| asked. Microsoft in office, which just randomly asks me for
| my credentials to perform some communication between app
| components (I see this a lot when opening powerpoints for
| some reason), and Apple because my iOS devices are constantly
| wanting me to re-auth with my appleid. So people probably
| don't think twice about it. I know my kids think constantly
| canceling an appleid login prompt without reading it is just
| part of using an iPad.
| donmcronald wrote:
| This is the biggest issue. Some sites ask for your TOTP
| every time you log in, so a phishing site asking for it
| won't seem out of the ordinary.
| md_ wrote:
| The fault with phishing _always_ lies with the victim, by
| this logic.
|
| Put differently: if you assume the user to be infallible,
| there's very little reason to use 2FA of any kind. (Don't
| believe me? Describe to me a threat which applies to an
| infallible password-only user which is mitigated by non-FIDO2
| second factors.)
| jdavis703 wrote:
| I leave my work desk to grab a coffee. An attacker adds a
| hardware keylogger between my keyboard and computer. When I
| come back 5 minutes later I don't sweep for any hardware
| modifications. Now they have my password.
| CyberRage wrote:
| What? that's absolutely not the reason for 2FA... if he
| can key-log your passwords, he can keylog your 2FA
| code...
|
| deployment of a keylogger means your host is compromised,
| from there you can do so much you really don't need
| someone's password...
|
| 2FA is for plain phishing attacks. building phishing
| attacks against 2FA is significantly harder and usually
| easier to detect\protect from.
| UncleMeat wrote:
| This threat model is orders of magnitude less likely than
| something like phishing. It is not scalable for attackers
| and simply doesn't work for anybody who works from home
| or works in a location with meaningful physical security.
|
| It also isn't defeated by 2FA, since they've physically
| installed something on your machine to detect your
| keypresses. They just capture your password and the sms
| code.
| jdavis703 wrote:
| The post asked to "Describe to me a threat which applies
| to an infallible password-only user which is mitigated by
| non-FIDO2 second factors." Defense in depth is absolutely
| a thing. Now does your grandfather need this level of
| security? Probably not. But that doesn't mean multi-
| factor is worthless.
| UncleMeat wrote:
| But it isn't. The key logger steals your second factor
| code just the same.
| nyuszika7h wrote:
| That only works if the site allows replaying codes and it
| doesn't expire before the attacker logs in with it.
| md_ wrote:
| Sure, I guess. I would tend to argue that with hardware
| access they can do a number of things, though:
|
| - They can install a wifi-enabled* keylogger that
| exfiltrates your OTP. Yes, they have to use the OTP
| before you do, but that seems solvable to me--just
| program the keylogger to transpose one of the six
| characters that comes after your (now known) password.
|
| - They exploit any number of likely plug-and-play
| vulnerabilities in common OSes (e.g.
| https://www.thetechherald.com/tech-news/disable-plug-n-
| play-...).
|
| - They steal your computer. Are you using FDE? If not,
| your cookies are sitting there on disk waiting for them.
|
| - They...steal your phone next time you forget it at your
| desk. ;)
|
| Are there scenarios where TOTP can protect against a non-
| phishing attack? Yeah, I can construct one if I really
| have to. (I think you're thinking too locally; my top
| argument for TOTP would be that I can rarely be sure the
| identity provider has implemented reasonable quotas
| against password brute-forcing--and who knows how well
| they secure things like server logs against rogue
| insiders?)
|
| But if you tell me you use TOTP because you're afraid of
| a local attacker plugging in a keylogger--and not because
| of phishing--I think your priorities are out of whack. :)
|
| * Or they use a covert channel, but I'm not serious about
| this part: https://dl.acm.org/doi/10.5555/1267336.1267341
| hsbauauvhabzb wrote:
| I work in infosec, I literally write phishing sites. A good
| phishing site with MFA would easily fool me. How's grandma
| gonna stand a chance?
| tialaramex wrote:
| WebAuthn saves granny though. Because it's so easy that
| granny can't get confused. The best way forward under
| WebAuthn is to have her physically send them her Security
| Key.
|
| Now, granny may not be down with the latest Tik Tok trends,
| but she has seen keys before, and the analogy is strong -
| so I think she can get this right.
|
| To be fair, scammers have been successful with scams that
| involve an actual bike courier (presumably the scammer or a
| friend) coming to pick up your bank card, but that at least
| feels a bit reasonable because it does say the card remains
| property of the bank, so, sure, have your card back. And
| I'm also guessing this is a much higher friction scam than
| the average "Phone support in India" setup. I reckon scam
| dozens of people for their card this way and somewhere
| around the 100 victims mark the guy opening the door to
| your courier has a baseball bat, or worse, and your courier
| has a bad day.
| mint2 wrote:
| When you call Amex for a while (and maybe still) will send a
| onetime password for things that need added verification and
| ask you to share it with them. The text itself says don't
| ever share it.
| dotancohen wrote:
| > The fault here lies with victims answering a prompt >
| to enter their 2FA out of the blue.
|
| Go wish 10 random people happy birthday. For some people such
| a greeting is relevant for one day only. For others, a week.
| For some people, especially if the don't recognize you and
| think that "it's been a long time" a whole month is valid.
|
| If one is using a dozen services that auth with 2Fa and needs
| to log in once per day, that's a lot of windows of
| opportunity. Multiply that by 86,400 numbers phished that
| day.
| UncleMeat wrote:
| We've spent years and years and years trying to train people
| to resist phishing. It doesn't work. Even actual literal
| security professionals fall for it. If you use a thing with
| such common known failure modes, it is your responsibility
| for using that thing.
|
| Phishing is enormously more common than sim-swapping because,
| as described in TFA, it can be fully automated. Going from
| SMS to TOTP fixes a rare attack but does not fix a common
| attack.
| Laforet wrote:
| So what other options do we have available? We have tried
| client certificates, hardware tokens, biometrics and a
| tonne of heuristics. None of these could do much to stop an
| attack when the user is cooperating with the scammer.
| UncleMeat wrote:
| Webauthn works. You cannot sign a message for the wrong
| origin. The core problem here is that everybody needs
| access to some sort of hardware to do this and they need
| systems to handle the inevitable loss of that hardware.
| withinboredom wrote:
| Literally Windows and MacOS has this built-in. But you're
| right, the hard part is losing the token or it breaking.
| I slammed one Yubikey in a door, breaking it in half. I'm
| on my backup but I still find services where I didn't
| enroll the backup and have to go through a lengthy
| process to regain access to my account (or create a new
| one).
| jdavis703 wrote:
| Hardware tokens and biometrics are better because it
| makes it harder for the scammer to describe a plausible
| scenario to intercept the authentication.
|
| In one of the linked articles the scammers pretended to
| send a one-time token and asked the victim to read it
| back. This is the same process my top-10 US-based bank
| uses, so it wouldn't necessarily raise any red flags.
| jorvi wrote:
| I think against somewhat trained people only spear phishing
| is effective which is the type of phishing that can't be
| automated
| UncleMeat wrote:
| The data does not seem to support this. Yes, spear
| phishing is even more effective. But oodles and oodles
| and oodles of exercises demonstrate that people, even
| experts, fall for phishing.
| formerly_proven wrote:
| Experts fall for phishing because many businesses,
| including and _especially_ financial institutions (PayPal
| and eBay are easily some of the worst offenders here),
| make it essentially impossible to tell phishing from
| their "legit" mails.
| remexre wrote:
| Doesn't WebAuthn fix phishing? I was under the impression
| the secrets are tied to individual origins by the browser.
| UncleMeat wrote:
| It does. This is why every service should be making
| active plans to push in this direction. We've struggled
| with this problem for ages and it is now _completely
| solved_.
| GekkePrutser wrote:
| Does it really though? I love Webauthn. It is so much
| better than passwords. But I don't think it means the end
| of phishing. Phishers will evolve too and find new
| tricks. Just like they did here with OTP interception
| bots.
|
| For example a phishing site could trick me into
| authenticating into a fake site, and give them a session
| at the real site as a result. They won't have my actual
| credentials but they could have a session which is enough
| to do a lot of damage.
|
| I don't think Webauthn guarantees that the site I'm
| authenticating to is the site I'm supposed to (though I
| may be wrong here, I didn't read into it too deeply). As
| far as I know it still relies on TLS for that, and
| regular phishing and typosquatting show that this is not
| airtight. It would be great if the authentication worked
| both ways, the server would authenticate to the client as
| well as it does to the server.
|
| It does raise a few other questions too. If every site
| uses Webauthn, I will have to update every site when I
| get a new yubikey. That's going to be a PITA.
|
| A solution for that would be using an identity service..
| Like "Sign in with Google". But I would never trust a
| commercial service like Google, Facebook, Microsoft for
| this. It would have to be something open and privacy-
| safe.
| UncleMeat wrote:
| > For example a phishing site could trick me into
| authenticating into a fake site, and give them a session
| at the real site as a result.
|
| The fake site needs to be hosted somewhere, presumably
| not on the same origin as the real site. As such, your
| key will be _unable_ to sign a message for the phishing
| site regardless of how hard you try.
|
| This is the core difference with SMS/TOTP. With those
| models nothing stops you from handing the material over
| to a site on a different origin and letting them reflect
| that material to the target site. With webauthn, the
| thing you hand the phishing site is useless for
| authenticating on the target site.
| tialaramex wrote:
| > I don't think Webauthn guarantees that the site I'm
| authenticating to is the site I'm supposed to (though I
| may be wrong here, I didn't read into it too deeply). As
| far as I know it still relies on TLS for that, and
| regular phishing and typosquatting show that this is not
| airtight.
|
| WebAuthn needs the DNS name of the site to _exactly_
| match. This isn 't for humans, who think 1 and I are
| pretty similar, it's for a machine, which thinks they're
| different. Phishing and typosquatting don't get you
| google.example they get your
| google.comsecurityupdatelogin.example or goggle.example
| which do not match. Now, in principle you could attack
| the Ten Blessed Methods to get yourself a real,
| legitimate (albeit fraudulently obtained) certificate for
| the exact DNS name of a real popular site, but that's not
| easy, and indeed making it more difficult is a continuing
| focus of Web PKI work. Also, defenders can make it
| arbitrarily harder if they put work in.
|
| I never tired of explaining the clever trick that makes
| this possible, so here goes (for the easy case of a cheap
| Security Key, something like an iPhone can do fancier
| tricks with more complicated explanations)
|
| When you enroll at some.example, your Security Key is
| told we're enrolling at SHA256("some.example"). A button
| flashes and you push it. The Security Key picks a
| completely random public/private key pair. It uses the
| private key to sign a document, "Hello, I am this
| Security Key, I checked a human was present" and it
| encrypts the private key with its own _symmetric_ key and
| with that SHA256( "some.example") parameter as "Extra
| data" in an AEAD (Authenticated Encryption, Extra Data)
| cipher to produce a large opaque blob it will claim is a
| "random identifier". It sends the public key, the "random
| identifier" and the signed message back to your web
| browser. You are enrolled.
|
| When you come back to the site, the site says oh, your
| account requires a Security Key, prove you still have it.
| It sends one or more of those "random identifiers"
| corresponding to enrolled Security Keys. Your browser
| talks to any Security Keys plugged in, hey, I'm at
| SHA256("some.example") and it asked if anybody can prove
| I'm still some-huge-identifier ?
|
| Your Security Key tries to decrypt some-huge-identifier
| using its symmetric key, and the Extra Data
| SHA256("some.example"). Maybe it gets a success and a
| private key. The little button flashes and you push it.
| In this case it can sign a message using the private key,
| "Yes, I'm still me, I checked a human was present"
|
| But, if _anything_ goes wrong, that decryption will fail.
| If this is some-other.example, SHA256( "some-
| other.example") won't match and decryption fails. If the
| site picks random gibberish instead of your identifier,
| decryption fails. If you plugged in the wrong Security
| Key, decryption fails.
|
| You are unable to even _try_ to authenticate to the wrong
| site. And if they _enroll_ you which they can do, now
| they 've got useless credentials for you to sign into
| their site that are unrelated to the credentials on other
| sites. They're even deliberately not correlated and they
| aren't even wasting space on your Security Key, the
| Security Key (this is why the trick was so clever)
| doesn't store anything to make all this work! All the
| storage is in the Relying Parties, and it's all storage
| of _public data_ that 's harmless when inevitably crooks
| steal it.
| GekkePrutser wrote:
| Ah thanks for clarifying. I didn't know that Webauthn did
| that. I had planned to read up in it in detail but at
| work it has been ruled out for implementation for the
| next months so it didn't have priority :)
|
| I really appreciate the breakdown of how it works! I
| agree this makes phishing almost impossible (at least
| without obtaining a valid cert which is in itself really
| hard for a non state actor)
| loudmax wrote:
| In my experience, banks and other online institutions have
| spent years training their customers to fall for phishing
| attempts by sending legit emails with embedded links.
| People take it for granted that emails coming into their
| inbox that contain links to login pages really are from
| their bank, because that's how their bank behaves normally.
| stanleydrew wrote:
| I hadn't ever thought about this but you're right. Best
| practice for sensitive services like banks should be to
| have no links at all in emails. I don't think that's
| likely to change though.
| ezekg wrote:
| Sort of off-topic -- but related to "they would never request
| that" -- recently, I reached out to Hover's support due to a
| billing issue. The support agent eventually asked me for my
| 2FA code and I literally sat back in my chair and mumbled
| "...what?" I told them, "absolutely not." Then I told them
| that typically, they would request access and then I would
| have to approve it. They then proceeded to follow protocol.
| This agent was literally asking to take over my account, and
| I guess they can bypass passwords but not 2FA. I know Hover
| != $Bank, but regardless, it made me very uncomfortable and
| has me second guessing Hover's security practices.
| flixic wrote:
| Banking systems in Baltic countries use a unified 2FA
| system called SmartID[0]. When authenticating to bank via
| phone, they ask for two things: your user ID (which is not
| secret), and to authenticate using Smart ID, which means
| entering a PIN on your phone.
|
| However, each PIN entry is accompanied by "code check":
| bank's support person says their 4 digit code, and you can
| verify that it matches on request for PIN screen. This
| neatly prevents someone pretending to be a bank during a
| call, because each PIN request uses a different "code
| check".
|
| [0]: https://www.smart-id.com
| londons_explore wrote:
| It can still be man-in-the-middle'd. Theres no way to
| know the attacker isn't calling you on one line while
| calling your bank on the other. As soon as you've
| authenticated, they'll continue talking to your bank, and
| fob you off with some excuse like "oh, the system is
| down, can you call back tomorrow".
| btown wrote:
| Is it still vulnerable to a MITM attack though, e.g.
| https://krebsonsecurity.com/2020/04/when-in-doubt-hang-
| up-lo... ?
|
| Attacker wants Victim's code. Attacker calls the Bank
| impersonating Victim, and also calls Victim impersonating
| the Bank. Bank tells Attacker the code check, Attacker
| tells Victim the code check, Victim sees the match and
| enters their PIN into the Smart-ID app, and Attacker's
| phone session with Bank is now fully authenticated and
| has no more need for Victim.
| im3w1l wrote:
| I like how the ones in my country work, when you want to
| send money you have to sign the transfer with the 2fa
| app, and the 2fa app itself will display how much money
| you are transferring, preventing an mitm from displaying
| one amount but actually sending another. However the
| recipient is not displayed. So a mitm could modify a
| legitimate transfer to have another recipient, stealing
| the $100 destined for your utility bill. But at least
| that is not a catastrophic loss.
| flixic wrote:
| For transfers, Smart ID displays both recipient and
| amount. So that part can't be easily MITM'd.
| flixic wrote:
| I never thought about this, but yes, I think it can be
| MITM'ed exactly as you described. Same attack can
| probably be performed on the web, where Smart ID is also
| a sign in method.
| u801e wrote:
| > Unfortunately he fails to mention that there is a way to do
| 2fa that does prevent phishing: Hardware tokens with the
| webauthn protocol.
|
| This could also be done using client side TLS certificates
| without restricting the application protocol used on top of the
| TCP connection.
| ttul wrote:
| An increasing number of websites are now offering their own
| authentication app, which uses a secure back channel to push
| authentication requests down to the user's device.
|
| While it's a pain to have a dozen authentication apps on your
| phone, IMHO this method is just as secure as a hardware module
| while being much more convenient.
|
| I'm sure that there is a start up that recently announced
| itself here on hacker news that is creating a universal
| authentication app that will allow any website to authenticate
| users in this way. Great idea.
| withinboredom wrote:
| Authy?
| chrisbolt wrote:
| And what's the recovery method for the authentication app? If
| it involves SMS...
| ttul wrote:
| The best practice is a piece of paper with backup codes on
| it. And if you don't store that properly, you're out of
| luck. Nothing is perfect, but paper in a safe is pretty
| good. The cryptocurrency world has introduced titanium
| backup code holders, where the code letters are literally
| etched into titanium. Bullet proof, fire proof, etc..
| donmcronald wrote:
| How does that help? If I put my credentials into a phishing
| site and then get a prompt on my phone to approve a login,
| why wouldn't I click approve? Plus, then the attacker often
| gets a cookie showing their device passed 2FA.
| ttul wrote:
| The newest authenticators make a fingerprint of your
| browser and use that to select a random number that they
| show you in the app, along with other "controls". You have
| to pick the correct number, which of course the attacker
| will not have.
| hsbauauvhabzb wrote:
| Hardware tokens were commoditised by yubikey but they really
| should be TPM based, until there's critical mass it'll be a
| nuanced technology and Yubikey clearly don't have the clout.
| CyberRage wrote:
| There's no need for yubikeys. we have the ultimate key, our
| phones.
|
| Most modern phones have SE(Secure Element) or virtualized
| secure zone(ARM Trustzone) which can act as de-facto key.
|
| Google already uses it to great success(most people are
| clueless to that though)
| chopin wrote:
| The Yubikey at least requires me to press it in an
| authentication process. If it's software only an attacker
| could gain access stealthily.
|
| It's already hard to trust OS and browser. Therefore I'd
| prefer a physical interaction on a device where the behavior
| cannot be altered.
| hsbauauvhabzb wrote:
| TPM is a hardware chip which effectively implements the
| same concepts as yubikeys but predates them by about a
| decade.
| md_ wrote:
| TPM-based like...Windows Hello?
|
| Both Windows and Mac support host-based FIDO keys. Of course,
| the downside here is that you...can't move them to a new
| computer. So they're sort of hard to use on their own, hence
| people still turn to portable (but less secure) solutions
| like TOTP and SMS.
| hsbauauvhabzb wrote:
| Fair point, I'm not super familiar with hello. The problem
| of cross-computer access is solvable* - add cryptographic
| trusts to transport encrypted data across insecure
| hardware.
|
| *I didn't say it'd be great user experience though.
| md_ wrote:
| Yep, Apple solves this by moving FIDO key material around
| via iCloud, I believe. But it requires a good syncing
| mechanism like that.
|
| In principle it's similar to the password manager
| problem, which is a bit ironic: if everyone used password
| managers, most of the same security issues would be
| resolved. (There are a few cases where a FIDO key is
| better than a password manager, but not many!)
| ufmace wrote:
| > Hardware tokens with the webauthn protocol
|
| It'd be nice, but support for them around the web seems to be
| mostly terrible. Only a tiny handful of sites support it at
| all, and most of the ones that do support it don't support more
| than one, which seems kind of essential to actually use it
| long-term and guard against the tokens breaking or getting lost
| or damaged.
| tialaramex wrote:
| > most of the ones that do support it don't support more than
| one
|
| Do you have _any_ examples besides AWS?
| ufmace wrote:
| Well now that you mention it...
|
| I had been thinking of Github and Cloudflare, but I
| actually just checked both of them and they do now allow
| multiple keys to be registered. So I guess that's gradually
| getting better.
|
| It's still pretty amazing that AWS still doesn't allow
| multiple 2FA methods though.
| thunderbong wrote:
| Key point from the article -
|
| > This service (and all others mentioned in this story) assumes
| the customer already has the target's login credentials through
| some means.
|
| > OTP Agency customers would enter a target's phone number and
| name, and then the service would initiate an automated phone call
| that alerts that person about unauthorized activity on their
| account. The call would prompt the target to enter an OTP token
| generated by their phone's mobile app ("for authentication
| purposes"), and that code would then get relayed back to the bad
| guy customers' panel at the OTP Agency website.
| nextos wrote:
| There are OTP algorithms that allow both parties to identify
| each other (not just one way where the server confirms the
| identity of the client), so you can't be subject to a MITM
| attack.
|
| In EU, 2FA is mandatory, but it's really frustrating that the
| law allows to use SMS codes as a second factor. The typical
| hack in my country is to use a rogue employee in a phone shop
| to clone a SIM card, and then you are screwed up.
| jrimbault wrote:
| Can eSIM be cloned ?
| g_p wrote:
| Yes - eSIM is just the same keys used in 3GPP, but
| distributed differently.
|
| You could do a "SIM swap" to a traditional SIM in exactly
| the same way, using phone customer support or retail store
| IT.
| tinus_hn wrote:
| And of course allow resetting the password over sms.
| [deleted]
| jaywalk wrote:
| Push notifications to a smartphone app for login approvals is by
| far the most convenient 2FA method and also more secure than TOTP
| or SMS. I use it wherever I can.
| tialaramex wrote:
| Push notifications mean that if you believe you're logging in,
| and the crook is _actually_ logging in, (not a coincidence,
| they understand how this works) you get a push notify, which
| you accept because you think you 're logging in, and you
| thereby let the crook in. Brilliant.
|
| Prefer WebAuthn.
| jaywalk wrote:
| With Okta, it tells you the approximate location of where the
| login request is coming from. So unless the crook happens to
| be in the same city as me, I'm going to immediately see that
| something is wrong and decline the request.
|
| Not perfect, sure. Webauthn is definitely more secure, but
| far less convenient.
| lucb1e wrote:
| > an uptick in services on the cybercrime underground that allow
| attackers to intercept one-time password (OTP) tokens [...] we've
| seen actors provide access to services that call victims, appear
| as a legitimate call from a specific bank and deceive victims
| into typing an OTP or other verification code
|
| So not intercept, just phish.
| EB66 wrote:
| There's an interesting way you can implement TOTP that avoids the
| phishing problem described in the article. The method doesn't
| work for all situations, but it works for many -- it works
| particularly well if all you're trying to do is protect access to
| a mobile app.
|
| At my company we have a mobile app and we use TOTP for MFA. But
| instead of requiring a separate app like Google Authenticator to
| generate and type in 6 digit codes, we store the TOTP secret and
| generate the 6 digit codes all internally. In other words, we
| bundle the functionality of Google Authenticator directly into
| our own app.
|
| From the user's perspective, it's wonderfully simple: the user
| scans a QR code on our website and they're instantly enrolled in
| MFA. Then for all subsequent logins, they just type in their
| username and password -- the 6 digit TOTP code generation is
| handled silently in the background.
|
| With this approach you get all the benefits of TOTP-based MFA,
| but without the phishing risk. For all the mobile apps out there
| that offer TOTP as a form of MFA, I'm surprised how many of them
| require you to use a separate authenticator app.
| psadauskas wrote:
| How does that work if the user logs on via a new device? (Or
| the attacker, knowing the user's password, does the same?)
| EB66 wrote:
| If the user gets a new device then with this approach they
| would have to re-enroll in MFA.
| Johnny555 wrote:
| Is there any advantage of doing that versus just using a client
| side certificate to authenticate the device?
| EB66 wrote:
| I suppose that could work, but one potential advantage of
| TOTP is that the secret/seed used to generate the 6 digit
| codes is never transmitted and not at risk of being
| intercepted.
|
| It's also probably more user-friendly to put a TOTP
| secret/seed on a device than it would be a client
| certificate. A certificate would probably be too big to
| easily scan with a QR code. QR codes can hold large amounts
| of data, but with more data the QR becomes larger and the
| detail becomes very fine. The camera needs to be very good,
| lighting needs to be very good, etc.
| e12e wrote:
| Neither is the key for a ssl cert generated on the device?
| In fact, with qr enrollment the 2fa approach _does_
| transmit /expose the secret (probably over https, but
| still).
| EB66 wrote:
| True, you can't generate a QR code without transmitting
| the TOTP secret/seed in some fashion, but it's a one-time
| event that's typically done over HTTPS like you
| suggested.
| Johnny555 wrote:
| Just as with normal server side TLS, the client doesn't
| send its private key (and it's not known to anyone but the
| client), so intercepting the certificate doesn't do the
| attacker any good.
|
| But if communications intercept is possible, even with TOTP
| the attacker could intercept the TOTP token for that
| session and use it to log in himself.
| wepple wrote:
| So the TOTP seed is deployed to a specific users mobile app?
| EB66 wrote:
| Yep, that's correct.
| wepple wrote:
| Really fascinating idea I hadn't heard of before. Felt
| "icky" at first pass, but it's no different to having a
| separate TOTP gen app, in fact given it stops you from
| having to copy/paste the code around, possibly less
| exposure there.
|
| The only downsides I can think of is that if the app local
| data is exposed, you possibly lose your cached creds and
| the TOTP seed.. but most apps are toast if there's a full
| local data exposure. I guess the other challenge is if you
| have to do a (full) app reinstall, you've got to re do the
| MFA config. But app reinstalls seem extremely rare these
| days (basically only when you get a new phone)
|
| Very fascinating idea
| EB66 wrote:
| > I guess the other challenge is if you have to do a
| (full) app reinstall
|
| Yeah, that's true, if the user does a full app removal
| and re-install then they would need to re-enroll in MFA.
| But for app updates they'd be ok.
|
| > The only downsides I can think of is that if the app
| local data is exposed, you possibly lose your cached
| creds and the TOTP seed..
|
| That's a good point too, but what you're describing would
| probably require someone to fully compromise (root) a
| phone. If that happened, you'd be SOL on many fronts. At
| my company we try to safeguard against rooted phones by
| 1. only holding user credentials in memory and 2. pairing
| our app with a public key that encrypts the password as
| soon as it's entered (our servers then decrypt it with
| the private key upon receipt).
| nicoburns wrote:
| > Yeah, that's true, if the user does a full app removal
| and re-install then they would need to re-enroll in MFA.
| But for app updates they'd be ok.
|
| How would they re-enroll without their MFA token? Surely
| the whole point is not to let them login without it?
| EB66 wrote:
| It'd be the same process that you have to follow if you
| lost your phone and, along with it, all the TOTP seeds
| that were stored in your Google Authenticator. You'd have
| to go through whatever process the company requires to
| confirm your identity through alternative means and allow
| a re-enrollment in MFA.
| nodamage wrote:
| What happens when the user gets a new phone or deletes and
| reinstalls the app?
| EB66 wrote:
| They would have to re-enroll in MFA, but that's the same
| thing that happens today if someone uses Google Authenticator
| and gets a new phone (or uninstalls Google Authenticator).
| nodamage wrote:
| I'm not sure I understand. Aside from their password, does
| the user need to provide additional information to re-
| enroll in MFA on a new device?
| EB66 wrote:
| That additional information would vary, but you basically
| would follow the same process for someone who loses their
| device (and along with it their TOTP authenticator app).
| You might send them a SMS code, require them to call in,
| etc.
|
| Basically it'd be no different than what companies
| already do today when someone loses their device and
| their authenticator app.
___________________________________________________________________
(page generated 2021-10-01 23:01 UTC)