Placeholder handling

documentation
placeholder

#1

KeePass placeholders are a powerful feature that can save time configuring and maintaining large password databases and add custom behaviour to suit your workflow and preferences.

Since KeePassRPC 1.8, you can use placeholders anywhere that you would normally include a form field value. This includes the standard KeePass username and password fields as well as any custom form field that you configure for an entry.

Warnings

:warning: General use of placeholders

It is possible to configure your entry form fields with placeholders which will reveal information that you did not intend to. The scope of what can be revealed is as wide as the entire contents of your password database and even some information about your computer. You can view the documentation on the KeePass website to see what information can be accessed using placeholders.

:warning: Plugin placeholders

Some plugins enable additional placeholders. You should ensure that you understand the security impact of using these plugins and weigh that against any perceived increased convenience. For example, the KeeOTP plugin allows you to store the information required to use your KeePass database as a 2nd factor authentication token.

This essentially guarantees account compromise if your password database is compromised, negating one of the protections of multiple factor authentication. In some targeted social engineering attack scenarios you may not even need to intentionally utilise the corresponding placeholder ({TOTP}) in order to allow an attacker to authenticate as you.

This is a complex topic and one that is not specific to this one example plugin so you should ensure you understand the risks before proceeding.

Limitations

It is not possible to execute local programs. The {CMD... KeePass placeholder is disabled for security reasons.

Enabling the feature

This feature is disabled by default and can be enabled in one of two ways:

For the entire database

This is not recommended because it significantly lowers the barrier for an attacker to access your data (explained in the warnings above).

If you do need to enable it (perhaps for test purposes or in already low-security environments) you can do so via KeePass > File > Database settings… > Kee tab > KeePass placeholder tab.

The following screenshot of the Database Settings dialog illustrates this.

grafik

For individual form fields

Open and edit the specific entry in KeePass and then:

  1. Click on the Kee tab
  2. Click on the Form fields tab
  3. Select the form field that contains the placeholder (in this example, the main KeePass username field)
  4. Click on the Edit button
  5. Click on the Enable radio button

Then click OK until you’re back to the main KeePass window and save the changes to your database.

The following screenshots courtesy of @proxymus illustrate the main steps in the process.


grafik

Finding entries that contain placeholders

To aid with migration from KeePass 1.7 or earlier, you may want to find all entries that contain placeholders.

We’re not aware of any specific support for this functionality within KeePass but using a regular expression in the find window should get you pretty close:

You could also search “Other fields” but this will find all entries with Kee configuration data (and probably that of other KeePass plugins too) so if you need to do this, you will most likely need to build some far more complex regular expressions to ensure you don’t have an unmanageable number of false positive matches.

Examples

{TOTP}

Setting up 2FA/MFA code auto-completion for a website typically involves a modification to your entry (per the instructions in the comment below) or the creation of a new entry that’s specific to the TOTP form field.

In many cases (e.g. Google, GitHub, etc.) you will also need to add a whitelist entry to Kee so that it knows that you want this field to be treated in a similar way to a username or password field. This essentially overrides the protections that normally prevent Kee from filling usernames and email addresses into search boxes (for example). See: Documentation about whitelisting and some screehshots specific to configuring a whitelist entry for {TOTP}.

TODO: Better examples, screenshots, etc.


[Solved] Kee enters field reference ID instead of referred information
Field references question
Release notes - KeePassRPC 1.8.0
[Solved] Kee enters field reference ID instead of referred information
UN/PW fields do not populate with v1.80 and v2.39 in FireFox
Whitelisting or blacklisting forms
[Solved] Kee enters field reference ID instead of referred information
New feature : compliancy with 2FA / OTP
#2

So this is why the placeholders entries I have set up to use the credentials from one “master” account entry across several domains (each with a different URL having “single sign on”) stopped working. Kee(Fox) entered the literal field ref {REF:U:xxxx} instead of my username and password after updating to 1.8
Enabling “KeePass placeholders” for the entire database did the trick. But I do not want to disregard the warnings… so what would be the trick to enable the placeholders for individual form fields? (I guess I am just requesting to do the TODO :slight_smile: )

thanks!
Theun


#3

I’ve filled in the TODO for the individual form field configuration section now.


#4

While this could almost certainly use improvement and clarification, for people wanting to start using TOTP auto-entry, some basic instructions I wrote for a KeeTrayTOTP github issue (placeholder may vary for other plugins):

You’ll need to add the TOTP fields to Kee’s id/field listing in the browser plugin’s configuration. Different sites will likely use different field IDs, since TOTP doesn’t seem to have any standardized field name. (If you need that ID, right click the field itself and inspect element to see the code that defined it.) Once you’ve added it there, go to the specific entry you want to enable TOTP entry through in keepass. Kee tab > form fields subtab > Add. Name can be anything (I just name these all TOTP), Name is the field name. ID is the field ID, Value (assuming you haven’t changed KeeTrayTOTP’s default placeholder in settings) is {TOTP}. Make sure you click the Enabled radio for use of placeholders with this entry.


#5

I hope this is the right place for my Question about the Placeholder Warnings.

In which way are placeholders a Problem? (I learned now that there are more placeholders than the references)
In my hole Database i use many ref placeholders. theres no need for other placeholders until now.
So is it a Security Risk to enable the feature for the entire database or can it only be a security risk if i use other placeholders?

My Problem now is that you indicate to Warnings and i didn’t get the point how to prevent security risks… (I didn’t use any plugin that use placeholders and only use the ref placeholders as part of the general placeholders.)

I hope you can help me (and others) to clarify your declaration.
Thanks,
David

Edit 1: Please excuse formal and grammatical mistakes. As a German its not that easy for me to write in english^^


#6

Hi David,

So is it a Security Risk to enable the feature for the entire database

Yes, although it is difficult to quantify the severity of that risk because the exact risk depends upon how each person uses their browser and password database. I have not had time to enumerate a full list of risks but the one that comes to mind is a scenario where you are tricked into saving a password for a website which contains malicious code as part of the form fields that you save into the database.

When you then revisit that same website, different malicious code could extract the contents of any data that is filled by Kee. With placeholders disabled, this data is limited to the data that the website presented to you in the first place (so there is no risk) but if the website has included a placeholder which drags in content from elsewhere in your database, this could then be revealed to the malicious website. I’m not sure if there is even any way that this extraction via placeholders can be achieved without specific knowledge of the target database but I wouldn’t want to say for sure without much more research.

If you are confident that you will not be tricked into saving passwords that you did not need to, and if you trust that new websites you save passwords for are not malicious (or compromised with malware that specifically targets KeePass databases) then there isn’t really any risk.

By ensuring that newly created entries have placeholders disabled, this raises the bar even further so that any malicious website would also have to trick you into reconfiguring the newly created KeePass entry to enable placeholders before this type of attack can succeed. You can never say never, but this would appear to be unlikely enough that there will be easier routes for an attacker to trick someone into revealing secrets.


#7

Hey luckyrat,

thanks for your detailed reply! Now I understand what kind of risk this could be :slight_smile:
in most cases (it could be always) i create my Passwords in KeePass itself and test it then at the website. The only way i use Kee is to put existing credentials from keepass into the Browser (for me that is comfortable enough.)

nevertheless i handle this feature as you recommended and now i know why!

Thanks :slight_smile: