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

51–56 of 56 posts

Re: Making unphishable 2FA phishable

#51

Post by remram »

cryptonector wrote: post #49
remram wrote: post #43

Earlier quoted context omitted.

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?

This submission's title mentions "2FA". The first post in this thread is about OAuth. Nothing in here is about anything but the "enrollment".

Re: Making unphishable 2FA phishable

#52

Post by mjg59 »

stavros wrote: post #42
infotogivenm wrote: post #40

Earlier quoted context omitted.

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.

Twitter would need to approve the evil.com app.

Re: Making unphishable 2FA phishable

#53

Post by chupasaurus »

minitoar wrote: post #35
chupasaurus wrote: post #27

Earlier quoted context omitted.

AllowTcpForwarding no ftl

eh if you have shell access anyway this is easy to circumvent.

"If" is a good word. The setting above is usually being used in environments where network security is a bit paranoid, so shell access won't help against lack of a hole through the firewall somewhere in-between, unless there's a way to use avian carriers.

Re: Making unphishable 2FA phishable

#55

Post by minitoar »

chupasaurus wrote: post #53
minitoar wrote: post #35

Earlier quoted context omitted.

eh if you have shell access anyway this is easy to circumvent.

"If" is a good word. The setting above is usually being used in environments where network security is a bit paranoid, so shell access won't help against lack of a hole through the firewall somewhere in-between, unless there's a way to use avian carriers.

The thread we are in is talking specifically about using cli tools on a remote machine, so that’s why I mentioned it. If you have that you don’t need a hole in the firewall.

Re: Making unphishable 2FA phishable

#56

Post by Thorrez »

dinosaurdynasty wrote: post #39
Thorrez wrote: post #23

Earlier quoted context omitted.

Copy and paste means a user can be phished. The user can copy and paste it to an attacker.

The token could be made only usable by the cli process that asked for it (should be really).

Yes, but that doesn't stop this attack.

1. Attacker runs the cli process to generate the URL

2. Attacker sends the URL to the victim saying "as a second factor verification, you need to copy this code into this form"

3. Victim does it

4. Attacker enters the code into the original cli process

Post reply on HN