Hacker News Reader

Comment by Scaevolus | Hacker News Reader

Beating 2FA is almost always SMS hijacking, but sometimes it's social engineering where the attacker has figured out just the right script to tell support ("oh, I dropped my phone and it won't turn on...") to get it disabled.

edit: correction, beating 2FA without phishing-- like in the post where he lost his account while asleep.

View on HN

> Beating 2FA is almost always SMS hijacking

That's most definitely not true, as someone who works in this space. Plain old phishing is much more common, where the hacker tricks a user into entering their code into a malicious website.

To echo OP, this is why it's important to support non-phishable types of 2FA.

Could you describe the types that are non-phishable?

WebAuthn (or its predecessor U2F but that's obsolete, so in green field deployments do WebAuthn) is the only practical non-phishable second factor for ordinary users on the web.

You can do this two ways, one of which will make more sense for your web site:

1. PCs/ laptops/ etc. can use little USB hardware devices, from outfits like Yubico, the word to Google or type into your preferred hardware source is "FIDO" although if you have spare cash and like cool toys FIDO2 is a more capable second generation of the technology.

In this situation the FIDO authenticator is your second factor. Your web browser takes responsibility for telling this authenticator which web site you're looking at, and it's just a dumb machine, so from its point of view obviously refunds-my-bank.example isn't mybank.example because those strings are different. The FIDO authenticator just does whatever the browser tells it.

This could be attacked by specialist malware, but it's tricky because the FIDO authenticator wants you to take physical action to trigger authentication, so the malware needs to not only tell the authenticator "Yeah, I'm totally er, Internet Explorer, and I need you to authenticate for mybank.example" but also persuade you to press the button or whatever to make it happen.

Or I guess bad guys can be like "please FedEx your FIDO dongle to us" if people really are that dumb, but then no need for phishing, just call people "Hey, I'm the IRS, send me $5000 in unmarked bills, in a FedEx box marked er cat food for some reason that totally makes sense, to a residential address in a different state, yeah".

2. High end smartphones, the sort with a fingerprint reader, can do the same exact trick using that fingerprint reader (I think some iPhones do facial recognition instead?) to do WebAuthn instead for their onboard browser.

In this case the smartphone is in charge of everything, it knows which web site this really is, it knows if that's really your fingerprint or not (the fingerprint never leaves your device) and it decides whether to send credentials.

For machines it's much easier to do a secure transaction, but machines don't fall for a lot of phishing scams.

> PCs/ laptops/ etc. can use little USB hardware devices, from outfits like Yubico

This is actually built into most computers now -- Windows Hello, and Apple has something similar. Websites can check the attestation response to specifically block those, however. (Seems like Github allows it, and I've written code that allows it.)

> I think some iPhones do facial recognition instead?

Yup, they use whatever you use to unlock your phone. So if it's a FaceID phone, you can use FaceID to log in. You can also hold up your NFC Yubikey to the back of the phone and use that, even if you registered the key over USB on a PC! It's really, really good.

> Websites can check the attestation response to specifically block those, however. (Seems like Github allows it, and I've written code that allows it.)

For the client side of things WebAuthn contains a standard option to block/allow "platform" authenticators, which I empirically know includes Windows Hello, and I'm not sure about Apple's or other equivalents. Of course you'd still want to verify the attestation on the server side.

> Of course you'd still want to verify the attestation on the server side.

You almost certainly do not want to do this for a public web site. If you insist on attestation right thinking people will hit "No" and block the site.

Think about it, what is attestation doing for you in this scenario? You're saying that you don't trust your users/ customers to pick the authentication methods that work for them, and instead you're going to insist on methods you prefer. Do you also choose each user's passwords? "No, sorry, that resembles an English word, we have selected the password 48'J3X$q)M3NBfr_2 for you instead" ?

In a corporate environment this could make sense. If you issue every employee a $100 FooCorp Security Key with their photo engraved on it, maybe you decide to require attestation that the keys used are FooCorp brand keys to prevent employees adding some off-brand Yubico product. I don't know whether that's a good idea, but it's no crazier than lots of corporate policies, however doing this for a public site makes no sense, please just skip attestation.

Yes! Any developer that forces the user to use a specific type of device needs to be smacked around a bit (or more accurately, the manager that told them to do it that way). Banks are notorious for this, since their stupid 2FA apps will do insane things like scan your app list for common root-only apps and non-vendor ROMs (even with no root). Some even have a vendor whitelist that obscure brands (like OnePlus used to be) aren't on and in both cases, their only response is "well just factory reset your phone" or "just buy a different device". I've switched banks twice because of this insanity.

And there's no reason to do this! It's not like they're liable if I get my money stolen. If they prove 2FA was used and the security issue was on my device, not their app/server, it's my fault! As you said, if you're a custodian of something sensitive (an account, documents, money..), not the owner of it, it makes sense that the owner shouldd be able to dictate how you should protect it (like if you're accessing confidential company documents using 2FA). But in any other case, the service provider should never be allowed to force you to use a certain type of authentication device.

Can you hold your NFC Yubikey to the back of an iPhone? I thought Apple didn’t do NFC, appart from ApplePay?

Your recollection was correct but is now a few years out of date. As is typical Apple they intro'd it (in 2017 IIRC) as a 1st party dogfood item, started read only. Then in 2019 with iOS 13 allowing far more power including full range of two way authentication capability. Yubico blogged about it [0] after the announcement, and Apple's HIG on use of NFC [1] is also available. Also, Safari itself needed to have support added, but that too is now available.

So old workarounds like using the lightning port are no longer necessary, though AFAIK are still supported. It's nice to have it there as well since to really be most effective every platform a user has needs to support hardware 2FA. If something still needs SMS or OTP or whatever that becomes the weakest link.

----

0: https://www.yubico.com/blog/yubico-ios-authentication-expand...

1: https://developer.apple.com/design/human-interface-guideline...

My NFC Yubikey works fine with my iPhone 8.

It's built into Apple devices yeah (touch ID) but this is only supported in Chrome and Safari.

Firefox does NOT support Touch ID for webauthn

I can't make sense of your explanation.

In 1) I don't think my YubiKey knows anything about the sites I use it for? It just creates keys, so a phishing site could presumably still steal the key created by YubiKey and pass it on to the real site.

2) My fingerprints definitely don't know anything about web sites. So WebAuthn being unphishable has nothing to do with fingerprints. It is only incidental that some devices decide to unlock the functionality with fingerprints.

1) The browser tells the Yubikey: "sign this: 'logging in to site.com at 12:34PM'". The yubikey signs it and gives the signature to the browser. The browser gets the signature and passes it on to the site. attacker.com will get a signature over 'logging in to attacker.com at 12:34PM'. That signature will not allow the attacker to log in to facebook.com .

2) Correct. In fact you don't even need a hardware token. You can do the whole thing in software. It could even theoretically be built right into your browser (but you would have the problem of logging in to the account on a different device or different browser). The fingerprint protects against physically stolen devices, and slightly against malware on your computer.

> The browser tells the Yubikey: "sign this: 'logging in to site.com at 12:34PM'"

It's even a little bit cleverer than that. During enrollment (to say, Facebook.com) your Yubikey provides a random looking "identifier" to Facebook.com, and it promises that it can sign future logins if Facebook.com shows it the same identifier. The identifier is bound to the DNS name!

So a phishing site has a few choices, none of which help the bad guys even a tiny bit:

* It claims to be Facebook.com, but it isn't, so the web browser just doesn't even show the UI for Security Keys. There's a behind the scenes Javascript error basically, "What? You aren't Facebook.com fool".

* It admits its real DNS name, and makes up a random identifier. The browser gives the random identifier and the real DNS name to your Yubikey. But, it has never heard of this combination, so, it blanks the entire authentication figuring this must be for a different Security Key plugged in on another port or something.

* It gets that identifier code for your login from Facebook, and then admits its real name to your browser and provides the identifier taken from Facebook. This still doesn't match, and the Yubikey again assumes it must be for some other Security Key on your system.

Behind the scenes this is actually done with AEAD cryptography, maybe with AES keys baked inside your Yubikey. The "identifier" is actually something like a private key (likely elliptic curve parameters) that has been encrypted using an onboard secret AES key in an AEAD mode, with the DNS name (well, a hash derived from it) as a factor.

As a result, your Yubikey can't even decrypt the "identifier" correctly in order to log you in without the matching DNS name. This means goofs in the implementation fail safe - e.g. one brand of cheap Security Keys can fail to sign in once every 256 tries on average due to a logic bug. But they'd never sign in where they shouldn't because of mathematics, to do that they'd need to "accidentally" completely break the mathematical foundations of the cryptography!

