Hmm, hold on. Don’t yubikeys protect against that kind of attack by clever use of domain-specific cookies? And couldn’t you do the same thing with push notifications and a phone app? I doubt anyone does. But I feel like it should work.
-
-
You can be sure the notification gets delivered to the right phone but you can't be sure that the user is looking at your page. That's what the domain-specific keys in U2F do.
1 reply 0 retweets 2 likes -
Replying to @reillyeon @taviso
But couldn’t you have domain specific keys in a push notification in exactly the same way as U2F? U2F over https, basically. I realize that most current push notifications essentially just do OTP over https, but it seems like it’s not *intrinsically* doomed.
1 reply 0 retweets 0 likes -
How would that work if you are sending the push to a different device, like a mobile phone.
1 reply 0 retweets 0 likes -
Replying to @reillyeon @taviso
Web browser visits phishing site. Site does redirect to auth provider site, which triggers push to phone, waits for answer, updates cookie. Then redirects back to wherever. Phishing site should never see the auth material this way, right? That’s why it’s better than OTP.
3 replies 0 retweets 0 likes -
1. User visits phishing site and enters creds, no redirect to real auth provider. 2. Phishing server starts auth request to real site using creds and gets redirect. 3. Real site sends push to phone. 4. User confirms they want to log in. 5. Phisher's session is now authenticated.
1 reply 0 retweets 5 likes -
Replying to @reillyeon @taviso
Ah, ok, I think now I see. The U2F device trusts the local browser only because of its physical connection, not through crypto. That's the only reason the local browser is allowed to request a signature from U2F. And the auth site trusts the U2F only because of prior enrollment.
1 reply 0 retweets 0 likes -
So browser+U2F together are trusted combination. We could instead choose to enroll a browser instance + software U2F, but a) then enrollment is the weak link, and b) we're prone to OS security, and c) phone push auth won't add anything. Thanks for helping me help myself :)
1 reply 0 retweets 0 likes -
...or maybe I'm still not there. IIUC, advantage of U2F is the physical trusted link between U2F and browser, so enrolling U2F key once lets it work on any PC. If we enroll each browser explicitly with a phone (QR code?), and phone with server, could that replace physical link?
2 replies 0 retweets 0 likes -
Replying to @apenwarr @reillyeon
It could be a software implementation. The primary advantages of having a hardware button are that malware can't just steal the key material and generate arbitrary tokens without interaction, and it simplifies management.
2 replies 0 retweets 1 like
Note that malware can hijack any real press for any domain it wants, so U2F doesn't solve malware, just phishing on uncompromised endpoints 
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.