Support KeePass2 TOTP configuration settings

[sjvudp]

Overview

I had configured 2FA TOTP in KeePass, but when I open the database in KeePassXC, the TOTP configuration is not recognized. Compatibility with KeePass would be highly desirable.

Steps to Reproduce

1. Create a TOTP entry in KeePass (TimeOtp-Algorithm=HMAC-SHA1, TimeOtp-Length=6, TimeOtp-Period=30, TimeOtp-Secret-BaseE32=YOUHAVETOADDYOUROWN!)
2. The password field has "{TIMEOTP}"

Expected Behavior

Copying the password (^C) would copy the current 2FA sequence.

Actual Behavior

"{TIMEOTP}" is copied.

Context

KeePassXC - 2.6.6 Revision: 9c108b9

Operating System: openSUSE Leap 15.3 Desktop Env: Gnome Windowing System: X11/Wayland

[droidmonkey]

That format is not supported in KeePassXC at this time. Use the setup totp feature in keepassxc with your totp secret to "dual configure" for both keepass and keepassxc.

[Kobi-Blade]

To be fair the TOTP feature on KeePass is extremely barebones, the proper alternative we have on KeePassXC is vastly superior.

Adding this feature would be more of a regression than anything else.

[droidmonkey]

We would only add the ability to read the settings and offer the same totp experience within keepassxc.

[sjvudp]

Adding this feature would be more of a regression than anything else.

When sharing one file between KeePass and KeePassXC, then being able to use the TOTP mechanism defined with KeePass from KeePassXC it would not be a regression; instead it would be an enhancement!

[Kobi-Blade]

Adding this feature would be more of a regression than anything else.

When sharing one file between KeePass and KeePassXC, then being able to use the TOTP mechanism defined with KeePass from KeePassXC it would not be a regression; instead it would be an enhancement!

What you need is to ask the KeePass developer to add proper TOTP support like we have on KeePassXC, we are in 2022.

Is honestly one of the main reasons I switched to KeePassXC, the original KeePass is stuck in 2003.

[droidmonkey]

We did ask him and he denied our request to just use "otp"

[Offerel]

Is there some timeline, when we can expect to at least the field TimeOtp-Secret-Base32?

[droidmonkey]

This isn't on the top of our list. You can just configure totp in keepassxc using the same secret and everything will work in both apps.

[Offerel]

I don't want to be pushy, because I know how annoying this is for such a project. I also know that I can use both fields at the same time as a workaround but that is really annoying in the long run.

[b4st1en]

What you need is to ask the KeePass developer to add proper TOTP support like we have on KeePassXC, we are in 2022.

And the "proper way" must be yours, of course.

his isn't on the top of our list. You can just configure totp in keepassxc using the same secret and everything will work in both apps.

Except that... all OTP are not using a single format so your workarround does not work for all kind of OTP

And Is that me or you are compliant with "KeeOtp" plugin.. but not KeePass ? https://github.com/keepassxreboot/keepassxc/blob/develop/src/totp/totp.cpp#L87

You are right.. adding some "switch" in some functions sounds so complicated and painfull that it should have at least its own Epic issue in some Jira..

This must be considered as a a bug as it does not comply with the "official" way to manage OTP which was released more than one year ago (KeePass 2.47 : 9th September 2021)

If it bothers you to "respect" KeePass formalisms, don't say you are compatible and change the name of the application and its database format.

[b4st1en]

Any update ? Could you please remove "new feature" and replace it with "bug" :)

[theincogtion]

Why not using the keepass standard and offer a migration for keepassXC entries to be compliant with the standard?

[juliomaranhao]

I am a long time KeePass2 (Windows) and Keepass2Android user. I am just evaluating KeepassXC (Ubuntu 22.04), which seems to be a fork of KeePassX (correct me if wrong). Of course I didn't like to discover this OTP issue / incompatibility, but I have to respect the developers ego because they are doing voluntary work. So I am NOT here to beg for compliance with the KDBX4 (or 3) format as defined by KeePass author. I just have two douts:

1. I cannot see the attribute (KeePass2 string field jargon) TimeOtp-Secret-Base32 in the additional attributes list. Even if KeePassXC does not understand KeePass2 TOTP format, shouldn't the attribute be at least available for view/edit? Am I doing something wrong?

