> Your worry is that webauthn isn't true two factor because it's only > based on a thing you possess rather than both a thing you know and a > thing you possess? I agree, I've always thought the ability to steal > someone's token was a big flaw in the scheme. However, it is trivially > fixable: if you encrypt the fido key handle with a passphrase before > sending it to the remote then even if I steal your token, I still can't > use it to access your account because when the remote presents the > encrypted key handle I don't know the passphrase to decrypt it. > This double encryption scheme should work for openssh public keys > containing the key handle as well. The only drawback is that to change > the passphrase you now have to change every public key in every account > you possess. To add some more context about why I'm looking to implement this on that note. Personally, I make it a second factor by setting AuthenticationMethods=password,u2f in the original patches or AuthenticationMethods=password,publickey in the current version. This makes the encryption of the key_handle unnecessary as there's a separate verification of 'something you know' and the keys only job is to verify 'something you have'. The key_handle just isn't sensitive information in this setup. The rationale is that the AuthenticationMethods approach integrates better in environments with centralised user/password management and importantly allows the administrator to ensure that it is /actually/ a two factor authentication. There's no such guarantee with the current encryption approach as the user could just choose not to encrypt their key handle. To put it another way, it lets the administrator ensure that everyone uses two factor authentication compared to leaving it a per-user choice. My hope is to make SSH two factor auth in that environment/setup as easy and simple as possible and not requiring the user to carry around both the token and the key_handle unencrypted on a usb seems like easy low-hanging fruit that I would hope isn't particularly contentious a feature. Secondarily to that it opens up the elegant possibility of AuthorizedKeysCommand pulling the users CTAP key details from a centralised system. That lets other non-ssh services share the setup and manage it centrally in which case ssh-keygen may not have been the original CTAP key registrar and thus leaves the user without a private key file to make use of - so the SSH server would need to send the key_handle for the token to function. On that basis encrypting or handling encryption of the key_handle is out of scope for this as I see it. If you want to encrypt it just continue using SSH as you do now. I'm aiming this at scenarios where encrypting the key_handle doesn't really make sense or is just unnecessary. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
