I’ve been adding OTPs to more services, and while having an app on my phone is fine, I found the KeeOtp plugin which works a charm with the builtin autofill from KeePass, but I’d like to use Kee to fill this in for me.
I’m not sure what else to try now.
Kee does not support placeholders such as the {TOTP} variable. Some other people have requested this feature on GitHub but I need to think about the right way to enable such support before we come up with an implementation plan.
Things to discuss here include:
In terms of end behavior, I’d say any field other than username and password should by default not autofill, instead requiring a click on the already-present kee icon in the field to be filled. Granted, this comes from the perspective of someone who already does not use autofill for security reasons. As for warnings, in my time looking at keepass plugins and alternative keepass implementations, I don’t believe I’ve ever seen a TOTP plugin actually warn of the inherently reduced security associated with using them. I personally use KeeTrayTOTP (extended functionality fork of TrayTOTP), and know there is no warning in that. That said, I’m not entirely sure it’s appropriate to plaster warnings over the functionality beyond a cursory one-time notice. While yes, usage within keepass changes a TOTP from 2FA to just a dynamic extended password, I would imagine very few keepass users fail to understand that. Even in that state it still serves to extend security in all cases other than an unauthorized user using a device with an unlocked keepass database.
From the perspective of someone who admittedly has literally zero concept of how Kee works under the hood, I would think simply adding extra field IDs to search for (likely just TOTP/OTP/HOTP/2FA and possibly E-mail by default, with the option to let users add more) before attempting to check the database for relevant parity would be the most compatibility-friendly choice. I wouldn’t expect that to impact performance notably, but I could easily be mistaken on that point.
Worth note, some people will also want to use this to auto-enter credit card or bank account information. It might be worth adding a warning for that behavior when known fields are referenced (at least when attempting to set up that behavior for the first time).
Thanks for the input.
I pretty much agree with all of your first paragraph, although not the premise of disabling auto-fill on some fields (but that’s pretty tangential to this topic anyway so let’s not linger on that). The only other thing that I’m not sure about is whether “very few keepass users fail to understand” the increased risks. Without doing user surveys I can’t back up my view with anything concrete but anecdotally, people I have spoken to and interacted with on forums like this over the years do not often come across as having the requisite security knowledge to be able to reach the conclusion you suggest. Regardless, I agree that with the right balance (not plastering warnings everywhere every time for example), the quantity of people that directly benefit from such warnings is not a critical consideration.
I’m working on a plan for this feature today and will provide an update soon.
I’ve finished analysing this now and have decided that even though current support for placeholders/TOTP is almost complete (only custom plain text fields don’t already support “{TOTP}”) it is worth filling out this feature using a more complex implementation because there is a tiny information disclosure risk from the use of placeholders which is not (IMHO) adequately mitigated and disclosed with the current implementation.
Answers to my own questions:
No. As @Sanaki says and following a brief look around the internet myself, it appears that these warnings are at best very difficult to find, if not entirely absent.
https://bitbucket.org/devinmartin/keeotp/issues/44/possible-security-concern suggests that this may be added to the Wiki one day but there appears to be little urgency and the existence of other similar plugins mean that it’s not going to be feasible to wait upon such 3rd parties before we proceed with our implementation work.
2.1. See plan below.
See plan below.
Performance concerns such as those mentioned on the old forum are typically based on measurements where every entry in a database is routinely processed in a way that requires searching all other entries. The impact is limited if the quantity and variety of placeholder types actually used is low. In fact, since placeholders are already supported in a majority of cases in KeePassRPC, it is safe to say that with some additional mitigations, the performance impact of this project could actually be a net benefit for some users.
We have two main approaches to consider in order to mitigate the performance costs:
The plan below follows the 2nd approach since this is likely to be more discoverable and comprehensible by users.
No. Per the plan below, we will support placeholders in any field type.
I think the implementation plan below is the only way to retain backwards compatibility. We ensure that the only change for consumers (clients) is a different value for some fields.
The proposed implementation allows this. The disadvantage is primarily performance reduction - mitigated by the need for opt-in for specific fields.
See GitHub issue #30 for these details.
I’ll test basic placeholder replacement and try to find some plugins that are easy to set up with placeholders (such as KeeOTP). Then I’ll release a beta and wait a few days for some other people to test their own specific use cases for placeholders.
We will work on the assumption that if a user is technically competent enough to install KeePassRPC and another plugin like KeeOTP and then work out how to link the two together without referring to our documentation, there is a high chance that they already understand the risks. As mitigation against this assumption being incorrect, a moderately scary message and link to the documentation will be included in the parts of the UI where the placeholder functionality can be enabled by users.
The docs will be hosted on a page in this community and include:
The examples will include using KeeOTP eventually, although I might not have time to write this myself in the short-term.
It’s a fairly well defined set of tasks and none are huge so it should be possible to get this released along with KeePassRPC v1.8 in the next few days but documenting all the subtleties could take longer than that.
Sorry for the long delay in getting back to y’all.
A little more info about my use case.
As such having an automated 2FA code that the users never ‘touch’ would be a good way to keep our data to ourselves.
The implementation plan seems like a good way forward.
Perhaps shaking the KeeOtp plugin author’s tree a bit might get some heat applied to the security issue.
All in all our particular use case is limited and less of a “secure all the things” and more of a extra speed bump to limit un needed access to specific users.
I tried out this new functionality using the latest (1.8.x) KeePassRPC plugin, and the new placeholder fields are working a charm!
I’m gonna try rolling it out to a few users soon, and see how that goes. Probably a week or so away since this has to happen when I don’t have other responsibilities taking priority.
I am also using the KeeOtp plugin in KeePass (installed it today) and it would be great if Kee fills the TOTP codes into websites.
I have to admit that I did not read all information written above but how is the current status?