6 ms·

> W3C and FIDO finalized the Level 1 WebAuthn specification back in March. Chrome and Firefox already have mature support for it, and Safari is expected to foll

> W3C and FIDO finalized the Level 1 WebAuthn specification back in March. Chrome and Firefox already have mature support for it, and Safari is expected to follow. > Upcoming Android releases will allow users to use their phone as a security key, and iOS is expected to do the same. This does not make me happy. Why does there need to be a web standard for this? I do not want Firefox to store my keys for me. Or any browser. I do not want transparent authentication, I want it to be explicit, and I want it to be offline. I have the same issue with hands free keyless entry/ignition for cars. The feature is solely for convenience, and exposes far too much. The way things work now is the best. When setting up 2FA, I write down my key, and import it into Google Authenticator, or oathtool for the command line. There is no integration, no automation. It works just fine. In the future I'm imagining my 2FA secrets being stolen from my browser, or being used to track me. Google "for my convenience" automatically logs me in so it can track me? Or perhaps, my bank checking my battery level, WiFi hot spots, and the model of phone when it pulls the 2FA tokens to verify my location. Also, I can only log on with their app on my phone, because the tokens are hidden, further making my desktop useless. Maybe a website figures out how to use JavaScript to generate another logins tokens. It takes an hour of tokens, and feeds it into hashcat on AWS to break my key. No thank you. The rest of it though is great. SMS 2FA can die.

woodruffw 7y ago
Hey! Author here. > Why does there need to be a web standard for this? I do not want Firefox to store my keys for me. Or any browser. I do not want transparent authentication, I want it to be explicit, and I want it to be offline. WebAuthn doesn't specify key storage in the browser. It specifies a common JavaScript API for registering and generating assertions via an authenticator, which in turn stores keys internally. Wanting offline 2FA is perfectly reasonable, and I don't begrudge you that! TOTP is perfectly fine for that purpose, so long as you understand the tradeoffs you make in terms of symmetricity/phishability/replays/etc.
- bjt2n3904 7y ago
  Thanks for the reply. Despite my gripe about this one aspect, your article was very complete and well written. I've bookmarked it to revisit when I need to implement 2FA in projects I'm working on. That being said, I do not like a JavaScript API that provides access to this. JavaScript, JS developers, and the web in general has a horrific track record for security and privacy. To me, this is like the API that provides access to the battery charge state, or my accelerometer for device orientation. Why? Entirely unnecessarily! But it's a cool feature, so let's include it. Suddenly, my keyboard typing is being exfilled through the browser, and I'm being tracked by my battery charge state. Do not want! EDIT: I've maintained this position for "WebBluetooth" too -- a similarly terrible idea. The less my browser does, the better!
