Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

That’s a really good idea, we should be asking sites to verify themselves with a second factor. Do you know if that’s in use anywhere?


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.

[Edited to clarify some details]


This is called a site key and was made popular by Bank of America. I'm not sure if they still do it.

https://en.wikipedia.org/wiki/SiteKey




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: