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

Making unphishable 2FA phishable

mjg59.dreamwidth.org

Post reply on HN
Print view View original

41–50 of 56 posts

Re: Making unphishable 2FA phishable

#41

Post by remram »

mjg59 wrote: post #15
remram wrote: post #12

Earlier quoted context omitted.

> For devices, direct attestation could authenticate the device making the request (e.g. as a legitimate MacBook Pro, or something). The attacker may well be using a MacBook Pro, a real one. With a TPM.

I think the only MacBook Pros with real TPMs were the 1, and 2, series from 2006/2007. Right now Apple don't allow you to do device identity attestation with the secure element. But in the world where you take this approach you don't just tie issuance to "I have a hardware keystore", you tie it to "This hardware keystore has an identity that I know belongs to a computer I own"

But the entire thread is about delegating the authentication, granting access to another machine or process. You want to give access to one device (e.g. TV) from the trusted one (e.g. iPhone).

Both devices might be very pricey, real, up-to-date machines with TPM and keys and everything you want. The problem is that you can't tell whether the TV is the one TV that the iPhone's owner means to sign in.

Re: Making unphishable 2FA phishable

#42

Post by stavros »

infotogivenm wrote: post #40
stavros wrote: post #36

Earlier quoted context omitted.

Couldn't they do exactly the same thing with OAuth? I don't understand what the increased risk here is.

Normally iirc oauth will just transport the token in a browser redirect to the allowed domain that linked to the login page. evil.com will not be allowed, or if it is the token will end up scoped to evil.com.

If evil.com requests access to manage my Twitter account, and it fools me into accepting, why does it matter how the token is transported? Evil.com now has access to my Twitter account.

Re: Making unphishable 2FA phishable

#43

Post by remram »

cryptonector wrote: post #24
remram wrote: post #12

Earlier quoted context omitted.

> For devices, direct attestation could authenticate the device making the request (e.g. as a legitimate MacBook Pro, or something). The attacker may well be using a MacBook Pro, a real one. With a TPM.

Yes, but the idea is that you'd enroll the device (and its TPM), and thence wouldn't be phishable like this. Granted, there might still be a problem at device enrollment time.

See sibling thread, we're being duplicated; the point of this OAuth flow is to sign in on a different device, using the trusted one. That different device might be a legitimate TV with a TPM and cryptographic attestations that it truly belong to John Doe, there is still no way for your iPhone and Apple to check whether you meant to sign in to John Doe's TV or if they are a scammer and sent you the (legitimate) sign-up link over email.

Re: Making unphishable 2FA phishable

#44

Post by mooreds »

zacharyvoase wrote: post #10

It would be great if OAuth could include some form of cryptographic attestation—similar to what is already present in WebAuthn—to ensure that only trusted devices can get authorization tokens. In the case of CLI app authorization (where you are proving that the refresh + access tokens are being retrieved on the same device that issued the request), the CLI could generate a local key, store it in the TPM/keychain, and…

> It would be great if OAuth could include some form of cryptographic attestation

This is, as they say, a "known issue". Bearer tokens were defined in RFC 6750 and the thought was that more types of tokens would follow, including some that bound tokens and clients.

It took a while.

RFC 8705, mentioned elsewhere in thread, is one approach.

Another is DPoP, which was discussed at Identiverse in 2022. Here's a presentation about the approach: https://www.youtube.com/watch?v=cot40RRoPsc

Here's the current draft: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-... (not sure how close they are to finishing, haven't see much activity on the mailing list about it lately, though).

Re: Making unphishable 2FA phishable

#45

Post by _flux »

GreyStache wrote: post #21
jadedtuna wrote: post #5

Earlier quoted context omitted.

If SSH is already being used, can't one just create an SSH tunnel to forward the login?

Something akin to ssh agent-forwarding ("oauth-forwarding"?) is really needed. And it needs to be integrated similarly well like support for jumphosts. Haven't seen anything like this, I'll try to bring this up with the openssh folks.

Curl can connect over unix domain sockets and ssh can forward them, I feel this would be a decent way to forward authentication as access control rules would apply to the sockets.

Re: Making unphishable 2FA phishable

#46

Post by tomjen3 »

mdeeks wrote: post #4

The infuriating thing is that this isn't necessary for CLI tooling. The reason this approach is taken is that you need a way to get the token to a local process even if the user is doing authentication in a browser. This can be avoided by having the process listen on localhost, and then have the login flow redirect to localhost (including the token) on successful completion. Unfortunately this doesn’t work for CLI to…

Doesn't VSCode forward connections made in its terminal? I worked remote on some webstuff and I could use my local browser just fine.

Re: Making unphishable 2FA phishable

#47

Post by zacharyvoase »

hirsin wrote: post #25
zacharyvoase wrote: post #16

Earlier quoted context omitted.

WebAuthn uses such a directory already. Most implementations validate the attestation against a public database of ‘trusted’ device types (and DAA enables this to be done without compromising anonymity, up to the uniqueness of a device type)

That's not a trust statement, and it's not reliable as a proof. You can reliably tell you've seen this authenticator before, but that doesn't solve the problem being described here

Trust is a ladder, and identifying the make/model of device is but one rung of it.

Re: Making unphishable 2FA phishable

#48

Post by seanhunter »

dinosaurdynasty wrote: post #38
seanhunter wrote: post #20

Earlier quoted context omitted.

As long as noone compromised their clipboard using malware etc. Which is a vector that seems quite common in spearphishing at least anecdotally.

Wouldn't they already be pwned in that case?

Their machine would be pwned, but their 2nd factor would not be compromised if they used something like a yubikey, so the attacker couldn't use the compromised host to SSO to other systems and enlarge their compromise. That's why yubikey requires that you touch it - an attacker can't just remotely trigger it even if they totally own the host the yubikey is plugged into.

That's the point of TFA - unphishable second factors and ways to make them phishable. I'm saying that using the clipboard would be a bad idea in this case.

Re: Making unphishable 2FA phishable

#49

Post by cryptonector »

remram wrote: post #43
cryptonector wrote: post #24

Earlier quoted context omitted.

Yes, but the idea is that you'd enroll the device (and its TPM), and thence wouldn't be phishable like this. Granted, there might still be a problem at device enrollment time.

See sibling thread, we're being duplicated; the point of this OAuth flow is to sign in on a different device , using the trusted one. That different device might be a legitimate TV with a TPM and cryptographic attestations that it truly belong to John Doe, there is still no way for your iPhone and Apple to check whether you meant to sign in to John Doe's TV or if they are a scammer and sent you the (legitimate) sign-…

It's essentially an enrollment workflow using an existing enrolled device, yes?

Re: Making unphishable 2FA phishable

#50

Post by dinosaurdynasty »

seanhunter wrote: post #48
dinosaurdynasty wrote: post #38

Earlier quoted context omitted.

Wouldn't they already be pwned in that case?

Their machine would be pwned, but their 2nd factor would not be compromised if they used something like a yubikey, so the attacker couldn't use the compromised host to SSO to other systems and enlarge their compromise. That's why yubikey requires that you touch it - an attacker can't just remotely trigger it even if they totally own the host the yubikey is plugged into. That's the point of TFA - unphishable second fa…

If the machine is pwned, it seems like it wouldn't be super hard to get the user to touch the yubikey.
Post reply on HN