skybrian 7y ago
Browser support is necessary for a website to communicate with a hardware key (such as Yubikey). Yubikeys aren't automatic; you press a button to authenticate. Maybe you don't like those, but they work well for many people. Even non-technical users are less likely to lose a key on their keychain than to lose or damage their phone. (I've lost Google Authenticator keys to phone hardware failure.) They can also be used by people who don't have a cell phone at all, or use it rarely. They're also resistant to phishing attacks since they authenticate the site, and users are not good at checking domain names.
pfg 7y ago
Most of these concerns are luckily not a problem in practice, I'll try to go through them one by one. > In the future I'm imagining my 2FA secrets being stolen from my browser, or being used to track me. The API does not provide access to secrets. Keys remain on the WebAuthn device, and the device only signs data and sends that back. The key is likely also stored in a way that makes extraction hard - for hardware tokens, past attacks of this nature mostly required physical access, and modern iPhones and some Android devices have high-quality key stores offering similar protection. AFAIK keys used by these devices differ for each origin/domain (IIRC through some crypto magic on hardware devices, as they don't have space for many keys), preventing cross-origin tracking. > Google "for my convenience" automatically logs me in so it can track me? Most (all?) implementations I'm aware of require approval on the token (physical tap, approval of a prompt). Browsers also tend to show a prompt/notification when sites use this feature. > Or perhaps, my bank checking my battery level, WiFi hot spots, and the model of phone when it pulls the 2FA tokens to verify my location. The API does not allow this level of access. > Also, I can only log on with their app on my phone, because the tokens are hidden, further making my desktop useless. There is nothing stopping you from using hardware tokens (which use the same standard) or even soft tokens running on your desktop. IIRC GitHub created a desktop implementation utilizing the Secure Enclave that modern Macs come with for this purpose. > Maybe a website figures out how to use JavaScript to generate another logins tokens. It takes an hour of tokens, and feeds it into hashcat on AWS to break my key. This does not make sense with the implementation in mind - the key is stored on a separate device and the browser only ever gets something that was signed using said key.

woodruffw 7y ago

Hey! Author here. > Why does there need to be a web standard for this? I do not want Firefox to store my keys for me. Or any browser. I do not want transparent authentication, I want it to be explicit, and I want it to be offline. WebAuthn doesn't specify key storage in the browser. It specifies a common JavaScript API for registering and generating assertions via an authenticator, which in turn stores keys internally. Wanting offline 2FA is perfectly reasonable, and I don't begrudge you that! TOTP is perfectly fine for that purpose, so long as you understand the tradeoffs you make in terms of symmetricity/phishability/replays/etc.

bjt2n3904 7y ago
Thanks for the reply. Despite my gripe about this one aspect, your article was very complete and well written. I've bookmarked it to revisit when I need to implement 2FA in projects I'm working on. That being said, I do not like a JavaScript API that provides access to this. JavaScript, JS developers, and the web in general has a horrific track record for security and privacy. To me, this is like the API that provides access to the battery charge state, or my accelerometer for device orientation. Why? Entirely unnecessarily! But it's a cool feature, so let's include it. Suddenly, my keyboard typing is being exfilled through the browser, and I'm being tracked by my battery charge state. Do not want! EDIT: I've maintained this position for "WebBluetooth" too -- a similarly terrible idea. The less my browser does, the better!

skybrian 7y ago

Browser support is necessary for a website to communicate with a hardware key (such as Yubikey). Yubikeys aren't automatic; you press a button to authenticate. Maybe you don't like those, but they work well for many people. Even non-technical users are less likely to lose a key on their keychain than to lose or damage their phone. (I've lost Google Authenticator keys to phone hardware failure.) They can also be used by people who don't have a cell phone at all, or use it rarely. They're also resistant to phishing attacks since they authenticate the site, and users are not good at checking domain names.

pfg 7y ago

Most of these concerns are luckily not a problem in practice, I'll try to go through them one by one. > In the future I'm imagining my 2FA secrets being stolen from my browser, or being used to track me. The API does not provide access to secrets. Keys remain on the WebAuthn device, and the device only signs data and sends that back. The key is likely also stored in a way that makes extraction hard - for hardware tokens, past attacks of this nature mostly required physical access, and modern iPhones and some Android devices have high-quality key stores offering similar protection. AFAIK keys used by these devices differ for each origin/domain (IIRC through some crypto magic on hardware devices, as they don't have space for many keys), preventing cross-origin tracking. > Google "for my convenience" automatically logs me in so it can track me? Most (all?) implementations I'm aware of require approval on the token (physical tap, approval of a prompt). Browsers also tend to show a prompt/notification when sites use this feature. > Or perhaps, my bank checking my battery level, WiFi hot spots, and the model of phone when it pulls the 2FA tokens to verify my location. The API does not allow this level of access. > Also, I can only log on with their app on my phone, because the tokens are hidden, further making my desktop useless. There is nothing stopping you from using hardware tokens (which use the same standard) or even soft tokens running on your desktop. IIRC GitHub created a desktop implementation utilizing the Secure Enclave that modern Macs come with for this purpose. > Maybe a website figures out how to use JavaScript to generate another logins tokens. It takes an hour of tokens, and feeds it into hashcat on AWS to break my key. This does not make sense with the implementation in mind - the key is stored on a separate device and the browser only ever gets something that was signed using said key.