A little less convenient for a LOT more security.

But because Google delivers spam from senders who spend a lot on Google ads; and e-mail traffic gets laundered into web ads traffic; they just can't do it. And because Superhuman charges more than $0, it can't do it either. Nobody can fix e-mail. If you can't see how phishing and Google Ads are related... you know, this is why it is hard to "just" pass a law. It's not because the law wouldn't fix the problem. It would, if you permit the status quo where Google is the e-mail monopoly. It's this whole A16Z "just pass a law" nonsense, where someone thought he was saying something really insightful because he didn't like Jon Stewart, getting in the way of my inbox zero, and simply never receiving non-personal e-mails at all.

Great idea unless the attacker has SS7 access.

- from a number with no results on Kagi search

- claiming to be the online banking support of my bank

- asking me to read them a code sent to me via SMS

and when I refused to do that, they blocked my login credentials for online banking and sent me a sternly worded (paper) letter that my account could not be upgraded automatically for their software system migration because I had refused to engage with their support agent.

I then had to create a new login in their app, call the phone number on their letter and read that guy the SMS code and, to my surprise, that was the only !!! authentication needed to activate the new login credentials that I had just created.

(BTW, this was one of the top 100 largest banks worldwide)

It's almost like some companies are training you to fall for scams.

EDIT: This specific instance was Deutsche, but Chase has the exact same horrible habit of calling and then asking for an OTP code.

> - never give out codes sent to use via sms or push notifications to someone requesting them via phone or email. Never. The messages often even say that.

Chase bank still, as of last week, asks for these codes over inbound calls. Drives me mad. They do so when calling me about fraud alerts, not the other way around.

To their credit/discredit, when I said no I'm not giving that out it says not to they just moved on. Not sure why they even asked then.

Yeah, insane. I think it was HSBC. This was a couple of decades ago so maybe they've fixed that. I don't bank with them any more.

Unfortunately, some call centers DO use that for verification in some cases (i.e. you call them, and they send you a code to your email/phone that you read back).

It's like they want us to get scammed?

When you answer a call your brain kinda loses its ability to step back and think. Almost like the same trick that those people who ask for directions and steal your watch do.

Security is not the main reason I do this but it has been nice knowing I can't be reached directly by scammers and hackers.

Google Support would call me all the time, and then first thing they would do is ask me to open the interface and repeat some code or another.

Or even better, don't rely on a third-party hosted service.

I've been a Codebook[1] user since the old-days when they used to call it Strip.

They are old-school, local-system storage. With sync/backup done how you like it (all three encrypted before it leaves your computer):

    - Dropbox
    - Google Drive
    - Local folder (which you can then sync with using your own mechanism)
    - Recently (only this year) they introduced a totally optional hosted subscription cloud-sync option for those who want it

Capital One texts codes during live calls and requests the customer read the code to them.

A health care provider sends emails with links to 3rd party domain to provide encrypted email, because a) regular email isn’t supposedly not HIPAA compliant and b) apparently the health care provider’s web and app infrastructure which provides secure messaging is not secure enough for certain messages. It’s indistinguishable from a phishing attack.

Hospital direct invoicing by email, also includes 3rd party links, which takes the user to a site asking for personal information including SSN. It’s certainly phishing. Right? Nope, it’s legit, and no option to get a mailed bill once volunteering an email address.

I think half of mobile device users don’t know or can’t handle a best practices workflow.

The reality is the tech industry sucks, it’s bad at its job, gives shitty advice to everyone then goes and violates all of it leading to loss of trust.

I tried making this point downthread but it bears repeating higher up. Per OP, this was account with Authenticator enabled. If you have a working authenticator setup, they aren't going to "ask for a code", since by definition you're already authenticated. And while I'm no expert, I really don't think there is such a thing. Recovery for a lost account never goes back to device-in-hand once you have enabled full 2FA.

Something is being skipped in the description of the phish here. I don't think OP is being completely honest.

I have no idea how they had my password, I never share passwords or use the same password. But I hadn’t changed my Google password in a while.

I was pretty suspicious but thought I would get them to authenticate their identity as someone really from Amazon by telling me the last thing I had really ordered was...

I must have stayed on the call for 20 minutes, eventually they ended up swearing at me - all the time I could hear other people in the same room trying the same lines on different people. I have no idea why I stayed on for so long....

