3 ms·

Yes they can be lost but that's why people use more than one. They already support that as they mention in the blog post. And what you describe "password and o

Yes they can be lost but that's why people use more than one. They already support that as they mention in the blog post. And what you describe "password and oneOf(token, phone, etc)" is not how passwordles works. It is really just "oneOf(token, phone, etc)". The token itself is what validates your PIN code in this scenario. Eventually they'll have to implement this anyway because it's the "end game" for the FIDO designers. And it's something the competition already offers: https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-authentication-passwordless-security-key https://docs.microsoft.com/en-us/azure/active-directory/auth...

eternityforest 4y ago
Tokens will have to get a bit cheaper, or software implementations will have to be more widely available and well known, and the storage will have to increase. I would not be happy if I suddenly had to by several of these tokens, carry them around, and potentially manually swap them out, since many current ones only hold 25 keys or so. I wonder if something simpler wouldn't be possible, that didn't involve storing keys on-chip, or storing them in encrypted form on the host. Couldn't the token just generate the key as needed, seeded by hash(domainName, accountName, salt, internalSecret)? It seems like YubiKey does something like this but some seem to actually store keys, or require some complex in browser or server side storage, adding points of failure. And there seems to be some "resident key" feature that always stores data on the authenticator? Is that really necessary?
- GekkePrutser 4y ago
  > I would not be happy if I suddenly had to by several of these tokens, carry them around, and potentially manually swap them out, since many current ones only hold 25 keys or so. This is not how FIDO2 works. It uses the same key but it generates a different derivative for every site. There is no limit on how many sites you can use it on. And the derivative is different for each site, so you can't hijack an authentication session and use it for another site. It's pretty well designed. > I wonder if something simpler wouldn't be possible, that didn't involve storing keys on-chip, or storing them in encrypted form on the host. It is possible, but this is a weakness because you have the key in more than one place. Having it only inside the token is what makes the token unique. But Apple and Google are working on something like this: https://news.ycombinator.com/item?id=31272867 https://news.ycombinator.com/item?id=31272867 But personally I prefer the physical keys. And no it doesn't require browser storage.

eternityforest 4y ago

Tokens will have to get a bit cheaper, or software implementations will have to be more widely available and well known, and the storage will have to increase. I would not be happy if I suddenly had to by several of these tokens, carry them around, and potentially manually swap them out, since many current ones only hold 25 keys or so. I wonder if something simpler wouldn't be possible, that didn't involve storing keys on-chip, or storing them in encrypted form on the host. Couldn't the token just generate the key as needed, seeded by hash(domainName, accountName, salt, internalSecret)? It seems like YubiKey does something like this but some seem to actually store keys, or require some complex in browser or server side storage, adding points of failure. And there seems to be some "resident key" feature that always stores data on the authenticator? Is that really necessary?

GekkePrutser 4y ago
> I would not be happy if I suddenly had to by several of these tokens, carry them around, and potentially manually swap them out, since many current ones only hold 25 keys or so. This is not how FIDO2 works. It uses the same key but it generates a different derivative for every site. There is no limit on how many sites you can use it on. And the derivative is different for each site, so you can't hijack an authentication session and use it for another site. It's pretty well designed. > I wonder if something simpler wouldn't be possible, that didn't involve storing keys on-chip, or storing them in encrypted form on the host. It is possible, but this is a weakness because you have the key in more than one place. Having it only inside the token is what makes the token unique. But Apple and Google are working on something like this: https://news.ycombinator.com/item?id=31272867 https://news.ycombinator.com/item?id=31272867 But personally I prefer the physical keys. And no it doesn't require browser storage.