Keepassxc: TOTP doesn't work with keys with spaces and lowercase letters

[ghost]

When trying to use TOTP keys which contains spaces (e.g. _yygb 1rte sg5y_), KeePassXC throws an error saying that the said key is invalid and that it needs to be in proper Base32 Format. Even removing the spaces doesn't resolve the issue. Also, why can we not import TOTP keys from a CSV generated by BitWarden? Similarly, why can't TOTP keys be exported?

[droidmonkey]

I have no idea what format bitwarden uses. Exporting TOTP is enabled for QR reader based applications (think mobile). We have an open issue to allow export with CSV export.

As for your secret key, just convert it to Base32 using an online converter. Although I highly doubt that is the actual key, that looks more like a "recovery code" in case your TOTP fails.

[ghost]

Here is an example of such said key from Tutanota: _2g3g gee3 dv7o xrk6 5h5k vlng pq_

When I attempt to import it, KeePassXC throws me the error but I can easily use it in some other TOTP apps like Aegis/andOTP or BitWarden.

Also, I realized that KeePassXC offers XML import/export which has TOTP keys, is there any way to do it through GUI instead of the CLI?

[droidmonkey]

XML import/export, not right now, no.

Does converting the Tutanota string to Base32 using an online converter make it work? You'll probably have to remove the spaces before you convert.

[ghost]

I tried that using both online converter and the terminal tool (echo -n STRING | base32) but it generates wrong codes.

Also, is XML import/export fully supported or is it barebone? Like if I have a large database and export it to an XML file, will I be able to import it on another empty database later on? I mean, are there any serious bugs/issues present with the XML backup.

[KopfKrieg]

It's not only a bug, it's also a regression (could someone please add the according label?)

A few days ago, on v2.4.3, I've added a 2FA Token from Tutanota, using the RFC 6238 format without any problems. I then updated to v2.5.0 and tried the same, which resulted in the error message:

Sie haben einen ungültigen geheimen Schlüssel angegeben. Der Schlüssel muss im Base32-Format sein. Beispiel: […]

Which roughly translates to:

You've entered an invalid secret key. The key has to be in Base32 format. Example: […]

Also, I can still read the old token on v2.5.0 (which was stored in my KeePassXC database using KeePassXC 2.4.3) it in its normal format (e.g.): 5wc3 5fpl usy2 mo55 ydlw 2tr4 j4. It's also still working, I just can't update or change it on v2.5.0 because of the error message.

[droidmonkey]

How is that even possible? We do a base 32 sanity check prior to generating a totp code in 2.4.3. I'm using the same sanity check to issue the base32 warning. If that check fails in 2.4.3 you'd see "invalid key" instead of a totp code.

[droidmonkey]

Spaces are not part of base32. Just remove the spaces and make the letters capital. Base32 is A-Z and 2-7.

[KopfKrieg]

How is that even possible?

I have no idea, but apparently the sanity check is not working on v2.4.3. Also, even if I remove the spaces from my previously posted key and replace lowercase with uppercase letters (5wc3 5fpl usy2 mo55 ydlw 2tr4 j4 → 5WC35FPLUSY2MO55YDLW2TR4J4), I still get an error message on v2.5.0:

Sie haben einen ungültigen geheimen Schlüssel angegeben. Der Schlüssel muss im Base32-Format sein. […]

Which roughly translates to:

You've entered an invalid secret key. The key must be in Base32 format. […]

[droidmonkey]

AHHHH figured it out. Because the key is not a multiple of 32 bits the sanitize function appends a bunch of equals signs to the end to pad the result. This causes the comparison to fail resulting in the error message. Easy fix, thank you for reporting the issue!

I will also automatically convert the input to uppercase and remove spaces.

[ghost]

Thanks a lot for taking care of this.