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

When MFA isn't MFA, or how we got phished

retool.com

Post reply on HN
Print view View original

271–280 of 287 posts

Re: When MFA isn't MFA, or how we got phished

#271

Post by xtracto »

SoftTalker wrote: post #202
nanidin wrote: post #180

Earlier quoted context omitted.

Credit card fraud departments are generally good about this.

I can't remember which company it was, but I got a call a few years ago about some issue with an account, and they wanted some information to "verify my identity" I said wait a minute, you called me. Shouldn't I be verifying who you are? The guy kind of laughed and said yeah, but this is the process I've been given to follow. I said I would call back on public customer service number and he said that would be fine. I…

This happened to me with AT&T herein Mexico: I have an AT&T pre-paid sim card that expires after a year. At the end of the year I got a call supposedly from someone form AT&T and told me about some special discount offer if I pre-paid for another year. The catch is that I needed to pay over there by phone ... (give my card details).

I told her that I preferred to call the AT&T number and for her to tell me what options should I press to get to her. She couldn't give me an answer to that.

Most likely a scam I guess.

Re: When MFA isn't MFA, or how we got phished

#272

Post by skeaker »

xorcist wrote: post #236
skeaker wrote: post #138

Earlier quoted context omitted.

I am (genuinely, really asking) curious why you think so. I've got no hand in this, but the skepticism around phishing attacks from this site of all places really surprises me. People like Kevin Mitnick have done more sophisticated phishing with fewer tools. Why wouldn't someone intent on running a social engineering scam use one of the widely available voice faking technologies that are available now? Keep in mind t…

Making a meme is nothing like an interactive telephone conversation. It's not that it's impossible, but it's not trivial either. But mainly, it's just unnecessary. If the user is not fooled by a well crafted phishing, by doing the most trivial countermeasures such as calling back, they are not going to be fooled by a deepfake. In practice work on phishing is mostly better spent elsewhere. So while we shouldn't dismis…

I suppose the disconnect then would be that we fundamentally disagree on what the simpler answer is. It's my understanding that a deepfake voice being used as part of a phishing scam is something that can be done trivially (or at least by a determined actor using free tools, so at least trivial enough for this case), so to me that would be the simplest, most obvious answer when compared to a company-wide conspiracy, but I can see your point if it is assumed that that isn't the case and that deepfake voices are actually hard to do.

Re: When MFA isn't MFA, or how we got phished

#273

Post by akerl_ »

unethical_ban wrote: post #270
tptacek wrote: post #177

We use OTPs extensively at Retool: it’s how we authenticate into Google and Okta, how we authenticate into our internal VPN, and how we authenticate into our own internal instances of Retool They should stop using OTPs. OTPs are obsolete. For the past decade, the industry has been migrating from OTPs to phishing-proof authenticators: U2F, then WebAuthn, and now Passkeys†. The entire motivation for these new 2FA schem…

Are there self-hosted versions of something akin to what okta does? Push notifications with a validation step that the actual user initiated the authn request? Knowing how dead simple TOTP is technically, it's blown my mind that more companies don't host their own totp authn server.

Most places don't host TOTP auth servers because generally you want to bundle up the whole authn/authz package. Since you need your MFA flow to be connected to your primary auth flow, having one provider for one and then self-hosting the other is generally not smooth or easy.

Push notifications are also, in my experience, a massive pain (both in terms of the user flow where you have to pull out your phone, and in terms of running infra that's wired up to send pushes to whatever device types your users have). Notably, now you need a plan for users that picked a weird smartphone (or don't have a smartphone).

The better option is to go for passwordless auth, which you could self-host with something like Authentik or Keycloak, and then it handles the full auth flow.

Re: When MFA isn't MFA, or how we got phished

#274

Post by u801e »

acdha wrote: post #268
u801e wrote: post #265

Earlier quoted context omitted.

But they're not application level protocol agnostic. Based on my understanding, they require use of HTTP. If I want to get MFA using an email client communicating via SMTP and IMAP, then the email client needs to be able to interact with the HTTP API.

You can use FIDO tokens for other protocols: I use it for SSH, for example since OpenSSH 8.2 or so.

That requires the client to implement FIDO support. This was added to openssh 8.2p1. For example, mutt doesn't have FIDO support and you have to use an external script for oauth2 support. Both require implementing support for interacting with a HTTP API (which is not application level protocol agnostic).

On the other hand, you can configure mutt to use a client side TLS certificate and SMTP servers (e.g., postfix) and IMAP servers (e.g. dovecot) both support client side TLS certificates without having to support sending HTTP requests or parsing HTTP responses.

Re: When MFA isn't MFA, or how we got phished

#275

Post by acdha »

u801e wrote: post #274
acdha wrote: post #268

