2FA prevents harvesting of passwords - but it just means that they have to be actively (or programmatically) attacking
I suppose if they AlSO have protections against proxying (forbid more than X login/login attempts from a given IP) it might help - but certainly not against spearphishing. Honestly don’t see how you can protect against even moderate level spearphishing reasonably.
Some banks have a “word” or picture you select that they’ll show you durning login - never understood how this can’t just be proxied.
Certificate based authentication in theory allows both sides to Authenticate the Other.
> Honestly don’t see how you can protect against even moderate level spearphishing reasonably.
WebAuthn. The article author dismisses it as basically too inconvenient (they apparently keep their Security Key somewhere out of reach and they struggle to remember the complicated user interaction of... pressing a button)
But WebAuthn is completely effective against phishing.
The closest to plausible attacks are: The bad guys take over the target servers (no reason to phish you); The bad guys persuade you to physically send them your authentication device (truly not everybody can be helped...); The bad guys persuade you to install software under their control on a general purpose PC (this won't work on a Phone) and then you follow their bad instructions to "use" your authenticator with their software to get them in.
Mutually authenticated TLS is in principle viable, and I have used it in machine-to-machine systems, but the UX is atrocious and it has grave privacy problems.
I think the conundrum is that such a device uses either a simple UI (like pressing the button), which then is unable to convey to the user which transaction is to be signed off on (the desktop/laptop/phone might be compromised) or the device has its own display and multiple-choice input that'll be too expensive and cumbersome for all to carry around all the time, everywhere.
> Some banks have a “word” or picture you select that they’ll show you durning login - never understood how this can’t just be proxied.
It can, simple as that. Some make it moderately more difficult by showing you, say, 9 pictures and asking you to pick the one that's yours. But, again, dead easy to proxy.
Others also ask you to put in only some characters of your password, which is even more troubling because at best they hash them in various configurations when you change password, at worst - they keep it in plaintext.
With PAKE schemes such as OPAQUE, you verify the site as well, IIRC, and that can be used to derive a shared secret, I think.
It is my understanding that U2F and Webauthn can't be proxied either, but I forgot the specifics and would appeciate if someone could enlighten me.
Conceptually, you just have to generate a keypair using Diffie-Hellman, and sign a challenge after the session has been opened, so that the server can double-check you have the right key (it already has your public key).
In WebAuthn (and U2F but that's obsolete and you should just implement WebAuthn on a green field system) your credentials are inherently tied to an FQDN yes.
There are two tricks involved. Firstly, your web browser is co-opted to do this work. It knows this is news.ycombinator.com much better than you do. If this wasn't in fact news.ycombinator.com, but looked correct and behaved as expected, you likely would not notice, but the browser checks the name matches for every single individual HTTP transaction.
So if the site fakebank.example tries to do a WebAuthn validation for realbank.example it just plain doesn't work.
Next, for a Security Key or similar FIDO1 device, where you can enroll an unlimited number of sites on a single authenticator since they aren't actually stored on the authenticator - the keys used are encrypted with that FQDN. So if bad guys stole your real authentication database enties at Real Bank (maybe from a backup) they not only can't use them, they can't even play them back to you and have you use them - they only work at all on the real site they were for, they're just random garbage on any other site.
This relies on a two encryption technologies. 1. Public Key Signatures (mostly using elliptic curves but that isn't essential). I can pick two related numbers, tell you one, and then in future you can challenge me to prove I know the other one on different occasions, and you'll know I do even though you don't learn the number. Your Security Key can prove to GitHub that it is still the same Security Key that visited before, despite GitHub not knowing which one that is.
2. AEAD Authenticated Encryption. Modern symmetric encryption not only keeps your data confidential, it can also simultaneously authenticate it, your Security Key knows when given back an encrypted "ID" that it's a real one it issued to this web site, because random IDs will fail the authentication step.
Either of these tricks would arguably achieve our basic security goals, but they are both adding further strengths to the system, so why not have both.
I suppose if they AlSO have protections against proxying (forbid more than X login/login attempts from a given IP) it might help - but certainly not against spearphishing. Honestly don’t see how you can protect against even moderate level spearphishing reasonably.
Some banks have a “word” or picture you select that they’ll show you durning login - never understood how this can’t just be proxied.
Certificate based authentication in theory allows both sides to Authenticate the Other.