Ability to return current TOTP from secret service api

[olaf-b]

Summary

Having the keyring report the TOTP can be very useful for automated procedures in a shell. Thus being able to tell KeePassXC to report the TOTP-value for password would make a lot of sense. Other cases to where it makes sense to report something compound would require that the password return is customizable. So selecting the default {PASSWORD}, or {TOTP}, etc as a configuration option for what a keyring call will return, that would be way cool!

E.g. automatic connection with vpn using openconnect-sso where there is 2fa required. I do this in a forked version of openconnect-sso (see my github repo), but I have to send the TOTP secret as password and let the vpn client calculate the TOTP value. Would be so much better and safer to have the keyring (KeePassXC over libsecret-call) report back the calculated TOTP-value.

[droidmonkey]

Actually no, sending a totp value via secret service absolutely invalidates the whole purpose of a second factor. You should use Auto-Type for the totp value to put a human in the loop of that request. We won't be implementing totp over secret service due to this, and I don't think that is even part of the spec.

[olaf-b]

@droidmonkey I disagree completely. The point of any *OTP is that the value is not constant. And from the days when the wire was not encrypted, it prevented replay-attacks. It does not imply a human in the loop. Also, using the auto-type is error-prone and might not work well for console applications.

[olaf-b]

So if this is a straight out 'no', and so bluntly rejected, I will have to reconsider KeePassXC.

[droidmonkey]

The challenge is that there is no distinction for TOTP request from secret service. How would that even be handled in this case? Repurposing the password field is not an option. The {TOTP} placeholder is only valid in Auto-Type context.

I could just as easily leave this open for 4 years and the effect will be the same as an honest no up front.

[olaf-b]

Your choice. I currently use KeePassXC for my passwords, and had to serve the TOTP-secret as a password to let the downstream tools calculate the TOTP-value, i.e. a password-entry in KeePassXC + another password-entry for the TOTP-secret in KeePassXC. Then libsecret looks up the two different "passwords", and takes one of them for generating the TOTP. I'd like to be able to have libsecret fetch a "password", but in reality this could be a *OTP or some other compound response composed by {PASSWORD}{ENTER}{TOTP} or similar. There are many legit use cases for this without telling/restricting people how to deal with their security. If you find this will never make it into your code, then reject it. If I get the time and inspiration, I will implement in this tool or other. Pass already has this feature (extension), but doesn't work through libsecret and is also less cross platform.

[droidmonkey]

Does your VPN program request a password through libsecret to fill the totp field? What you are asking for is already available through Auto-Type, but targeting console is a bit of a challenge. Albeit much easier with 2.7.0's Auto-Type improvements.

[olaf-b]

My workaround is to make secret service provide two passwords: 1) the password, 2) the totp-secret. Then the application has to calculate the TOTP-value. What I think would be more secure is to not have the TOTP-secret or password ever leave the keyring/keyvault, and just respond as normal to a password request. But rather than responding with the {PASSWORD}, it would respond with the {TOTP}. If the password request response would be configurable just as in the case of AutoType, then this would work well. In fact, the whole point is to circumvent the need for having any windows in the console case, and also I find that the windows that pop up for e.g. CISCO VPN SAML login will not provide sufficient info to make AutoType work by window identification. Yes, you can do it by manually selecting to AutoFill in the KeePassXC GUI.

[espenfl]

I would support adding something like this. Use case would be MFA VPN as well. Considering pass, but as @olaf-b says, KeePassXC har some nice benefits of being cross platform.

[Aetf]

But rather than responding with the {PASSWORD}, it would respond with the {TOTP}. If the password request response would be configurable just as in the case of AutoType, then this would work well.

How would KPXC know which password to respond with? The secret service spec only supports one single session-encrypted password field per entry. So the client has to make two separate requests to get both the password and the totp.

[michaelk83]

I think the idea is still to have separate entries for regular password and TOTP (as per this and this comments), but have one of them configured service-side as TOTP. This would move the TOTP derivation service-side, so that the TOTP secret doesn't need to be transferred, only the final time-varying password (this also simplifies the client).

Ideally, the spec would allow the client to configure TOTP entries, but apparently this use case wasn't anticipated.