18 ms·

What I Wish I Knew About U2F and Other Hardware MFA Protocols

120 points by dylanz 5y ago

travgary 5y ago
I think HSM's are just expensive because of price gouging rather than cost of the device? Like the Yubikey HSM is the same form factor as the Nano FIPS key but over 10x the price.
- hlieberman 5y ago
  Generally speaking, they're both: 1) higher performance, and 2) held to a much higher standard in terms of certifications they need. For example, a normal YubiKey is unrated, a YubiKey FIPS is level 2 rated, and a Thales HSM is level 3 rated with all sorts of zeroization hardware.
  - travgary 5y ago
    Interesting, maybe also the development costs too. They sell way less volume of HSMs compared to the standard keys but the HSM's require I'm sure some very rigorous development and testing.
    - foolmeonce 5y ago
      > HSM's require I'm sure some very rigorous development and testing. I think they mostly require an outside evaluator to do a sort of documentation process that costs somewhere around $500k depending on complexity on a new product, and maybe $50k just for up-versioning. It's generally hard to get that money back on a product since the market of organizations that need the certification is tiny and then the larger overall market for a security product is also usually small and not so happy to defray those costs.
    - Spooky23 5y ago
      I evaluated and purchased a few Thales HSMs. At the time the difference between the FIPS and standard/dev editions was a bunch of cash and the spaces within the device were filled with epoxy and would erase if tampered with. Software was the same, hardware looked the same. The crypto module is validated only with the $$ hardware. Sometimes the non FIPS devices will have other algorithms not on the FIPS list.
      - 1cvmask 5y ago
        Did you ever consider the Yubikey HSM at all as it’s much cheaper?
        Spooky23 5y ago
        No, as at time they did not offer a FIPS device, which was a requirement. Another nice feature of the Thales is that you could use multiple smart cards to ensure that no one person can do certain things.
- cronos 5y ago
  Mostly yes. It's a niche product with low demand and relatively high R&D costs, so margins have to offset that. There's probably also a bit of psychological biases at play, like: "if your HSM is 10x cheaper than everyone else's, it must be crappy and insecure".
TacticalCoder 5y ago
From TFA: > Since the U2F device creates and stores asymmetric key pairs, and is able to sign arbitrary “challenges”, can I use it as a general-purpose hardware key store? You can however do it "the other way round" and use a private key to derive a U2F path. And that same private key can be used for many other applications (or none). For example you can use the Ledger Nano S (originally a cryptocurrencies hardware wallet), which has an HSM, with your "seed" (say a 256-bit secret, stored as 24 words you hide), to log in sites using U2F. Additionally as long as you've got your secret, you can reinitialize your Nano S (or another one) as a new U2F device and there's no need to reset your U2F credentials on the site as the newly initialized device shall work exactly as if it was the old one. Fun fact: the CTO of Ledger was part of the group working on the original FIDO specs.
- krrrh 5y ago
  Trezors work the same way and I have one that I set up as a backup factor (I still find Authy desktop/mobile the most convenient). It’s very nice to have a paper backup.
- bsder 5y ago
  > Additionally as long as you've got your secret, you can reinitialize your Nano S (or another one) as a new U2F device and there's no need to reset your U2F credentials on the site as the newly initialized device shall work exactly as if it was the old one. But isn't it the whole point that these devices never let you have the secret?
  - OJFord 5y ago
    The device GP is talking about is a cryptocurrency 'hardware wallet', so no. You may have thought (as I did at first) they meant a Yubikey; there is after all also a model called 'Nano', but not, I think, 'Nano S'.
  - PeterisP 5y ago
    The devices don't let you extract the secret, however, they generally can be set up with a secret that you know.
