Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Most Expensive Lesson of My Life: Details of SIM Port Hack

medium.com

Post reply on HN
Print view View original

71–80 of 251 posts

Re: The Most Expensive Lesson of My Life: Details of SIM Port Hack

#71

Post by Gwypaas »

knorker wrote: post #57
Gwypaas wrote: post #45

Earlier quoted context omitted.

I checked, to get a replacement sim my carrier sends out inactive cards that needs to be activated through their web service using the printed number on the card. If you don't have an account you need to contact customer service, and to get through there they most likely authenticate you based on your SSN and an already active app on your phone (BankID) where you input your personal password. This has actually create…

See recent Tele2 attacks. This is a problem in Sweden too. Maybe the Tele2 attacks made them finally sort things out.

Googled. Is it regarding using social engineering to enable call forwarding last autumn? Can't find anything else.

Re: The Most Expensive Lesson of My Life: Details of SIM Port Hack

#72

Post by yellingdog »

graeme wrote: post #70
Klathmon wrote: post #62

Earlier quoted context omitted.

>Many password managers (at least KeePassXC/KeePass with plugin) can store and create TOTPs. Personally I don't really like this feature and urge people to avoid it for "high security accounts". It's not a "second factor" if it's stored and input using the same device and authentication information as your "first factor" (your username and password). That's not to say it's useless, at the very least it's another laye…

What's a good secondary service to store the TOTP codes separate from passcodes? Authy, from what I understand, requires a phone number as backup, meaning it could be compromised by the same method Google authenticator can't be backedup, which is royally annoying when you change/lose devices Lastpass has some security issues, and one well known comment here has recommended no one use it. I heard someone say they use…

You can back up the Key used to set up the TOTP system. This allows you to re-seed the TOTP generator on a new device without needing to go through setup.

Re: The Most Expensive Lesson of My Life: Details of SIM Port Hack

#73

Post by badpun »

maxlamb wrote: post #15

Large tech companies like Google push 2-factor auth to "increase" security, but this article shows that 2-factor auth with SMS verification opens up a huge security hole since the attacker can access your email if they can get your provider to port your SIM over to their device. Am I missing something and if not how did companies like Google not foresee this huge security hole?

I don't know if that's possible in gmail, but in protonmail you can just disable password recovery altogether, which makes your email account secure against these kinds of attacks.

Re: The Most Expensive Lesson of My Life: Details of SIM Port Hack

#74

Post by Klathmon »

graeme wrote: post #70
Klathmon wrote: post #62

Earlier quoted context omitted.

>Many password managers (at least KeePassXC/KeePass with plugin) can store and create TOTPs. Personally I don't really like this feature and urge people to avoid it for "high security accounts". It's not a "second factor" if it's stored and input using the same device and authentication information as your "first factor" (your username and password). That's not to say it's useless, at the very least it's another laye…

What's a good secondary service to store the TOTP codes separate from passcodes? Authy, from what I understand, requires a phone number as backup, meaning it could be compromised by the same method Google authenticator can't be backedup, which is royally annoying when you change/lose devices Lastpass has some security issues, and one well known comment here has recommended no one use it. I heard someone say they use…

Personally I use Google Authenticator. The lack of a backup is a feature not a con IMO.

Every account I have setup with TOTP I also make sure to print out the recovery codes and put them in a safe, and use them if my device is ever destroyed. When I switch phones (which for me happens maybe once every 2-3 years at most), I go through the shitty process of transferring the TOTP codes over to the new device, but it doesn't really take all that long (it took me an hour to do it for about a dozen accounts last time I did it), and I'd much rather not have any of it uploaded anywhere.

You can print out the QR code or save that somehow during setup and use that to setup TOTP codes on other devices (or the same TOTP on multiple devices), but I tend not to do that as recovery codes work just as well, and they notify you if they are used (unlike a TOTP setup QR code). I did have to store the QR code for one account that doesn't provide recovery codes, but it's overall not that much extra work.

Re: The Most Expensive Lesson of My Life: Details of SIM Port Hack

#75

Post by aeorgnoieang »

knorker wrote: post #59
tga wrote: post #12

Part of the problem here is the lack of fraud insurance from CoinBase/exchanges. If the attacker would have instead stolen from his bank (several US and Canadian banks I know happily allow logins with only a password or are only starting to introduce SMS-only 2fa), it is likely that the bank would have returned the money, whether they could revert the transaction or not, and then pursued the hackers themselves.

