Making unphishable 2FA phishable
mjg59.dreamwidth.org
Making unphishable 2FA phishable
1–10 of 56 posts
Re: Making unphishable 2FA phishable
#2> "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."
I think this is what the AWS Client VPN client for Ubuntu does. So AWS does have the method in their tool set somewhere, though I imagine it's owned by an entirely different team than their CLI.
Re: Making unphishable 2FA phishable
#3This attack like OP says is not new. For a corporate environment you simply prevent all users except one or two admins/approvers from allowing 3rd party authorizations.
For consumers, my suggestion is for federation providers (auth0,github, google,etc...) review and human-approve applications that ask users authorizations.
Re: Making unphishable 2FA phishable
#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.
Re: Making unphishable 2FA phishable
#5The 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…
If SSH is already being used, can't one just create an SSH tunnel to forward the login?
Re: Making unphishable 2FA phishable
#6The 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…
If SSH is already being used, can't one just create an SSH tunnel to forward the login?
ssh -D ftw
Re: Making unphishable 2FA phishable
#7The 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…
If SSH is already being used, can't one just create an SSH tunnel to forward the login?
Some login requires Identity and access management (IAM) with a web interface only, if such gateway exists, a CLI tool would have to give user a link to open oneself I guess?
Re: Making unphishable 2FA phishable
#8The 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…
I wonder if having the user copy-paste the token could work?
Re: Making unphishable 2FA phishable
#9The 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…
If SSH is already being used, can't one just create an SSH tunnel to forward the login?
My SSH usage has multiple servers (staging, dev, etc..) and multiple clients (laptop, desktop). Some of those connections are going through jumphosts.
Setting up SSH tunnel would be possible, but a major pain, as every source/dest combination will need to have its own port, and every signin should specify the port number.
Compared to the current system, which prints a URL in terminal which I just need to click, it would be a major usability regression.
Re: Making unphishable 2FA phishable
#10It 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 then in the browser you could prove that you have access to that same key.
For devices, direct attestation could authenticate the device making the request (e.g. as a legitimate MacBook Pro, or something).
Of course, this depends on services choosing to implement such flows, and when you introduce a requirement for a TPM or similar, plus multiple cryptographic steps, implementors are likely to get lazy and just do something that works but is insecure (or they implement the flows badly with home-rolled crypto).