3 ms·

Too bad that they still require a username/password and only use webauthn as 2FA. Why not go full passwordless, with a fido2 token + pincode? It's more secure

Too bad that they still require a username/password and only use webauthn as 2FA. Why not go full passwordless, with a fido2 token + pincode? It's more secure and you need the token anyway. No password to remember or for an adversary to guess. Even the account can be derived from the token. With Office 365 all I have to do is insert the token, enter the pin, touch it (to avoid remote control abuse) and I'm logged in. Simple as taking money out of the ATM and just as secure.

eternityforest 4y ago
Tokens can be lost. Everything I've seen uses tokens as one possible 2F of many. (password and phoneNumber) or token might be harder to explain than password and oneOf(token, phone, etc) Plus they'd have to probably change a lot of code, for not thar much demand, everyone just lets the browser remember passwords.
- GekkePrutser 4y ago
  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 can be lost. Everything I've seen uses tokens as one possible 2F of many. (password and phoneNumber) or token might be harder to explain than password and oneOf(token, phone, etc) Plus they'd have to probably change a lot of code, for not thar much demand, everyone just lets the browser remember passwords.

GekkePrutser 4y ago
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.