Use Key Uri for TOTP storage and limit which entries appear in the tray menu

[anonymous1184]

Hi!

Just wandering why the information is stored in 2 separate non-standard fields (TOTP Seed and TOTP Settings) instead in the TOTP field in the standard Key Uri format? Well, more than "why?" the real question is "can we have an option for the standard?".

The thing is, I'm going though most of the password managers and I've been having issues exporting and later importing, I need to manually setup again each entry and with 30+ accounts with 2FA is cumbersome. Which leads to a second question, is there a way to limit which entries appear in the tray menu?

[robinvanpoppel]

Hi @anonymous1184,

Regarding your first question:
I like your suggestion for using the Key Uri format that you refer to. Ever since I've been working on the project the settings were stored in these two fields, and I personally had no need to change it.

I see no real reason why we couldn't move to this format. Things to look out for when making this change:

• We currently grab issuer and username from the Username and Title of the password entry, so these could diverge.
• Time correction url's would have to be stored somewhere.
• Not sure on using the Key Uri with the steam format. We currently store "S" instead of a length there.
• Not breaking the experience for users of the original field.

For your second question:
Just a few ideas on how to hide certain entries.

• We could add a flag on the password entry, indicating that the item should not be shown in the tray.
• We could use the groups from the password database, so that for every group there is a menu item.
• We could keep track on which TOTP entries were used most recently, limit the number of items shown and show them in that order. Look for ways to store this without requiring saving the database.

[robinvanpoppel]

We should probably split this issue in two.

[alystair]

I really like the idea of hiding entries I don't use on a daily basis - also reveals less personal information if screen sharing.

[anonymous1184]

Hey @robinvanpoppel

I'm really sorry to just have dropped the issue and went missing, it turns out Coronavirus is making things nearly impossible. My modem got friend and the reposition arrived until now.

Migrating could be a PITA, and as you mention the time correction might be an issue. I have 40ish OTP entries and I don't use time correction (since I do use w32time service). However, out of curiosity I tried once this feature and ended up using only http://www.ntp.org/ (no SSL handshake). In the test I played a lot with the clock and always got positive results.

Perhaps, just perhaps (and I know it's a stretch)... simplify the feature? I mean a checkbox for time correction should be enough. Cascading ntp.org, nist.gov and google.com (the big bad wolf as a fallback since not even the great firewall blocks it), will always work since they have reliable infrastructures. I mean, I'm just brainstorming.

As of Steam... I don't have the slightest idea of their implementation because I don't use Steam, however I looked around a bit and found this, so something like:

otpauth://totp/[Steam:]<steamID>?secret=<identitySecret>[&issuer=Steam]

Might do the trick.

---

Now, regarding if is shown or not in the tray... well:

otpauth://totp/<user>?secret=<base32>&tray=1
otpauth://totp/<user>?secret=<base32>&tray=true

A URI by definition may have an arbitrary number of query components, so &tray=<bool> won't break the standard URI format, nor the Google's spec.

And that precisely opens up storing everything in there. A full-fledged example:

otpauth://totp/GitHub:anonymous1184?secret=BASE32&issuer=github.com&algorithm=SHA1&digits=6&period=30&tray=1&correction=<ID|URL_encoded>

With ID, I mean the row id in: Settings / "Clock Sync" tab / Time Correction List

I'll consider starting the IDs in 1 to avoid confusion with the boolean values if you go with 1/0. If booleans are true/false the ID can start in zero without any issue (my 2c).

TL;DR

• &tray= "true" to show (or the inverse)
• &correction= "true" for predefined. Or an ID or urlencode("http://server") for a specific one.

Stay safe!

[alystair]

This got me thinking, if we were to store information in this format, could we also theoretically interpret it and register as a protocol handler in Windows to save new OTPs 'magically' without setup? :)

[anonymous1184]

Indeed, basically you only need to add a new key in HKCR with "URL protocol" value. However I don't know how to attach it to a specific entry in KeePass. Reading the QR is a good option too, like "Setup by reading QR".

[alystair]

I'd say on desktops the url protocol handler would be much more effective. "Setup by reading a QR" would be non-trivial to implement and would provide dubious UX improvements on desktop. It would be more useful to have it baked into a project like Keepass2Android instead.

[anonymous1184]

Sorry, I'm a bit lost.

By reading a QR I mean to point to the QR code every of my OTP accounts have shown to me (the idea came from this extension). And as I see it is far easier than copy/paste the base32 secret, assign period and digits manually, then again we might be talking two different scenarios.

Here is a QR you can "scan" by dragging with the mouse. Now, the protocol registration will be on what? what will the sites needs to show in order to click and the registered URL handler save the otpauth Key Uri?

As for the mobile app, I'm of no use at all in there; I've tried 3 times over the last decade with high-end Droids and I ran back to iOS, I've used PalmOS, Symbian and Windows CE; but Android... IDK.

