Compatibility with KeeOTP storage

[Fulgan]

The fact that the storage is incompatible (in really unnecessary way, as far as I can tell) with KeeOTP makes it a pain to migrate to this plugin: every other plugin that used to rely on the old format stops working.

Furthermore, the "upgrade" process deletes the previously exiting key, making it nearly impossible to recover.

[tiuub]

Hey, thank you for your feedback.

Im not sure about your problem. This Plugin is fully compatible to devinmartin's original KeeOtp. It can read the data which was saved by KeeOtp(1). Also the old Placeholder "{TOTP}" is supported. Even if it is marked as deprecated, it is still supported. You can use this plugin without doing anything. You only have to download it place it inside the Plugins folder. The migration process is only optional.

If you had done the migration process and you want to roll it back, you can simply click on "Edit" in the TOTP Window and tick "Use old KeeOtp save mode".

To get to your last point. The migration process seems stable. During my tests there happened no data losses. It's important to know, that the migration process changes the string field "otp" to "TimeOtp-Secret-Base32". Please look for these string field, if you have problems while recovering. Otherwise, if you still lose data through the migration process, please notify me.

[Fulgan]

Thank you for your answer. The issue is that many external plugins and tools used the KeeOTP storage format to read the entry secret and perform their own TOTP calculation (the ones that I'm personally using are KyPass 4 - and iOS keepass application - and KeePassHelper - a browser plugin for chromium browsers).

Removing the old key storage during the migration caused these applications to stop being able to access the OTP secret and support it.

According to the code, the removal of this key is voluntary and there is no way to re-generate them at all: once you've migrated, the database cannot be used by any of these tools anymore.

One possible fix would be to add a function to recreate the necessary keys based on the new format for all entries in the database (possibly through a tool) and update theses keys when the corresponding "main" key changes.

[tiuub]

Okay. I am understanding your issue. I have released an update. The migration process is now bidirectional, which means you can "migrate" and "recover".

In my opinion every plugin or app should switch over to the new built-in string field, to get an standardized environment. But well, some plugins are old and discontinued.

I will think about other methods to solve your issue, but for now, this should help you.

[Fulgan]

"In my opinion every plugin or app should switch over to the new built-in string field, to get an standardized environment. But well, some plugins are old and discontinued."

I agree that applications should migrate but the reality in the field is what it is.

Thank you very much for the updated version.

[tiuub]

No problem.

Sadly I have released the new update 1.5.0 with an bug. It is not a critical one, but it will create a lot of unnecessary MessageBoxes during migration. I recommend to you, to wait until 1.5.1, which will come up today or tomorrow.

[Fulgan]

Excellent, thank you.

I already installed 1.5.0 and noticed the issue. I fixed it in my fork and created a PR. I also took the liberty of adding a unit test project (which I used to test the problem)