[Suggestion] Allow explicit Form Field ID references to ignore whitelist

feature
#1

G’Day Guys,

This is primarily a suggestion to help improve MFA (TOTP), but could be more broadly useful.

The actual KeePass ‘Kee’ tab contains a sub-tab called ‘Form fields’ where you can explicitly specify what should be filled into a particular element (by Kee) by the element id.

This is great, because MFA on many sites doesn’t really have a lot of consistency, and just blanket adding all the possible MFA input ID’s to the actual global whitelist is probably not ideal. So instead you can just add a new form field to the entry, manually determine the id of the MFA input, and stick that in with the {totp} placeholder.

What annoys me because I’m lazy is that I also have to add the ID to the Kee whitelist in every browser I use on every machine. It doesn’t treat the KeePass Database specification of desired interaction with that ID as an ‘alternate’ whitelist.

It would be nice if it did, as by far the most ideal solution (from my perspective) would be to specify the ID once, alongside the specification of the value, and then have that specification used as the whitelist for custom form fields.

Of course, the blacklist should still take the most precedence.

Not sure how feasible it would be to implement, hopefully fairly straightforward.

Pseudocode:

function checkFillingValidity(Input input) {
  if(input.id in keeOptions.blacklist){
    return false;
  }
  if(input.id in keeOptions.whitelist){
    return true;
  }
  if(input.id in keepass.matchEntries(request.url).getFormFields().fieldIds)
    return true;
  }
}
#2

Kee determines which forms are sign-in forms first and then searches the password manager(s) for entries that might match those forms. Therefore the challenge with the idea you propose is that we would have to make a fundamental change to that first procedure, essentially considering every form on every page a potential candidate to receive credentials. At the moment, only a small percentage of web forms trigger the search for entries in the password manager.

I’m also not sure how we would solve the issue of configuration prioritisation for those cases where there are multiple matching entries, multiple open databases or even multiple password managers connected to Kee.

This all unfortunately means that this would be a complicated and high risk change to the extension with no certainty that it could be achieved without a detrimental impact on the performance of the extension (primarily I would imagine battery life being the most likely to suffer since Kee and the password manager(s) would have to execute a lot more code more often but there is also a higher risk of unwanted form fill operations). As such, it’s not something I’m personally all that keen to focus on right now, although maybe one day I’d consider it and I completely understand why the change would help with TOTP form filling in particular so I’m definitely open to further ideas for improvement.

Thanks for taking the time to think about and write up your suggestion.

#3

Makes sense. I was afraid that would be the sort of order it worked in, but I had to ask.

Thank you for taking the time to respond :slight_smile:

I did have some other ideas to make TOTP work better, with the added bonus of them also having positive effects on other things.

  1. Add an option in the right click context menu (ie: ‘Find Matching Logins’, ‘Add Element ID to Form Whitelist’, ‘Generate Password’) that adds that input’s ID to the whitelist (I’ve seen something similar suggested somewhere already but can’t remember where)

  2. Backup/restore of serialised settings via file or cloud (Google Drive, etc), like the Reddit Enhancement Suite, so the whitelist (and the other settings) can be added once and then synced easily/automatically.

  3. Still hook into the KPDB to derive ID’s for the alternate whitelist concept from above, but only as a one-off on connection to the db, or as a button/menu entry somewhere (or both).
    I can think of two ways this might work.
    The first is by defining a special entry in the db whose sole purpose is to serve as a host for the various settings being persisted (could include more than just whitelist), and then either manually specifying it in Kee, or having a default setting with a fairly unique naming convention to reference it automatically.
    The second is to apply the ‘Only run on connect or when manually triggered by the user’ thinking to my original suggestion. Scan the whole DB for user-specified Form fields, and just soft-persist them for the normal checking process alongside the properly configured whitelist.