[dannoe]

This got me thinking, if we were to store information in this format, could we also theoretically interpret it and register as a protocol handler in Windows to save new OTPs 'magically' without setup? :)

Indeed, basically you only need to add a new key in HKCR with "URL protocol" value. However I don't know how to attach it to a specific entry in KeePass. Reading the QR is a good option too, like "Setup by reading QR".

This is possible to implement.
(more information for the implementation: see KeePass - Feature Request 1870)

[robinvanpoppel]

Migrating could be a PITA, and as you mention the time correction might be an issue. I have 40ish OTP entries and I don't use time correction (since I do use w32time service). However, out of curiosity I tried once this feature and ended up using only http://www.ntp.org/ (no SSL handshake). In the test I played a lot with the clock and always got positive results.

I suspect the reason for the https:// not working has to do with Tls1.2. We can probably fix that.

Perhaps, just perhaps (and I know it's a stretch)... simplify the feature? I mean a checkbox for time correction should be enough. Cascading ntp.org, nist.gov and google.com (the big bad wolf as a fallback since not even the great firewall blocks it), will always work since they have reliable infrastructures. I mean, I'm just brainstorming.

I'd love this specific feature to go completely go away or indeed be way simplified. The stability of the settings is nog great: I tried setting this myself in the settings and the dialog crashed and burned and brought down KeePass in it's flames. I'm rather curious if there is ever a need to do this time handling in the plugin while the operating system already provides ways to have an accurate system clock.

As of Steam... I don't have the slightest idea of their implementation because I don't use Steam, however I looked around a bit and found this, so something like:

otpauth://totp/[Steam:]<steamID>?secret=<identitySecret>[&issuer=Steam]

Might do the trick.

Now, regarding if is shown or not in the tray... well:

otpauth://totp/<user>?secret=<base32>&tray=1
otpauth://totp/<user>?secret=<base32>&tray=true

A URI by definition may have an arbitrary number of query components, so &tray=<bool> won't break the standard URI format, nor the Google's spec.

And that precisely opens up storing everything in there. A full-fledged example:

otpauth://totp/GitHub:anonymous1184?secret=BASE32&issuer=github.com&algorithm=SHA1&digits=6&period=30&tray=1&correction=<ID|URL_encoded>

With ID, I mean the row id in: Settings / "Clock Sync" tab / Time Correction List

I'll consider starting the IDs in 1 to avoid confusion with the boolean values if you go with 1/0. If booleans are true/false the ID can start in zero without any issue (my 2c).

I've been playing around with storing a few things in the KeyUri format, and that approach indeed has a lot of benefits.

TL;DR

• &tray= "true" to show (or the inverse)
• &correction= "true" for predefined. Or an ID or urlencode("http://server") for a specific one.

Stay safe!

Thanks for your time and suggestions. This thread has a lot of powerful ideas.

Stay safe as well!

[alystair]

Well this discussion made me realize I was using the "time correction" input incorrectly, I thought it had to be the remote URL, not a time server. Perhaps the input label should be changed to clarify this at the very least.

[dannoe]

Well this discussion made me realize I was using the "time correction" input incorrectly, I thought it had to be the remote URL, not a time server. Perhaps the input label should be changed to clarify this at the very least.

No I think you are right. I thought the intention behind this is to change the time KeeTrayTOTP uses for generating the T(ime)OTP. In the past I had problems using KeeTrayTOTP for origin.com (EA) because I only had like a 2 second timeslot to enter a new TOTP. But I didn't really try the time correcting thingy.

Because the OTP is timebased, it depends on the site/login provider how he calculates the TOTP on his side. I think there are also providers that do allow old TOTPs (like the last one) and even the ones that are in the future (like the next one). So that there are no timing issue.

Disclaimer: Just overflew the whole code some time ago

[alystair]

Yeah even in the pageDriver framework we extend the default window to allow for potential email delays if an authenticator isn't setup.

[anonymous1184]

The time correction can be either dismissed (in favor of w32time service, aka the "Set time automatically" setting in Windows) or optionally grab time from the issuer to get the EPOCH difference for the OTP that is about to be used. Example for GitHub: curl -ILs github.com | grep date:, if that fails a random/round-robin over a list of trusted servers (or big players like Google, Apple, Microsoft, Amazon...).

I suspect the plugin is quite popular, so a poll for the feature might be beneficial since we're talking about modifying a very old feature. However IMHO this feature, is not that useful since nowadays clocks must be set correctly for a wide range of services (at very least every service using SSL, id est 90-something of web browsing). I have a RasPI and those don't have HW Clock, for those kind of devices this options exist, but I don't see any added value for PC users.

Anyway, I just peek a bit the PR and is looking good. Thanks for the chat and the efforts. Please, be safe guys, is really hard to bury a friend, is harder every time the number goes up.