I'm still waiting for password managers to add soft-WebAuthn support, so I can log in using my password manager (and no physical keys or passwords). That would make password managers ten times better.

Then again, it doesn't have to be the password manager that does this, but it'd be nice if it were integrated.

yes exactly! Bitwarden supports TOTP nicely already. And I think you can authenticate to it with FIDO2 apparently. It would be awesome if it could do software-based WebAuthN but I don’t think it does…

It doesn't, unfortunately. I've opened an issue on their forum but nothing yet. Not many websites support WebAuthn (let alone passwordless), so I guess password manager vendors aren't in a hurry to implement it.

At high level imagine it like this:

The browser will only give access to the Yubikey token for a specific domain name - so if the attacker phishes for examle.org, rather then example.org, then there is just no tokens (signing keys) available the Yubikey could use and give to the browser.

In the early days WebUSB in Chrome had bugs that allowed to bypass that same origin check but that has been fixed 3 years ago.

I've been using the browser's password manager as protection against phishing, as the password manager won't fill in passwords on the wrong site. So I guess it works in a similar way with the Yubikey? OK.

At a very very high level yes - but the reason you want to use tokens is that you get a second factor and you have better entropy and created tokens are time based (password is valid forever).

And of course client side certificates. It's a pity they are rarely available as an option on public websites.

The UX for client certificates is horrific, especially if you choose the more secure approach of storing them on a smart card.

It certainly would make sense to improve the UX as opposed to coming up with different implementations.

webauthn basically forces use of HTTP as the application level protocol, whereas a client side TLS certificate will work regardless of which application protocol is in use.

Client certificates, as the name might hint, certify your identity. But a big thrust of technologies like U2F and WebAuthn was not to do that, for privacy reasons.

My FIDO authenticator has no idea who I am, no opinion who I am, so you can't use it to do identity correlation. It's only useful for the very specific problem we wanted to solve "Are you still you?" "Yes".

In contrast a client certificate for u801e is enduring proof you're u801e and signatures the client cert makes during login will be durable proof that u801e logged in. PornHub can show Facebook and GitHub that the same user is using their site. So that's a privacy hole you can drive a truck through.

There are numerous practical problems with trying to leverage TLS client certificates for this work, but that's a big privacy problem.

> In contrast a client certificate for u801e is enduring proof you're u801e and signatures the client cert makes during login will be durable proof that u801e logged in. PornHub can show Facebook and GitHub that the same user is using their site. So that's a privacy hole you can drive a truck through.

Client certificates can certainly be separated based on different domains. So, there would be no way to really determine my identity across multiple websites if I sent each one a different CSR and they each gave me different client certificates. The browser should only send the client side TLS certificate that's relevant to the server it's trying to connect to via TLS.

The main purpose of the client side TLS certificate is to verify the identity of the client on the server side, just as a server side TLS certificate signed by a trusted CA allows the client to verify the identity of the server. In the case of the client side TLS certificate, it doesn't have to be signed by an outside entity. There could be an internal CA the server uses to sign those CSRs and when the client connects, the server need only to verify that the client cert presented has a valid internal CA signature.

There's no reason why it has to be horrific. I'd like to see someone make a decent attempt at making client TLS certs actually work well, including not using the same cert for multiple domains by default. Other problem is, I don't think many web server frameworks have support for them either.

> if you have spare cash and like cool toys FIDO2 is a more capable second generation of the technology.

Why would you want passwordless authentication? Isn't the whole point of 2FA that you have to have something and you have to know something?

