9 ms·

I think FIDO is not meant to be backup at first place. It's more a derived key exists to authenticate certain device safely without being stolen to authenticate

I think FIDO is not meant to be backup at first place. It's more a derived key exists to authenticate certain device safely without being stolen to authenticate other you aren't expected. Make it easily backupable actually defeats its whole purpose if it is intended to be used this way. And for service that actually want it to be used as major key. I think they can just make the one authenticated able to authenticate another(and even decide whether this new device can auth yet another or not). (Like the way google use: popup on user phone, and ask if user would like to let the computer login.) I think the one we actually need is a common protocol to authenticate new fido device from existing one. Although you can do it currently, every website have different flow to do it. And there is not currently a common way here. A common and machine understandable way to auth new device from existing one may ease the pain.

lxgr 4y ago
At least the WebAuthN standard seems to be moving in a different direction [1], which is also surprising to me. In a nutshell, it will be possible for relying parties (i.e. websites) to detect multi-device/backup capable authenticators if required, but disabling multi-device functionality would require a very explicit opt-out, not an opt-in, on the relying party's side. [1] https://github.com/w3c/webauthn/issues/1714 https://github.com/w3c/webauthn/issues/1714
- mmis1000 4y ago
  That seems to make fido just a non human readable/rememberable account/password. A somewhat downgrade from original hardware enforced implementation. But also make it more usable to majority of people, because keep something without losing it is just a pain to many people(where is my fxxking key goes again?). And it is still 1000x better than people using same password on every website.
  - lxgr 4y ago
    It's much more than a non-rememberable password: One of the most important attributes of WebAuthN/FIDO is that it's fundamentally impossible to fall victim to phishing. Assuming your browser isn't itself compromised, it is impossible to authenticate using a key for service.com on evil.com. Passwords can't do that. (PAKEs or other challenge/response protocols theoretically could, if implemented in the browser and not on websites, but that's a different story.)
    - mmis1000 4y ago
      However it will be weaker to malware compares to the original one. Because if you can export or sync the key, then malware probably also can if your device is compromised. The guarantee that key is never cloned unknowingly even machine fully compromised isn't in this new model.
      - lxgr 4y ago
        > The guarantee that key is never cloned unknowingly even machine fully compromised isn't in this new model. True, that was my concern with the new specification as well. But I believe the main problem will be account takeovers, not malware. > Because if you can export or sync the key, then malware probably also can if your device is compromised. Not necessarily. There are ways to still keep these keys only in secure hardware while allowing synchronization if the secure hardware supports service-provider mediated attestation. HSMs usually support a similar process, where keys can be copied to a different HSM by the same vendor, preserving all of their usage and authentication restrictions (i.e. only the same set of authenticated and authorized users are able to use them). This conceptually works by e.g. a new and old device, or a service-provider side HSM-secured backup and a new device, establishing a secured channel, attesting their state to each other and then copying the credentials over that secured channel. By necessity, this includes the service provider (or at least their HSM code) as a trusted party: They are the one that ultimately gets to decide which new devices get added to the synchronization set, and under what circumstances (running a recent hardware and software version, multifactor authentication, providing a high or low entropy shared secret). Of course, all of this also vastly increases the trusted computing base, and this might well not be appropriate for high security organizational environments.

lxgr 4y ago

At least the WebAuthN standard seems to be moving in a different direction [1], which is also surprising to me. In a nutshell, it will be possible for relying parties (i.e. websites) to detect multi-device/backup capable authenticators if required, but disabling multi-device functionality would require a very explicit opt-out, not an opt-in, on the relying party's side. [1] https://github.com/w3c/webauthn/issues/1714 https://github.com/w3c/webauthn/issues/1714

mmis1000 4y ago
That seems to make fido just a non human readable/rememberable account/password. A somewhat downgrade from original hardware enforced implementation. But also make it more usable to majority of people, because keep something without losing it is just a pain to many people(where is my fxxking key goes again?). And it is still 1000x better than people using same password on every website.
- lxgr 4y ago
  It's much more than a non-rememberable password: One of the most important attributes of WebAuthN/FIDO is that it's fundamentally impossible to fall victim to phishing. Assuming your browser isn't itself compromised, it is impossible to authenticate using a key for service.com on evil.com. Passwords can't do that. (PAKEs or other challenge/response protocols theoretically could, if implemented in the browser and not on websites, but that's a different story.)
  - mmis1000 4y ago
    However it will be weaker to malware compares to the original one. Because if you can export or sync the key, then malware probably also can if your device is compromised. The guarantee that key is never cloned unknowingly even machine fully compromised isn't in this new model.
    - lxgr 4y ago
      > The guarantee that key is never cloned unknowingly even machine fully compromised isn't in this new model. True, that was my concern with the new specification as well. But I believe the main problem will be account takeovers, not malware. > Because if you can export or sync the key, then malware probably also can if your device is compromised. Not necessarily. There are ways to still keep these keys only in secure hardware while allowing synchronization if the secure hardware supports service-provider mediated attestation. HSMs usually support a similar process, where keys can be copied to a different HSM by the same vendor, preserving all of their usage and authentication restrictions (i.e. only the same set of authenticated and authorized users are able to use them). This conceptually works by e.g. a new and old device, or a service-provider side HSM-secured backup and a new device, establishing a secured channel, attesting their state to each other and then copying the credentials over that secured channel. By necessity, this includes the service provider (or at least their HSM code) as a trusted party: They are the one that ultimately gets to decide which new devices get added to the synchronization set, and under what circumstances (running a recent hardware and software version, multifactor authentication, providing a high or low entropy shared secret). Of course, all of this also vastly increases the trusted computing base, and this might well not be appropriate for high security organizational environments.