because they can (usually) revert it. Because reversibility is a good thing.

Fraudulent transactions made with a regular bank account are pretty irreversible too. There's a whole extra layer of infrastructure on top of the 'core' banking services that allows them (banks) to 'reverse' a fraudulent transaction. But I'd be very very surprised if fraudulent charges are 'reversible' in any other way than the bank reimbursing the account holder.

In other words, crypto-currency exchanges could do the same thing (but then they'd almost certainly have/want to charge for that).

Double-entry bookkeeping is also, ideally, irreversible.

Re: The Most Expensive Lesson of My Life: Details of SIM Port Hack

#76

Post by apo »

781 wrote: post #13
apo wrote: post #6

> Do not leave funds idle on exchanges or fiat on-ramps. This warning has been publicly repeated hundreds of times since 2010, yet people still insist on ignoring it. The author didn't lose anything. He gave Coinbase his bitcoin in exchange for a promise to pay it back. That deal backfired. > I knew the risks better than most, but never thought something like this could happen to me. There's knowing the risk, and the…

Do you also keep your cash under your mattress, instead of into a bank account?

That line of thinking is part of the problem. It's terrible that the author lost his money, but misconceptions only ensure this will happen over and over.

Coinbase != bank.

The banking system has a safety net for recovery of stolen funds. Coinbase has pretty much jack squat in that sense.

True, Coinbase is insured against loss from its hot wallet. But if Coinbase were to suffer a loss from its cold wallet, you'd be left with zilch.

Likewise, Coinbase's terms of service put all of the responsibility for security on you, the user.

Your bank is a different story. It's FDIC insured. It has in place numerous security measure that enable it to claw back any digital theft and make you whole.

Re: The Most Expensive Lesson of My Life: Details of SIM Port Hack

#77

Post by apo »

galimaufry wrote: post #69
781 wrote: post #13

Earlier quoted context omitted.

Do you also keep your cash under your mattress, instead of into a bank account?

Someone please correct me if I'm wrong, but at least in the US banks take on all risk of fraud. If someone starts writing bad checks in your name, that's ultimately the bank's problem rather than yours.

Coinbase is not a bank. It acts like one. It spies on its customers on behalf of federal regulators like one. But it most definitely is not a bank.

The author has to eat the loss, as per the user agreement.

Re: The Most Expensive Lesson of My Life: Details of SIM Port Hack

#78

Post by mleonhard »

rando444 wrote: post #50
inetknght wrote: post #25

> Google Voice 2FA Unfortunately many places are actively refusing to work with Google Voice. I got a message from Bank of America saying specifically that they're removing Google Voice support: > You can't enroll in Zelle with a landline, Google Voice or VOIP (voice over internet protocol) phone number. (Section 3.C.3 Enrolling in the Service) This follows with some other unnamed (because I don't remember them) serv…

If you ported a previous phone number to google voice, how would they know?

It's easy to find out the company hosting a phone number: http://twilio.com/lookup

Re: The Most Expensive Lesson of My Life: Details of SIM Port Hack

#79

Post by romwell »

mAEStro-paNDa wrote: post #64
BlackRing wrote: post #46

Earlier quoted context omitted.

A non-federally controlled pseudo-anonymous currency similar to cash has the positive upside of enabling digital privacy in spite of the blockchain. That's why. There are still trustworthy tumbler services to obfuscate and hold your bitcoins similar to a bank. And with what some claim, inarguably so, of government overreach and corporate over-sharing of your personal data, it's something I can sympathize with.

Similar to a bank as in a guaranteed insurance of my funds, like the FDIC in the US?

FDIC is the government overreach the parent was talking about.

It's also a relatively new thing.

People who cry about government overreach seem to rarely ponder why it is there in the first place. Well, TFA shows why.

Re: The Most Expensive Lesson of My Life: Details of SIM Port Hack

#80

Post by kevin_b_er »

The major US provides are looking to get you to replace all your logins with direct cell-provider authenticated logins, so they can skip the email recovery part:

https://www.fiercewireless.com/tech/project-verify-will-brin...

With this the attackers get direct access to all your services once they socially engineer or identity theft attack your cell account once.

Post reply on HN