On Sun, 2020-07-26 at 18:50 +0100, Jordan J wrote: > > 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. But that's a server side option. It works if you control the server, but not if you're using an external one (think github ssh key). That's why I like my second factor on the user side. > 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. Heh, well, I've been using TPM based two factor authentication in ssh for years (I actually use it for all my secure keys): it's nice and seamless and entirely controlled on the user side, but really hard to get the engine patch it requires upstream. > 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. Absolutely provisioning machines in a data centre is a royal pain when you have to get everyones ssh keys on to the new system correctly ... having an LDAP database simply do it is very convenient. It's just not the only use case. > 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. Well, the key handle is already a fully opaque data blob. Encrypting it only makes sense to add an extra authentication factor on the user side. James _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