The cheapest available FIDO2 option is PIN-based so your PIN (actually any password, it doesn't need to be like a bank PIN) is the something you know, and the FIDO2 authenticator is something you have, two factors. You don't need to pick a PIN to have conventional "second factor" working but if you want a usernameless authentication you can have that by choosing a PIN.

What's different compared to having a web site password? The web site knows the password, but they don't know your PIN. This means suddenly relatively weak human memorable passwords are good enough, because bad guys can't break in and steal 40 million of them in seconds or leverage them across multiple sites, the PIN is useless without the authenticator.

But other FIDO2 authenticators can do fingerprints, making it something you are (a person with that fingerprint) and something you have (the authenticator) so two factors again.

Usernameless (rather than passwordless) is the differentiator. You can literally have the sign-in flow be a "Sign In" button and the user does the thing (finger on reader, types in PIN, or maybe looks at camera) and they're authenticated. No step where you type in an email address or a username. This has a privacy cost because it means the authenticator knows in some sense who you are, but it is super convenient if that's what you're all about - while being much more secure than today's username + password dance.

The FIDO2 key is usually protected by a PIN that wipes the key after a few wrong attempts, so it combines the two itself.

Besides, there's nothing that dictates how secure the key should be. You could use your hardware cryptocurrency wallet for this, which is probably much more secure and convenient than the average Yubikey (you can duplicate it with the seed phrase).

You can duplicate the Yubikey or the hardware cryptocurrency wallet?

Wouldn't the ability to duplicate it make it weaker?

You can duplicate the wallet. It would make it weaker, but it's more secure in that they usually have hardware keypads for you to enter your PIN on.

Some people care more about convenience than security. And for everyone else, it doesn't have to be passwordless. You can use a regular password and a FIDO authenticator.

So, popping up three comments, this explains which types of 2FA are not phisable:

> I wish he'd mention what kind of 2FA. The reason you _really_ should use U2F/WebAuthn is because it does origin binding which, unlike entering a TOTP, a code from your hardware token/authenticator app on your phone/SMS/etc is not phishable, i.e. you can't enter it by accident on accounts.google.com.totallylegit.ru and then have them enter it on real accounts.google.com. This is so because the U2F/WebAuthn security key signs a request, sent by your browser, which embeds the requesting page's domain, so a signature on attacker.com will not pass victim.com's verification checks, whereas a code from your authentication app is trivially copied.

The first comment in this thread describes why U2F is unphishable.

Yubikey is one - it requires the user touch a hardware device which signs something locally that I think is never sent? I don’t know enough of the implementation specifics, but it’s supposed to guard against this kind of thing.

Yubikey is actually pretty "phishable", at least in the OTP mode. It will happily put the token into a phishing website (or literally anywhere else) as soon as you touch it.

It's also good to know that Yubikey's OTP tokens don't expire based on time, but based on a hidden counter that gets incremented with every issued token.

So if you've accidentally touched your Yubikey and leaked the token publicly, you just have to log out and then log back in using your Yubikey - that action will invalidate all tokens issued before this point.

Yubikeys (or at least some models) can be configured with multiple different OTP implementations. Yubico's own OTP implementation behaves as you have described. It is not a guarantee that generating an OTP from a Yubikey means you have generated a Yubico OTP.

YubiKey uses U2F and FIDO2/WebAuthn. The YubiKey also does a lot of other things, depending on which YubiKey you have... but if you want 2FA on random websites, those are the most likely protocols (used for GitHub and the like).

The basic U2F + FIDO2/WebAuthn is the least expensive model, around US$25. These days it works seamlessly on Chrome, Firefox, and Safari.

What happens if the Yubikey goes bad? I use one for work, and the last 2 keys I had developed some hardware issues, and stopped responding, so I had to get a new one.

The recommendation is to have at least one backup key.

There's also a WebAuthn extension in the works to at least make it easier to maintain a backup key by not having to pull it out of the safe every time you register MFA with a new service:

https://www.yubico.com/blog/yubico-proposes-webauthn-protoco...

I really wish I could find a password manager which supports WebAuthn, and can also be unlocked with WebAuthn, so that only one secret needs to be replaced in such a situation.

I wondered about this in regards to Crypto and NFT's in the digital wallet space. It seems like Metamask with a ledger wallet is stadard, but I have a theory that if you're not sophisticated and you get into Crypto/NFT's, it may be safer to just use Coinbase Wallet, as it is less popular target than matamask and you're able to leverage Coinbase's ongoing security updates. and if you're not sophisticated, you're just as likely to lose your stuff via user error with a hard wallet set up.

Just don't click on giveaways and never enter your secret code

How’s it any relevant?

Another poster has mentioned it, but I will add weight. This is super ultra mega wrong.

Phishing SMS and TOTP codes is way more common than SIM-swapping. Outrageously so. SIM-swapping does not scale. You need to call up a company each time you want to do it. Yes, it works. But you cannot sell a tool that just automates it. In comparison, there are many off-the-shelf phishing kits that fully automate SMS and TOTP 2FA theft.

Old school phishing is the most common MFA bypass.

Here is a description how it works:

https://github.com/wunderwuzzi23/KoiPhish

Unless you use Yubikeys (webauthn) etc these phishing attacks just continue to work. I do consultancy in this space at times and about 95+% of folks who enter their password will also enter their MFA token.

Followed the link and the read me is bit spare on details. For the less technical this still would require the phishee to manually enter credentials which then can be relayed to the attacker. Correct? The article mentions this happened while the author was asleep — any thoughts on how that would work?

One thing that can happen is you get enduring credentials from the OTP sign-in, and they last despite other credentials simultaneously existing elsewhere.

I only use Facebook trapped inside Facebook Container in one Firefox on one computer. But my understanding is that it's possible to sign in to Facebook from say a phone and a laptop at the same time, so the bad guys could get you to give them working credentials one day and persist those until you're asleep before using them. If you went to Facebook's security settings "Where you're logged in" and it lists two logins, one in "Paris" while you are in New York, you might realise there's a problem and force them out. But most people likely never look at that, why would they?

I might be tempted to enter the TOTP, but my browser is unlikely to enter the password, and I definitely won't.

I think the fact that password managers can spot incorrect urls better than users is useful. However I've become numbed to this warning flag by those services that seem to have endless different urls that are all legitimate. (Microsoft being a particular offender here).

I can imaging some variant of outlook.microsoft.developer.really.yes.com catching me unawares one day.

Microsoft does seem to know how to do this correctly when they have to, as they offer WebAuthn and there is deliberately no way to tell WebAuthn "I know this is outlook.com but I need live.com credentials". So they will bounce you through the right name to make it work. But you're correct that for phishing this habit of making up new DNS names is a problem, ie it convinces the lay person they have no idea and should just fill in their password wherever it's requested.

It’s probably worth faking having lost your 2FA and asking for it to be reset. If you find out they are this careless with 2FA-protected accounts, you should probably not rely on it too much.

I manage an authentication and identity provider and if someone gets locked out of 2FA and can’t prove their identity via a previously-uploaded gpg key, they get locked out for good. I never honor requests to reset the device sent by email, no matter how much they beg or offer to prove identity by sending copies of official IDs - I don’t care who they are now, I care about them being the same person that set up the account and 2FA, which can only be proven via a valid 2FA device or a GPG signature.

> It’s probably worth faking having lost your 2FA and asking for it to be reset.

I'm not sure I trust that I'd be as good an attacker as a professional, and there's not a great way to replicate "hang up, call again" approaches likely to work with a big org.

It could be worth it to spend the 1.50$ on stripe to do identity verification with id documents for accounts of a certain size, so that they can present those documents again to regain access to their account.

Re-enabling the account after a certain period of time without activity would also be a good measure (on top of the id verification).

And then lose the documents in a big hack so that everyone with a forum access can use your passport copy. yes.

The whole point of using Stripe for it would be not to have the documents in question. Kind of like you don't hear about companies using stripe losing their customers' card numbers.

Google is better than all other alternatives in that regard. They have a feature called Advanced Protection where you add your 2FA U2F keys and if you lose them your account is gone. No social engineering possible.

https://landing.google.com/advancedprotection/

> if you lose them your account is gone

IMO, this is way too extreme for almost everybody. There needs to be some sort of happy medium so that a person who's lost everything they own (e.g., house fire) can get their account back somehow still. Two ideas I had:

1. When you set up your account, provide your legal name, date of birth, and a photo. If you need to reset 2FA, go somewhere in person with a government-issued photo ID (which we already have procedures to replace) that all of the details of match.

2. When you set up your account, provide 5 trusted contacts. If you need to reset 2FA, get 3 of them to agree.

Advanced Protection does have the account recovery. https://landing.google.com/advancedprotection/faq/ It is just very slow as it's a human process. There's very little reason you shouldn't use Advanced Protection, if your account is important enough.

Big caveat being you can no longer use the account to develop things with the Google API or use some third party clients (e.g. rclone).

Which Google API do you mean? I use advanced protection and have developed various things with various Google APIs, I just use a service account with minimal privileges for each thing I'm developing, which is probably best practice anyway. Not sure about rclone but probably it would work fine with a service account too?

It blocks any unverified OAuth app, including the ones you create yourself.

It sounds like you're trying to use APIs with your personal account rather than using a service account though? Again, I use Advanced Protection and I've never encountered the problem you're describing.

I'd just use a dummy account for developing.

>If you need to reset 2FA, go somewhere in person with a government-issued photo ID (which we already have procedures to replace) that all of the details of match.

Very few people are going to want to pay for this labor if the perception of risk of using a free account is as low as it is now.

What about giving people a choice like this to pay for the labor? Either pay $1 per month for your account, and then this service is free for you whenever you need it, or have a free account, but then this service costs you $1000 if you ever need it.

That would be nice, but I imagine there's a perception problem with that.

Simply offering the option would bring the risk to the forefront of people's minds, and once you start exchanging money, lots of other thoughts and liabilities begin to enter.

If it is kept free, then the conversation ends there.

If you choose to opt-in to Advanced Protection, you can keep a backup hardware token somewhere outside of your house.

My concern with that is that if something happened to the off-site token (e.g., ESD damage, or even just random failure over time), I may not realize until I needed it.

If you would like to take advantage of such an option, you are also opting in to taking on an operational burden. That burden is exactly maintaining a set of backup keys and testing them on a regular basis.

And that's why "everyone should just use yubikeys" is never going to happen.

Everyone already pays the same operational burden with their house keys, which are far more difficult to manage for the average person (as they leave the house constantly). It's worked fine for hundreds of years.

If you lose your house keys, you get a lock smith to break into your house for you - your house doesn't become unusable forever more.

If you ever need to have this done, you'll realise how much house keys and door locks for many cases really only stop the opportunistic "pull the handle and see if it opens" attack. If your door has above average security they'll need to drill the lock, but the time I had to call one they could just push a tool through the letter box and break/move the bolt by applying leverage from the "indoor" side.

> If you lose your house keys, you get a lock smith to break into your house for you - your house doesn't become unusable forever more.

Same with 2FA. Just like a Locksmith it's a "human in the loop" situation where you'll need to give identification etc.

The rest of your post isn't relevant it's just about picking door locks.

House keys don't just randomly break the way electronics sometimes do, though.

I would bet that door locks and keys break pretty often. I know I've had many door locks that you had to wiggle just right.

I agree with this, it was my original expectation.

I've always thought the Post Office should offer something like Option #1.

That way you end up with the same issues as we have now with SIM swapping: Post Office employees are not more reliable and not necessarily more careful with their credentials than people who can give you a new SIM card.

The post office does (did?) ID verification for first-time passport applications. I think that’s about as good as you can reasonably expect since it gets you a bona fide, universally-accepted proof of ID that would work anywhere else.

I would bet that the post office employees are a bit less susceptible to the “hurry up and hit your metrics” pressure than someone at the Verizon call center.

In another universe, the Post Office manages the email services, too. Sigh ...

“If you lose your key and are still signed in on one of your devices, visit account.google.com to add or replace a key. Otherwise, submit a request to recover your account. Google may take a few days to verify that it’s you and restore your access.”

I trust that it would be (potentially much) harder than normal, but it still seems to be possible.

I was under the impression you were screwed in that case, thanks for pointing out that I was wrong. It's lot less secure than I thought.

Still sounds like a significant barrier to most phishing attacks.

A little bit. It's mostly a time delay, since the alternatives to verify your identity seem to be a different emailaddress or a phone number and then you're back to square one imo. The phone number is still susceptible to social engineering and the alternative mail likely is too. Ideally I want something where keys gone = account gone. Now a dedicated scammer could still succeed and it sure doesn't provide any real safety for political groups which Google kind of claims it does by using testimonies from politically vulnerable people to "advertise" the Advanced Protection Program. This is a tricky situation though since your adversaries could get your keys and your password and then they control your account without any chance of getting it back, so it's definitely a double edged sword.

> It's mostly a time delay, since the alternatives to verify your identity seem to be a different emailaddress or a phone number and then you're back to square one imo. The phone number is still susceptible to social engineering and the alternative mail likely is too. Ideally I want something where keys gone = account gone.

I can think of options less extreme than keys gone = account gone that are still very secure.

e.g. To enable "Extra Advanced Protection" you have to visit Google HQ in your region, where your DNA is sampled. If you ever need to recover your account, you have to visit Google HQ again for another DNA sample, after which you're provided with account access, in person.

Definitely also a good, but still very extreme option. This might actually be more secure, depending on the threats you have to take into account. It would be possible to retrieve the account after a (physical) hack.

Just showing up in person by itself (with a stored photograph and maybe audio recording) is a pretty high barrier.

> DNA sample

and who's gonna pay for that? Seems pricey and doesn't scale exactly well.

I presume in this scenario you would have multiple keys and multiple backup accounts, so fallback to a likewise secured account is reasonable.

IIRC, Google will stop the "several day process" if you log in at any time.

Oddly enough, Google's Advanced Protection is the gold standard in my opinion, yet Firebase Auth, an Auth-as-a-Service product from Google, only supports SMS as a second factor, which is baffling to me.

How is it possible that some kind of imaginative script can be enough to get SMS sim swapped? Why aren't the operators requiring a strong identification via a passport or something like that? Maybe I'm really dumb but that just boggles my mind, whether or not there exist other types of alternatives to 2FA.

There's not much you can confirm over the phone, except the account PIN and sometimes security hint. But an attacker can pretend to have forgotten it and press that the matter is urgent. If the attacker knows enough about the person, they might be able to convince an agent to make the swap so the agent can:

1) Get on with their day to maybe hit a support request quota 2) Make sure this person doesn't give them a bad customer satisfaction score

