"Form fields" tab items

It seems I’m not the only one which is confused by the “Form Fields” Tab. I do know how Placeholders work in Keepass but how is this all connected here? I mean what are especially the values for “Name”,“Id” and the weirdest one “Page”? I really tried to understand and also searched through this forum and FAQ but I essentially failed at understanding these columns. Can you please give a detailed explanation of the form-field section as I don’t know how this all relates?

Especially I had the case that I created a new Entry through Kee Browser extension from the “registration page” which did put a lot of form fields into this section with “Database default” as value. However when I then tried to login after registration Kee Browser extensiont always filled out “username” with the value of “givenname” instead of what was really the content of “username”. In the end I had to delete all fields except “KeePass username” and “KeePass password” to make it work like expected but I would like to understand why it did that but as I said form fields section of Kee (except of handling placeholders) is a big myster as of now to me.

I’m not entirely sure how you ended up in a case where the password Kee saved was then immediately not able to be filled in unless you had to modify the items in the form fields tab. Most people never need to customise anything within there but I could guess that this problem might occur if a website randomly re-uses names and unique IDs behind the scenes, thankfully I’ve never come across this so I would hope this was a one-off problem.

The columns are:

Name: The “name” attribute in the HTML on the web page.
Value: What gets inserted to the form field.
Id: The “id” attribute in the HTML on the web page.
Type: The type of form field in the HTML on the web page, with the additional “magic” type of “username” which is prioritised for insertion to the first “text” field.
Page: No longer used but before Firefox forced the extension rewrite a couple of years back, this would relate to how many pages through a multi-page automatic sign-in procedure the field should best match against.

I’ve tried to make this clearer for new users of Kee Vault (and harder to confuse for something that must be well understood in order to use the browser extension) but changing this area of the KeePassRPC plugin is a lot of work so it’s unlikely I’ll make any modifications in the foreseeable future apart from potentially removing the page column or modifying the list of available types.

I think I slowly get the hang of how it works by also having a look at the Vault demo. So when I create a new entry in Kee it saves all available form fields I filled in with their corresponding values. So if the same id/name combination shows up again on this site it can fill in not only username & password but also other data. Did I get this right? If so, that’s a very cool feature indeed. And now also the security risk of placeholders gets clearer to me which it wasn’t even there was a long explanation of yours in that thread. But as I did not fully understand how this auto-fill worked I didn’t get the potentional risk. But the risk is also really small as someone would have to target specific entries and the master passwort afaik can not be used as placeholder as it’s cryptograhipcally not available (hopefully)

The only thing still unclear to me is, what if id & name is filled. Do both have to match or is it enough if just one field matches? Basically that question also applies for black/whitelist in the kee extension. Do both have to match or not?

Thanks for quick clarification on that issue. And I agree it’s very weird that I had to modify this fields. I should have inspected it actually to see why it worked the way it did. But I didn’t get how form fields work at the time as well.

Did I get this right? If so, that’s a very cool feature indeed.

Yep :slight_smile:

It’s not a generalised form filling solution but works very well when there are sign-in forms with multiple “usernames” or multiple “passwords”. Even drop down boxes, checkboxes and radio buttons can be selected (albeit not the type that ask for different information each time such as character x from password number 3).

But the risk is also really small as someone would have to target specific entries and the master passwort afaik can not be used as placeholder as it’s cryptograhipcally not available (hopefully)

I’m not aware of any way that KeePass can reveal the master password directly via a placeholder but it does allow arbitrary execution of programs on the host machine so although highly unlikely and probably only as part of a targetted attack as you suggest, it is feasible that this could reveal the master password (along with everything else on the machine of course). So yes, low likelihood but there’s such a high cost if this feature is abused that I really can’t justify leaving the functionality enabled by default (and as you may have seen, I’m not really even giving much effort to support placeholders in Kee Vault).

The only thing still unclear to me is, what if id & name is filled. Do both have to match or is it enough if just one field matches? Basically that question also applies for black/whitelist in the kee extension. Do both have to match or not?

For the black/white list, we consider that a match has happened (and hence the form should be white or black listed) if any of the 4 types of search match (form field name, form field id, form name, form id).

For the prioritisation of individual entries and the choice of which form field is the best match for each piece of information in the entry, it’s more complicated. The direct answer to your question is no, both do not have to match. However, if both do match, it’s considered a stronger match. If an id or name is configured on an entry and it does not match the field in the web page, that is considered a lower-quality match than if there were no id or name information attached to that form field in the entry.