2. Is there a list of incompatibilities between KeePassXC and KeePass2? I mean if I use both to manage the same KDBX4 file, will I loose data? Will I loose functionality? As this is off topic, I'd be glad if someone show me some blog/site/discussion.

Cheers.

[Offerel]

Currently TimeOtp-Secret-Base32 is not supported on KeePassXC and I miss it really. More important, the placeholder TIMEOTP does not exist and a sequence with this, will throw an error. Hopefully this will change in the future.

Im not aware of any other things which are not compatible. I hope the situation with TimeOtp-Secret-Base32 and TIMEOTP will change, since using standard KeePass with mono on Linux is no alternative.

[droidmonkey]

To clarify, the TOTP and HOTP settings from KeePass2 are NOT part of the KDBX standard. At least they were not part of KDBX 4. They were introduced about 3 years afterwards.

Also, I just made a new entry using KeePass 2.53 and added TOTP configuration. I can see the attribute that holds the TOTP secret without any issue in KeePassXC.....

Then I created a corresponding KeePassXC TOTP configuration on that same entry in 0.5 seconds:

[juliomaranhao]

@juliomaranhao (Me)

1. I cannot see the attribute (KeePass2 string field jargon) TimeOtp-Secret-Base32 in the additional attributes list.

My bad, my bad. Sorry for wasting your time, @droidmonkey. I was using an old database file where the entry yet did not have otp info. Now I tested the correct one and it works as you showed.

@Offerel

Im not aware of any other things which are not compatible. I hope the situation with TimeOtp-Secret-Base32 and TIMEOTP will change, since using standard KeePass with mono on Linux is no alternative.

I am choosing KeePassXC and Keepass2Android standard, because this covers Win/Lin/Android better (same standard read/write OTP config). So I am quitting using KeePass2 in Windows as I think it could be a mess to mix the standards. For instance, Keepass2Android allows me to have both standards at the same entry.

[droidmonkey]

You'll find our program is just generally faster and easier to use than KeePass2. I just used it again to test this issue and immediately ran away.

[Offerel]

Yep, thats so true. KeePassXC is a lot faster. Specially under Linux/Gnome. Here the standard KeePass takes ages to enter the credentials via Global AutoType. The only thing i really miss, is the missing sync via WebDAV inside of the password manager itself. I know the endless discussion about this topic, but in fact, i miss it. I have workaround this with a bash script triggered by systemd service on a) grapical.target (before Login) and b) a second systemd unit triggering the same bash script, when the keepass db changes on the hdd. It uses curl in the background to download/upload the db automatically. Using a davfs2 mount was not a wise idea, this was to unstable.

Besides of this and back to the topic: @droidmonkey please support in a future version the TIMEOTP placeholder additonally, to the TOTP placeholder. It is really annoying to receive an error message and to have to seperate sequence, when i have to use the same database with standard KeePass and KeePassXC. I have no chance to use KeePassXC in my work anvironment.

@juliomaranhao KeePass2Android and KeePassDX on Android support both variants for holding the shared secret and also support both placeholders. So it doesnt care, which Desktop application you use. In fact, i have both fields on every TOTP entry and it works fine. Using the "otp" field from KeePassXC has the benefit to support also non standard RFC6238 TOTP codes, like Steam. This is at least currently not possible with "TimeOtp-Secret-Base32".

[juliomaranhao]

KeePass2Android and KeePassDX on Android support both variants for holding the shared secret and also support both placeholders. So it doesnt care, which Desktop application you use. In fact, i have both fields on every TOTP entry and it works fine.

@Offerel I just tested KeePass2Android, again. It recognizes the KP2 standard BUT if there is an otp attribute then it ignores the KP2 standard. As I see it, there's no way to use both standards without double work (from user perspective) to keep the same value in both attributes. And no single KP* can fully implement both standards without risking other KP* unsync the attributes.

About your systemd story and work environment story, I feel sorry for you. My requirements are way simpler.

[Offerel]

I have not tested this, but maybe you can reference the secret key value. Personally for me I have use both separate or mostly the otp vaeiant, because my private pc is Linux only. I have to use Windows only at work and there I can use the https://github.com/tiuub/KeeOtp2 plugin which allows it to the otp entry from KeePassXC. This and KeeAgent are my only 2 plugins for standard Keepass application. But I hate it to use Windows...