Earlier quoted context omitted.

You can use FIDO tokens for other protocols: I use it for SSH, for example since OpenSSH 8.2 or so.

That requires the client to implement FIDO support. This was added to openssh 8.2p1. For example, mutt doesn't have FIDO support and you have to use an external script for oauth2 support. Both require implementing support for interacting with a HTTP API (which is not application level protocol agnostic). On the other hand, you can configure mutt to use a client side TLS certificate and SMTP servers (e.g., postfix) an…

It’s not HTTP - the design uses a much smaller binary protocol (hardware tokens are very constrained) called CTAP:

https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-cl...

OpenSSH uses that protocol to request encryption operations. Mutt could do that the same way but it’d need a server which supports the same crypto algorithm FIDO2 specifies. That’d be great but also somewhat pointless if you’re using Yubikeys which support x509 auth which IMAP and SMTP have supported for decades.

Re: When MFA isn't MFA, or how we got phished

#276

Post by gmerc »

rossjudson wrote: post #267
gmerc wrote: post #252

Earlier quoted context omitted.

Not surprised. A team at Google identified this as a vector to juice growth, submitted the metrics which now govern their PSC and didn’t add the necessary counter-metrics to measure negative effects. That’s normal because that’s how the game is played. All the way up the chain to the org leader, there is no incentive to not do this.

You live in a funny alternate reality. You should consider what it might be like to live in one where everyone else isn't dumber than you. I will tell you a truth: People who think they're smarter than everyone else are generally missing important context or information.

Please don’t project your inferiority complex onto me.

Re: When MFA isn't MFA, or how we got phished

#277

Post by drhuseynov »

e12e wrote: post #258
rawgabbit wrote: post #185

Earlier quoted context omitted.

Which FIDO2 service do you recommend? I get tired reading all these security articles. The more I read, the more I feel they are hiding something.

> Which FIDO2 service do you recommend? Generally what comes with your phone and one or two hw tokens for backup? Looks like token2.com is a reasonable choice if you just want NFC/USBc and FIDO2 (and not storage for ssh/gpg keys). But I have little experience with hw keys.

ssh and pgp keys are not based on the similar functionality.

the keys from Token2 support *-sk key storage

https://www.token2.com/site/page/using-token2-fido2-security...

But not PGP

Re: When MFA isn't MFA, or how we got phished

#278

Post by GoblinSlayer »

miki123211 wrote: post #53
softfalcon wrote: post #26

Earlier quoted context omitted.

>FIDO2 can also detect the domain making the request, and will not provide the correct code even it the page looks correct to a human. I could not agree more with this sentiment! We need more of this kind of automated checking going on for users. I'm tired of seeing "just check for typo's in the URL" or "make sure it's the real site!" advice given to the average user. People are not able to do this even when they kno…

The problem with Fido (and other such solutions, including smartphone-based passkeys) is that they make things extremely hard if you're poor / homeless / in an unsafe / violent family situation and therefore change devices often. It's mostly a non-issue for Silicon Valley tech employees working solely on their corporate laptops, and U2F is perfect for that use-case, but these concerns make MFA a non-starter for the w…

The claim was that fido protocol is better than totp protocol no matter where you store keys. Your claim is that hardware key storage is difficult, but it doesn't differentiate between protocols: if you lost a device with hardware totp keys, you're not in a better position than if you lost a device with hardware fido keys.

Re: When MFA isn't MFA, or how we got phished

#279

Post by GoblinSlayer »

Master_Odin wrote: post #122
adamckay wrote: post #48

Earlier quoted context omitted.

> I'm surprised Google encourages syncing the codes to the cloud... kind of defeats the purpose Probably so when you upgrade/lose your phone you don't otherwise lose your MFA tokens. Yes, you're meant to note down some recovery MFA codes when you first set it up, but how many "normal people" do that?

A number of sites I've signed up for recently have required TOTP to be setup, but did not provide back up codes at the same time. There's a lot of iffy implementations out there.

The totp recovery code is just a base32 encoded secret key, which is also present in qr encoded url.

Re: When MFA isn't MFA, or how we got phished

#280

Post by e12e »

drhuseynov wrote: post #277
e12e wrote: post #258

Earlier quoted context omitted.

> Which FIDO2 service do you recommend? Generally what comes with your phone and one or two hw tokens for backup? Looks like token2.com is a reasonable choice if you just want NFC/USBc and FIDO2 (and not storage for ssh/gpg keys). But I have little experience with hw keys.

ssh and pgp keys are not based on the similar functionality. the keys from Token2 support *-sk key storage https://www.token2.com/site/page/using-token2-fido2-security... But not PGP

Thank you for the reminder that ssh now has FIDO2 support!
Post reply on HN