loloquwowndueo 5y ago
A tomu (https://tomu.im/tomu.html https://tomu.im/tomu.html) can be used as a U2F device. Since it’s hackable and the code for U2F is available maybe it can be adapted as the author was asking (do you know of a device...?)
- CameronNemo 5y ago
  https://www.crowdsupply.com/solokeys/somu https://www.crowdsupply.com/solokeys/somu
christiansakai 5y ago
For a noob like me, I am thinking to get a Yubikey. What will happen if I lose my Yubikey? Am I essentially out of luck assuming the admins can’t reset my password or associated yubikey device? How do I prevent such scenario from happening? Is there truly a fool proof way of hardware authentication?
- Tomte 5y ago
  Usually people buy a second Yubikey, enrol both and have the second one somewhere safe. Most services and web sites also give you emergency login codes to print out, though.
  - busterarm 5y ago
    This is the thing to do. But I would suggest SoloKeys instead. I use these to log into my Linux systems, in combination with a password. pam_u2f was pretty easy to setup.
  - exporectomy 5y ago
    For services where no admin can get your access back, like most websites, a 3rd factor should be a compulsory part of 2FA. There's a balance between keeping hackers out and keeping yourself out. The more factors you require, the more optional factors you should also require users to have, not just optional codes but "you must write these codes down, we'll check later to make sure you did" or something like that.
    - userbinator 5y ago
      not just optional codes but "you must write these codes down, we'll check later to make sure you did" or something like that. ...which people will still not do, or misplace/erase due to disuse, etc. Security and availability are always at odds with each other. The question that you should always have when choosing a level of security is "does the risk of denying everyone access --- including myself --- outweigh the risk of someone other than myself gaining access?"
scott00 5y ago
I thought PKCS#11 was exactly what the author wanted: an API for performing arbitrary sign and encrypt operations using a hardware protected key. What doesn't it do?
- cronos 5y ago
  PKCS#11 is a C API. It does not describe the wire format for talking to the actual hardware. To use PKCS#11 for a particular device, you need a module (shared library) to translate between the C API and the actual hardware. This module is usually vendor-specific. If I develop software with PKCS#11 support, I'm basically asking every user to find a PKCS#11 module from their device vendor and install it in the right place. With U2F at least the hardware wire format is standardized: https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-raw-message-formats-v1.2-ps-20170411.html https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fid...
  - wahern 5y ago
    The wire format is standardized: ISO 7816. Even U2F uses ISO 7816. This issue with existing smart card technology is not lack of standardization, it's too much standardization--too much flexibility and stacks that are too deep. Vendors ship their own PKCS#11 drivers as a convenience. But PKCS#11 isn't the only high-level API. The other is PC/SC, which is actually simpler than PKCS#11, though it often requires more local support from the OS. But not necessarily. You can write PC/SC shims that talk directly to hardware, or even to Vault servers if you want, w/o OS support. I have my own rapid driver framework that supports all of these. For example, I have a PKCS#11 and PC/SC client driver which can use the Apple T1 chip to authenticate to a Vault server for remote signing using Transit keys--the only engine that supports ad hoc remote key operations. This permits sharing GnuPG (via PC/SC) and OpenSSH (via PKCS#11) keys between users, without actually disclosing the keys, though Vault actually makes it difficult to do this securely as you need to write ACLs to prevent transit keys from being exportable. BTW, you don't need special drivers to use Yubikeys, either. They just provide them as a convenience because the FOSS ecosystem is confusing and... non-optimal. I'm hoping to release a macOS product soon and as part that may release some of my framework as FOSS.
  - 5y ago
thomashabets2 5y ago
> TPMs are soldered onto motherboards so they are not portable. Like U2F, they also don’t let you sign arbitrary data. Incorrect! You can use TPM chips to RSA sign arbitrary data, and use that to authenticate SSH: https://blog.habets.se/2013/11/How-TPM-protected-SSH-keys-work.html https://blog.habets.se/2013/11/How-TPM-protected-SSH-keys-wo... Even under Windows: https://blog.habets.se/2016/10/Windows-SSH-client-with-TPM.html https://blog.habets.se/2016/10/Windows-SSH-client-with-TPM.h... The secret is using TSS_HASH_OTHER as the hash algorithm, which tells the TPM "it's already hashed". Whether it actually is hashed, or just raw input, is up to you.
- Rafert 5y ago
  TPMs are also sold separately that which can be plugged in to motherboards, e.g. Gigabyte (https://www.gigabyte.com/us/Motherboard/GC-TPM20-SPI-20 https://www.gigabyte.com/us/Motherboard/GC-TPM20-SPI-20) and Asus (https://www.asus.com/Motherboards-Components/Motherboards/Accessories/TPM-M-R2-0/ https://www.asus.com/Motherboards-Components/Motherboards/Ac...) to name a couple. The article has a couple of other weird faults, too: 1. I'm not sure why the author is complaining about FIDO2 having backwards compatibility with U2F/CTAP1. The article even incorrectly claims FIDO2 is "a 3rd incompatible standard" only to counter-argue the point a few paragraphs below explaining CTAP? People not having to throw away their perfectly fine old devices is a good thing in my book. 2. "All FIDO standards are web-centric and aren’t designed with any other client software in mind" the first part is true, the second part not so much. For example FIDO2 supports silent authentication (no user interaction) while WebAuthn explicitly does not[0]. It also supports the hmac-secret extension[1] which is used for offline authentication with Azure Active Directory[2] and IIRC no WebAuthn browser implementation exposes this extension to web apps. [0]: see e.g. discussion on https://github.com/w3c/webauthn/issues/199 https://github.com/w3c/webauthn/issues/199 [1]: https://fidoalliance.org/specs/fido-v2.1-rd-20210309/#sctn-hmac-secret-extension https://fidoalliance.org/specs/fido-v2.1-rd-20210309/#sctn-h... [2]: https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-authentication-passwordless#fido2-security-keys https://docs.microsoft.com/en-us/azure/active-directory/auth...
- lstamour 5y ago
  Also on a modern Apple device, you can use the Secure Enclave AES Engine to perform encryption and decryption. You can also use the Public Key Accelerator (PKA) for RSA and ECC (Elliptic Curve Cryptography) signing and encryption algorithms with hardware keys that stay within the PKA. https://support.apple.com/en-ca/guide/security/sec59b0b31ff/web https://support.apple.com/en-ca/guide/security/sec59b0b31ff/... covers an overview of the technologies involved. Of particular interest is probably the "Secure Enclave feature summary" at the bottom of that page which lists which Apple chips support which features. Also relevant: https://developer.apple.com/documentation/security/certificate_key_and_trust_services/keys/storing_keys_in_the_secure_enclave https://developer.apple.com/documentation/security/certifica... and CryptoKit https://developer.apple.com/news/?id=3bwfq45y https://developer.apple.com/news/?id=3bwfq45y and https://developer.apple.com/documentation/cryptokit https://developer.apple.com/documentation/cryptokit (Note that the Linux version of CryptoKit doesn't get any of the fancy hardware features, you'll need an Apple OS for them.)
shaicoleman 5y ago
Does anybody know if there is a U2F software solution that works with mobile phones? Ideally with the following features: * Stores keys securely in the Hardware-backed Keystore * Authentication via fingerprint + periodically via password * Allows to backup the secret key during setup * Supports multiple devices * Open source * Works over Wifi * Works with Linux desktops and Android phones
- francislavoie 5y ago
  There's https://krypt.co/ https://krypt.co/
  - shaicoleman 5y ago
    That's almost what I was looking for. I wonder how long before Akamai kills it. Main downside is that it doesn't support multiple devices
    - 1cvmask 5y ago
      I thought it was already discontinued a while ago
- jrockway 5y ago
  U2F is the predecessor to the current standard, WebAuthn. If a web app supports WebAuthn, then that integrates with native keystores (Windows Hello, Face ID, whatever Android has), as well as hardware keys. The site operator has some flexibility to prefer certain methods (platform vs. external) and devices (attestation). I wrote an authenticating proxy that uses Webauthn: https://github.com/jrockway/jsso2 https://github.com/jrockway/jsso2. I don't think you should use it, but you can fire it up locally and try enrolling the various devices. Actually, you can just use Duo's demo: https://webauthn.io/ https://webauthn.io/
  - shaicoleman 5y ago
    Unfortuately WebAuthn with the native keystores requires Bluetooth, which is a constant source of pain. That's a deal-breaker for me.
jrockway 5y ago
The article complains about the spec and "design by committee" but I think the WebAuthn standard is great. I read through it and it gave me all the information I needed to create a secure implementation that works with all browsers and devices. From zero, I can now FaceID into my personal Grafana instance, which is great. Zero complaints at all, and there are plenty of libraries floating around for people that don't want to read the spec and just want passwordless cross-device logins for their web app.
Arainach 5y ago
> Generally, FIDO standards push too much logic into hardware, when it could be handled in software instead. This is a feature, not a bug. It's one of the core points: Everything is in hardware, so software can't attack it. In theory, a bug in Android/iOS could expose my authenticator app secrets, but even a full root compromise of the host operating system can't extract the secrets or trigger a signing from a U2F key without me physically touching it.
tialaramex 5y ago
> Unfortunately, we don’t have the freedom to expand other standard protocols the same way. There's nothing standing in your way. However, SSH has the advantage that it's commonly used interactively, so FIDO is a good fit. Any protocol that is most often used silently with the user maybe not attentive or not even present won't work well - it's easy for your phone's mail client to just present the same password it remembers each time it re-connects, but it would be annoying if you need to touch the fingerprint reader each time. I can imagine (if anybody wanted to) retro-fitting SMTP submission to do FIDO, although I don't know if there's a practical way to hack it into the existing SASL AUTH layer.
taeric 5y ago
My biggest gripe with a security key right now is that there is no clear way to build the habit of using it. Basically every site will offer to "never ask from this device again" and then I have a key that I haven't used in a long time. Which, yes, I can use nothing but incognito windows, but that is too extreme and a single time I forget breaks it. Why can't I set it so that I need to use the key once a week?
- deleted 5y ago
  [deleted]

120 points by dylanz 5y ago

I think HSM's are just expensive because of price gouging rather than cost of the device? Like the Yubikey HSM is the same form factor as the Nano FIPS key but over 10x the price.

hlieberman 5y ago
Generally speaking, they're both: 1) higher performance, and 2) held to a much higher standard in terms of certifications they need. For example, a normal YubiKey is unrated, a YubiKey FIPS is level 2 rated, and a Thales HSM is level 3 rated with all sorts of zeroization hardware.
- travgary 5y ago
  Interesting, maybe also the development costs too. They sell way less volume of HSMs compared to the standard keys but the HSM's require I'm sure some very rigorous development and testing.
  - foolmeonce 5y ago
    > HSM's require I'm sure some very rigorous development and testing. I think they mostly require an outside evaluator to do a sort of documentation process that costs somewhere around $500k depending on complexity on a new product, and maybe $50k just for up-versioning. It's generally hard to get that money back on a product since the market of organizations that need the certification is tiny and then the larger overall market for a security product is also usually small and not so happy to defray those costs.
  - Spooky23 5y ago
    I evaluated and purchased a few Thales HSMs. At the time the difference between the FIPS and standard/dev editions was a bunch of cash and the spaces within the device were filled with epoxy and would erase if tampered with. Software was the same, hardware looked the same. The crypto module is validated only with the $$ hardware. Sometimes the non FIPS devices will have other algorithms not on the FIPS list.
    - 1cvmask 5y ago
      Did you ever consider the Yubikey HSM at all as it’s much cheaper?
      - Spooky23 5y ago
        No, as at time they did not offer a FIPS device, which was a requirement. Another nice feature of the Thales is that you could use multiple smart cards to ensure that no one person can do certain things.
cronos 5y ago
Mostly yes. It's a niche product with low demand and relatively high R&D costs, so margins have to offset that. There's probably also a bit of psychological biases at play, like: "if your HSM is 10x cheaper than everyone else's, it must be crappy and insecure".

TacticalCoder 5y ago

From TFA: > Since the U2F device creates and stores asymmetric key pairs, and is able to sign arbitrary “challenges”, can I use it as a general-purpose hardware key store? You can however do it "the other way round" and use a private key to derive a U2F path. And that same private key can be used for many other applications (or none). For example you can use the Ledger Nano S (originally a cryptocurrencies hardware wallet), which has an HSM, with your "seed" (say a 256-bit secret, stored as 24 words you hide), to log in sites using U2F. Additionally as long as you've got your secret, you can reinitialize your Nano S (or another one) as a new U2F device and there's no need to reset your U2F credentials on the site as the newly initialized device shall work exactly as if it was the old one. Fun fact: the CTO of Ledger was part of the group working on the original FIDO specs.

krrrh 5y ago
Trezors work the same way and I have one that I set up as a backup factor (I still find Authy desktop/mobile the most convenient). It’s very nice to have a paper backup.
bsder 5y ago
> Additionally as long as you've got your secret, you can reinitialize your Nano S (or another one) as a new U2F device and there's no need to reset your U2F credentials on the site as the newly initialized device shall work exactly as if it was the old one. But isn't it the whole point that these devices never let you have the secret?
- OJFord 5y ago
  The device GP is talking about is a cryptocurrency 'hardware wallet', so no. You may have thought (as I did at first) they meant a Yubikey; there is after all also a model called 'Nano', but not, I think, 'Nano S'.
- PeterisP 5y ago
  The devices don't let you extract the secret, however, they generally can be set up with a secret that you know.

loloquwowndueo 5y ago

A tomu (https://tomu.im/tomu.html https://tomu.im/tomu.html) can be used as a U2F device. Since it’s hackable and the code for U2F is available maybe it can be adapted as the author was asking (do you know of a device...?)

CameronNemo 5y ago
https://www.crowdsupply.com/solokeys/somu https://www.crowdsupply.com/solokeys/somu

christiansakai 5y ago

For a noob like me, I am thinking to get a Yubikey. What will happen if I lose my Yubikey? Am I essentially out of luck assuming the admins can’t reset my password or associated yubikey device? How do I prevent such scenario from happening? Is there truly a fool proof way of hardware authentication?

Tomte 5y ago
Usually people buy a second Yubikey, enrol both and have the second one somewhere safe. Most services and web sites also give you emergency login codes to print out, though.
- busterarm 5y ago
  This is the thing to do. But I would suggest SoloKeys instead. I use these to log into my Linux systems, in combination with a password. pam_u2f was pretty easy to setup.
- exporectomy 5y ago
  For services where no admin can get your access back, like most websites, a 3rd factor should be a compulsory part of 2FA. There's a balance between keeping hackers out and keeping yourself out. The more factors you require, the more optional factors you should also require users to have, not just optional codes but "you must write these codes down, we'll check later to make sure you did" or something like that.
  - userbinator 5y ago
    not just optional codes but "you must write these codes down, we'll check later to make sure you did" or something like that. ...which people will still not do, or misplace/erase due to disuse, etc. Security and availability are always at odds with each other. The question that you should always have when choosing a level of security is "does the risk of denying everyone access --- including myself --- outweigh the risk of someone other than myself gaining access?"

scott00 5y ago

I thought PKCS#11 was exactly what the author wanted: an API for performing arbitrary sign and encrypt operations using a hardware protected key. What doesn't it do?

cronos 5y ago
PKCS#11 is a C API. It does not describe the wire format for talking to the actual hardware. To use PKCS#11 for a particular device, you need a module (shared library) to translate between the C API and the actual hardware. This module is usually vendor-specific. If I develop software with PKCS#11 support, I'm basically asking every user to find a PKCS#11 module from their device vendor and install it in the right place. With U2F at least the hardware wire format is standardized: https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-raw-message-formats-v1.2-ps-20170411.html https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fid...
- wahern 5y ago
  The wire format is standardized: ISO 7816. Even U2F uses ISO 7816. This issue with existing smart card technology is not lack of standardization, it's too much standardization--too much flexibility and stacks that are too deep. Vendors ship their own PKCS#11 drivers as a convenience. But PKCS#11 isn't the only high-level API. The other is PC/SC, which is actually simpler than PKCS#11, though it often requires more local support from the OS. But not necessarily. You can write PC/SC shims that talk directly to hardware, or even to Vault servers if you want, w/o OS support. I have my own rapid driver framework that supports all of these. For example, I have a PKCS#11 and PC/SC client driver which can use the Apple T1 chip to authenticate to a Vault server for remote signing using Transit keys--the only engine that supports ad hoc remote key operations. This permits sharing GnuPG (via PC/SC) and OpenSSH (via PKCS#11) keys between users, without actually disclosing the keys, though Vault actually makes it difficult to do this securely as you need to write ACLs to prevent transit keys from being exportable. BTW, you don't need special drivers to use Yubikeys, either. They just provide them as a convenience because the FOSS ecosystem is confusing and... non-optimal. I'm hoping to release a macOS product soon and as part that may release some of my framework as FOSS.
- 5y ago

thomashabets2 5y ago

> TPMs are soldered onto motherboards so they are not portable. Like U2F, they also don’t let you sign arbitrary data. Incorrect! You can use TPM chips to RSA sign arbitrary data, and use that to authenticate SSH: https://blog.habets.se/2013/11/How-TPM-protected-SSH-keys-work.html https://blog.habets.se/2013/11/How-TPM-protected-SSH-keys-wo... Even under Windows: https://blog.habets.se/2016/10/Windows-SSH-client-with-TPM.html https://blog.habets.se/2016/10/Windows-SSH-client-with-TPM.h... The secret is using TSS_HASH_OTHER as the hash algorithm, which tells the TPM "it's already hashed". Whether it actually is hashed, or just raw input, is up to you.

Rafert 5y ago
TPMs are also sold separately that which can be plugged in to motherboards, e.g. Gigabyte (https://www.gigabyte.com/us/Motherboard/GC-TPM20-SPI-20 https://www.gigabyte.com/us/Motherboard/GC-TPM20-SPI-20) and Asus (https://www.asus.com/Motherboards-Components/Motherboards/Accessories/TPM-M-R2-0/ https://www.asus.com/Motherboards-Components/Motherboards/Ac...) to name a couple. The article has a couple of other weird faults, too: 1. I'm not sure why the author is complaining about FIDO2 having backwards compatibility with U2F/CTAP1. The article even incorrectly claims FIDO2 is "a 3rd incompatible standard" only to counter-argue the point a few paragraphs below explaining CTAP? People not having to throw away their perfectly fine old devices is a good thing in my book. 2. "All FIDO standards are web-centric and aren’t designed with any other client software in mind" the first part is true, the second part not so much. For example FIDO2 supports silent authentication (no user interaction) while WebAuthn explicitly does not[0]. It also supports the hmac-secret extension[1] which is used for offline authentication with Azure Active Directory[2] and IIRC no WebAuthn browser implementation exposes this extension to web apps. [0]: see e.g. discussion on https://github.com/w3c/webauthn/issues/199 https://github.com/w3c/webauthn/issues/199 [1]: https://fidoalliance.org/specs/fido-v2.1-rd-20210309/#sctn-hmac-secret-extension https://fidoalliance.org/specs/fido-v2.1-rd-20210309/#sctn-h... [2]: https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-authentication-passwordless#fido2-security-keys https://docs.microsoft.com/en-us/azure/active-directory/auth...
lstamour 5y ago
Also on a modern Apple device, you can use the Secure Enclave AES Engine to perform encryption and decryption. You can also use the Public Key Accelerator (PKA) for RSA and ECC (Elliptic Curve Cryptography) signing and encryption algorithms with hardware keys that stay within the PKA. https://support.apple.com/en-ca/guide/security/sec59b0b31ff/web https://support.apple.com/en-ca/guide/security/sec59b0b31ff/... covers an overview of the technologies involved. Of particular interest is probably the "Secure Enclave feature summary" at the bottom of that page which lists which Apple chips support which features. Also relevant: https://developer.apple.com/documentation/security/certificate_key_and_trust_services/keys/storing_keys_in_the_secure_enclave https://developer.apple.com/documentation/security/certifica... and CryptoKit https://developer.apple.com/news/?id=3bwfq45y https://developer.apple.com/news/?id=3bwfq45y and https://developer.apple.com/documentation/cryptokit https://developer.apple.com/documentation/cryptokit (Note that the Linux version of CryptoKit doesn't get any of the fancy hardware features, you'll need an Apple OS for them.)

shaicoleman 5y ago

Does anybody know if there is a U2F software solution that works with mobile phones? Ideally with the following features: * Stores keys securely in the Hardware-backed Keystore * Authentication via fingerprint + periodically via password * Allows to backup the secret key during setup * Supports multiple devices * Open source * Works over Wifi * Works with Linux desktops and Android phones

francislavoie 5y ago
There's https://krypt.co/ https://krypt.co/
- shaicoleman 5y ago
  That's almost what I was looking for. I wonder how long before Akamai kills it. Main downside is that it doesn't support multiple devices
  - 1cvmask 5y ago
    I thought it was already discontinued a while ago
jrockway 5y ago
U2F is the predecessor to the current standard, WebAuthn. If a web app supports WebAuthn, then that integrates with native keystores (Windows Hello, Face ID, whatever Android has), as well as hardware keys. The site operator has some flexibility to prefer certain methods (platform vs. external) and devices (attestation). I wrote an authenticating proxy that uses Webauthn: https://github.com/jrockway/jsso2 https://github.com/jrockway/jsso2. I don't think you should use it, but you can fire it up locally and try enrolling the various devices. Actually, you can just use Duo's demo: https://webauthn.io/ https://webauthn.io/
- shaicoleman 5y ago
  Unfortuately WebAuthn with the native keystores requires Bluetooth, which is a constant source of pain. That's a deal-breaker for me.

jrockway 5y ago

The article complains about the spec and "design by committee" but I think the WebAuthn standard is great. I read through it and it gave me all the information I needed to create a secure implementation that works with all browsers and devices. From zero, I can now FaceID into my personal Grafana instance, which is great. Zero complaints at all, and there are plenty of libraries floating around for people that don't want to read the spec and just want passwordless cross-device logins for their web app.

Arainach 5y ago

> Generally, FIDO standards push too much logic into hardware, when it could be handled in software instead. This is a feature, not a bug. It's one of the core points: Everything is in hardware, so software can't attack it. In theory, a bug in Android/iOS could expose my authenticator app secrets, but even a full root compromise of the host operating system can't extract the secrets or trigger a signing from a U2F key without me physically touching it.

tialaramex 5y ago

> Unfortunately, we don’t have the freedom to expand other standard protocols the same way. There's nothing standing in your way. However, SSH has the advantage that it's commonly used interactively, so FIDO is a good fit. Any protocol that is most often used silently with the user maybe not attentive or not even present won't work well - it's easy for your phone's mail client to just present the same password it remembers each time it re-connects, but it would be annoying if you need to touch the fingerprint reader each time. I can imagine (if anybody wanted to) retro-fitting SMTP submission to do FIDO, although I don't know if there's a practical way to hack it into the existing SASL AUTH layer.

taeric 5y ago

My biggest gripe with a security key right now is that there is no clear way to build the habit of using it. Basically every site will offer to "never ask from this device again" and then I have a key that I haven't used in a long time. Which, yes, I can use nothing but incognito windows, but that is too extreme and a single time I forget breaks it. Why can't I set it so that I need to use the key once a week?

deleted 5y ago
[deleted]