You could require verifying your identity using your electronic ID if you want to simswap by calling the helpdesk.

They could require this. Most of the big operators have physical stores where they could do an ID check. There should be an advanced protection mode where SIM swaps and other sensitive operations require physical authentication.

Yes this, please!

How does an sms hijacking attack typically work? I know sms isn't secure, but how does one go from having a password to bypassing the sms confirmation? Is it as easy as having the number and carrier?

It happened to me. Cellular carriers, in my case T-Mobile, didn't require any confirmation to port a number to a new phone/sim.

Eventually some required the last 4 of your social security number to port a number, which we all know at this point are pretty much public anyway.

T-Mobile now lets you set an arbitrary pin, which my parents promptly set to their DOB :facepalm:

I haven't looked more into it, but as far as I know, sim swap/port attacks were hilariously simple to execute which is why I only use SMS verification when it's the only option.

You might want to edit out what your parents set their pin to! (You can email hn@ycombinator.com if you're past the edit window.)

Lol, I had made them change it as soon as they told me.

Maybe what is needed is regulation that makes the service provider liable (with no option to disclaim it) for all damages suffered by the victim if the provider gives away their phone number to an attacker.

I accidentally ‘hijacked’ a number by typoing one number in my online request. I only found out after my wife pointed out my number was different after porting. It took a couple hours with the telco’s support agents, and practically no verification steps, to actually get my correct number back. Very sad state of affairs here.

Don't they just hijack your number with the help of the telecom company's helpdesk?

Wouldn't that be obvious to the victim the moment their phone didn't work? Or will the carrier leave the old SIM activated?

IIRC, in the US, sometimes just give the old sim some random phone number (to keep you paying the bill) and don't cancel the line. In the EU, I'm pretty sure they cancel the old line.

> ...has figured out just the right script to tell support ("oh, I dropped my phone and it won't turn on...")

Isn't this vishing? https://youtu.be/BEHl2lAuWCk

No; phishing / vishing is contacting the customer to get login details. Contacting support and getting them to circumvent security is social engineering.

>Beating 2FA is almost always SMS hijacking

How exactly does this get executed? I'm pretty technical, but I cant fathom exactly how this occurs;

You hijack a cell tower, then have some system to listen to un-encrypted SMS traffic??

Plz ELI5

It's zero cost and zero effort to port someone's number out, or get a new SIM card issued for the existing account.

I've worked with a bunch of streamers and YouTubers, and the threat model is such that people have shown up with professionally made printed fake IDs to attempt hijacking in an actual retail carrier store.

It's an attack on humans, not on technology. You trick their phone carrier's employees into thinking that you're them and that you lost your phone. Then you end up with a SIM card assigned to their phone number, so you receive all of their calls and texts instead of them.

There is also the ad which runs on the same webpage and reads what you type or your clipboard.

Reply on news.ycombinator.com