They have the scammers working off phone queues, it takes a little bit of time to get the call to the scammer, who has to start off with a script, so there's a delay.

Remember, the scammer, also likely not a native english speaker, also probably bored out of their mind, has to spin up, they have to read the name, understand how to say it and then say it out loud. Their is a mental startup time that a normal conversation doesn't have.

If someone calls you and isn't ready to immediately respond to "hello" it's a scammer.

Friend’s mother got scammed. She’d contacted tech support and they said they’d call back. Then a scammer just happened to call her within that next hour…

The answer is almost certainly greater than 0.

Getting a procative call for my benefit would make me very suspicious about the authenticity of that call!

Never, ever, use a cloud password manager, that's just dumb. Combining these things together in some sort of master account -- be it Google, Apple, Microsoft -- is also terrible. It's like leaving all of your savings accounts, checking, and investments at a single bank.

All of this stuff is going to get way worse because of AI. You'll be talking to real people you know personally who are 100% not AI but were tricked in to asking you to do something by other AI enabled scammers. However aggressive I've suggested people be in the past probably isn't going to be enough for 5 years from now.

These things have always been possible, and have been done, but now they can be done at scale, with advanced testing to figure out what works on who, whereas before it was targeting the guy who kept posting pictures of expensive watches on his public Instagram.

Sure, but this is Hacker News, not Mugger News.

For example, even a 2-of-2 setup with a trusted authority like a bank is straight-forward improvement in security over the conventional bank system.

You can go further, for example consider a 3-of-5 setup with 2 keys in security deposit boxes, 1 key on a laptop, 1 key on a phone, and 1 key on a hardware token. You can set the hardware token to erase its keys when the wrong pin is entered, making it pretty rubber hose proof.

It's a tiny, infinitesimal chance: but it's a heck of a lot greater of a chance than the same thing happening with a bank account, especially the "no recourse" part.

Unrelated, but for added spice, here's a thread from ten months where everyone agrees you're a fool unless you secure your coinbase account with google authenticator

https://www.reddit.com/r/CoinBase/comments/1h65zuh/account_h...

Doesn't seem like there's a lot of middle ground between being responsible for your mistakes and being treated like you can't be trusted to make your own decisions.

If your goal is to stay safe even after one of your devices is owned then you’ve got a rarer (and way more difficult) threat model.

Since you’re getting harassed all the time and dealing with opaque rules it is no wonder people are fatigued, make mistakes, are inclined to panic when they get a scary call and hand over the keys, etc.

To add to that, having anything to do with crypto is to put a big target on your back and make yourself vulnerable.

I've seen references to "three factor" auth which is often a push notification to a phone, and then there's more secure second factors, like yubikeys or code-protected passkeys.

Sadly for the scammers, that number didn't match. But, I note it was part of his script to sound confident and give a working URL. Pretty strong.

    ~ dig _dmarc.google.com txt +short
  "v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"

https://easydmarc.com/blog/google-spoofed-via-dkim-replay-at...

Yeah, I would be curious to see the actual email headers of what was received.

As an aside, fun fact, this would not be possible with @apple.com because Apple employees have old-school S/MIME signatures as an additional security layer.

https://undercodetesting.com/how-email-spoofing-exploits-spf...

This person read an SMS code — one that explicitly says not to give it to anyone — and then they said "I work in tech. I design authentication experiences. I know you’re not supposed to share verification codes! And yet, I got phished."

This person's greatest mistake was answering the phone to a stranger. Who knows what hell can be unleashed on one's emotions nowadays with AI. One cannot expect to be rational in a lion's den.

They are royally fucking up their PSA by throwing Google under the bus rather than telling people to avoid answering their phone to scammers. I suspect this PSA will help approximately no one because of that. Not getting your voice captured (for AI synthesis) is, by itself, a great reason not to answer random calls like this.

Why do banks have to "know their customers" and telephone providers don't?

You can use Google Cloud or Google Sites to trigger emails to anyone that legit come for Google email addresses and servers or submit forms on Google that will send legit emails to Gmail users/targets.

They simply either just embed their scam text into these emails or use the emails from legal@ as a scare tactic and pretext for their scam when they call you.

A warning to auth engineers: if an account is using a Gmail address, then auth codes from Google Authenticator should not be considered a second factor.