[dj-wednesday]

Can KeePass XC discover 'legacy' 2FA fields via search?

I discovered this limitation in KeePass XC today, after using KeePass 2 for many years. The TimeOtp-Secret-Base32 field with the secret is present, but only treated as an 'additional attribute':

• I have many entries with 2FA secrets in TimeOtp-Secret-Base32 fields.
• Even if I wanted to manually copy all the secrets into KeePassXC's format, I cannot find a way to easily discover all entries with TimeOtp-Secret-Base32 fields.

I realise it's unlikely for KeePass XC to have an option to auto-populate its 2FA from TimeOtp-Secret-Base32 fields.

But it would really help if KeePass XC had some way to easily discover entries with legacy 2FA secrets. Why not let the search discover the names of 'additional attribute' fields?

[michaelk83]

attr:TimeOtp-Secret-Base32 or more simply attr:TimeOtp should work.

https://keepassxc.org/docs/KeePassXC_UserGuide#_searching_the_database

The following fields can be searched along with their abbreviated name in parentheses:

• Attribute names and values (attr)

[dj-wednesday]

@michaelk83 Thank you, this is very helpful.

[theking2]

Adding this feature would be more of a regression than anything else.

When sharing one file between KeePass and KeePassXC, then being able to use the TOTP mechanism defined with KeePass from KeePassXC it would not be a regression; instead it would be an enhancement!

What you need is to ask the KeePass developer to add proper TOTP support like we have on KeePassXC, we are in 2022.

Is honestly one of the main reasons I switched to KeePassXC, the original KeePass is stuck in 2003.

But it is supported. I have a use case for this as well. On Windows 10 I use Dominik Reichl Keepass and have setup a number of sites with TimeOtp-Secret-Base21 which work fine. On my Fedora laptops I have to use KeepassXC which seems unaware of the TimeOTP settings.

[theking2]

I could just copy the entry in Advanced TimOtp/Secret-Base32 to the KeepassXC only Secret Key: in Setup TOTP. Iḿ not sure why it is made in such great deal to copy/paste this in code.

[ffes]

I find this incompatibility quite annoying as well.

When I look at the code in src/core/Topt.* I see there is already support for multiple OTP-formats.

There is obviously support for the otp-url which is the default for KeePassXC.

There is support for the KeeOtp plugin. I assume this is for supporting the KeeOtp 1 plugin which is gone. There is a KeeOtp 2 plugin, but that uses the default KeePass settings and it can migrate the KeeOtp 1 to the native KeePass settings.

And there is support for a legacy csv format. No idea what that is all about.

So I don't really understand why there isn't support for the native KeePass OTP settings. It's most likely a matter of "somebody has to do it", and the core devs probably don't have a personal need. It get that.

I am able to build KeePassXC on my Linux machine. My C++ knowledge is not that modern, otherwise I would consider adding this myself. If adding support in Topt::parseSettings() and Totp::writeSettings() is all that is needed, it seems doable. Maybe @droidmonkey can answer this question.

[droidmonkey]

What I find annoying is KeePass's incompatibility with everything else that was out there BEFORE they decided to make a new "standard". They took what is extremely efficiently represented as a url string (otpauth) and spread it out across 3+ attributes.

Problem 1- I'll only accept an implementation that takes the 3+ attributes and converts them to an otpauth string for the existing TOTP code to parse

Problem 2- which attribute(s) take precedence if multiple exist in the entry? otp or KeePass ones?

Problem 3- when setting up new TOTP, we will only support the existing otp standard. Do I need to now provide some ui element asking user if they want to use KeePass' silly standard or otp? No. See https://github.com/keepassxreboot/keepassxc/issues/7263#issuecomment-1008668090

It's a freakin mess and it is 10000% KeePass' fault.

How about KeePass support the existing otpauth standard and get off the crazy train?

Recommend just taking 0.5 seconds to setup TOTP in keepassxc using our ui and the existing totp secret in your entry instead of wasting 10 hours coding this dumb feature. https://github.com/keepassxreboot/keepassxc/issues/7263#issuecomment-1409325004

[droidmonkey]

For the record, I am ok with implementing the {TIMEOTP} placeholder as that is very trivial to support without changes to anything related to attribute handling.