On the plus side, iOS and Android now have features for auto-answering and filtering so thankfully I have that.

Google Authenticator can be local-only or synced to the cloud.

In local-only mode, the authenticator is bound to a specific device. You can manually sync it to additional devices, but if you lose access to all those devices, it's game over, you will get locked out of whatever accounts you secured with authenticator as the second factor.

In cloud-synced mode, it's synced to your google account, so if you lose your phone, you can restore authenticator state. But if your google account gets taken over, it's game over, the attacker has your authentication codes.

You can buy that information. Databrokers will sell it. Your bank sells your transactions.

Coinbase has many ways to secure your account if the user enables them

also physical Yubi Keys would prevent anyone from withdrawing or steals funds as it would have to be plugged in and tapped to process them.

Don't disable cloud sync unless you have a backup of all your TPTP secret keys. It's dangerous to advise people to disable cloud sync without mentioning backups. Being locked out of thousands of dollars in your crypto account is as damaging as losing that crypto to hackers.

You can literally tie a yubi key to your Coinbase account and no one can withdraw funds unless a yubi key is physically plugged in and pressed.

One can also use the Coinbase Vault system where it would be impossible to steal any funds from his account had he enabled it.

You should also never use cloud sync for Google Authenticator as evidence here as why.

The security bottleneck is the one institution that holds all of the responsibility. It cannot be fixed by giving more hoops to authenticate themselves to the one institution

One of the best features of Apple iOS 26 is the new call-screening feature[1].

[1] https://support.apple.com/en-gb/guide/iphone/iphe4b3f7823/io...

What clued me in was that he said he couldnt share the estate documents with me until I gave him my popup 2FA code.

We trolled each other in class with it a bit. But at one point some student not in our class sent out a mass email, which was against the rules. I replied with a From line as "Administrator" and a bunch of whitespace, telling the girl that she broke the rule and would be suspended for it. Our teacher made me apologize, and I was lucky that I didn't get into more trouble beyond that.

Basically, the from field on an email can be anything you want. It's like sending physical mail and using a fake letterhead with someone else's info, just type what you want. No verification.

That's sometimes a good feature. Like, a third party provider can send newsletters on behalf of company A. But can also be bad, when used for phishing.

However, the email doesn't just appear in your mailbox. It comes to your email provider by another server connecting to it and sending the email. Spf allows the owner of A.com to specify which IPs/servers are actually acting on their behalf. So if I get an email from something@A.com, I can lookup and verify that the sending server is one to trust. If not, the email client should reject or warn the user somehow.

I'm pretty surprised gmail didn't flag this at least. When I did it for a class in Uni, it always let me know that the FROM header didn't match the sender since that's a clear attack vector

Whether you fall for an elaborate phish, or if your Ponzi-token predictably loses value after your 'investment' was cashed out as an earlier adopter's profit, it's all the same to me.

Alternatively your hardware wallet bricks itself or three of your disks fail at once.

I don't care. You lost the money when you first exchanged it for worthless tokens.

Did they send the fake legal email and at same time trigger a recovery code to be sent?

Is this like the same thing in discord where they ask you for your email to join a server then ask you for a code sent to verify you own that email but really they submitted the email for password reset. The victim doesn't realize it's a real recovery code sent by Microsoft, etc instead in the moment thinking it is a "discord code". Once you submit the code in discord they have your account stolen in seconds.

Is this what the article is attempting to describe?

if the scammers had spoofed the email, they would already have that code, and if they hadn't spoofed that email... I mean it looks like a case ID, why would they need it?

Maybe the reading back the code was to get buy in, then there's a missing step here like they had him hit "allow" on a 2fa prompt. Or maybe the email was legit, since it references a "temporary code" and the case ID allowed access with that code?

Good chance my reading comprehension is shot and I'm missing something, I suppose, but I don't understand.

OP said the coin base account was drained within “minutes”. Server thief bait can take up to 24h to notify you when someone takes the bait.

> We'll put a tiny amount of cryptocurrency in a wallet, but probably still enough to attract the attention of automated scripts. We notify you when it's taken within 24 hours.

A Horrific threat.

EDIT: to be clear, the fix has arrived: had he used passkeys, this attack would have been impossible and every login would’ve been faster and easier. There are edge cases but this is literally the reason why U2F was created a decade ago.

And would you say that using something like authy with encryption using a totally unique password is safe?