Placeholder handling

[luckyrat]

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

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.

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.

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.

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.

[Theun]

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 )

thanks!
Theun

[luckyrat]

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

[Sanaki]

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.

[Ingrimmsch]

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^^

[luckyrat]

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.

[Ingrimmsch]

Hey luckyrat,

thanks for your detailed reply! Now I understand what kind of risk this could be
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

[vertigo]

I just updated Kee to the latest version (1.8.0) and have run into this, as a site I regularly log in to suddenly was putting the reference info (e.g. {REF:U@I:CB9B8E47EE20FA42A5F5C41A07B3B578}) into the login form fields instead of the referenced data (actual username/password). I’ve enabled it on that entry as described above, but the behavior persists. I thought maybe it was because the “Name” and “Id” fields in the Kee tab were blank (not sure why, or if it even matters, but the example here has them filled out), so I tried putting the info there and it still didn’t work (and if it did, it would be a pain to have to manually do that on each entry using references). So I have two questions: 1) how do I get this to work, and 2) since placeholders have been supported for a while, why all of a sudden has the behavior been changed to lock their use down? I understand the reasoning and importance for doing so, it just seems strange to suddenly do it now and not have done it before, unless the potential security issues involved only recently came to your attention.

[Ruby_Goody]

I thought I added this here for others running into placeholders problems on advanced fields.
Been looking for an hour to find this solution, including this forum and other pages from Kee, until I finally found it myself, from deriving it from auto-fill functionality from KeePass.
So, to put clearly:

If you want to autofill a value from an Advanced tab field from KeePass with Field Name xyz, you need to fill in this string into the Kee Form Field value {S:xyz}.

Hope this helps someone

[cevni]

If you want to autofill a value from an Advanced tab field from KeePass with Field Name xyz, you need to fill in this string into the Kee Form Field value {S:xyz}.

also had to disable default KeePass username placeholder to make it work

[air_ben]

Just to expand on what others have mentioned, and hopefully provide it all in a single block of details (it’s quite an arduous process to set up for multiple entries, I must say!):

1. You have your account entry in KeePass.
   Username: superman@krypton.org
   Password: Welcome1 is a *totally* suitable password!.

2. This entry in the keepass database might have the UID field of ‘FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF’ for example… (look in the properties tab!)

3. You then have entries for each of your duplicate portals that rely on the credentials:

• https://dev.krytpon.org/login,
• https://test.krypton.org/loginUAT,
• https://krypton.org.

In each of these portals, you would have the username string:
{REF:U@I:FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF}, the password string {REF:P@I:FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF}.
These are your KeePass placeholders.

Then to expose these to Kee
You need to edit each entry and change to the Kee, Form fields sub-tab, you would configure it as per the two images from above, so that the Kee plugin can see ‘through’ to the actual ‘superman’ entry (steps 1…5):

(and the image about enabling the placeholder - my account won’t allow me to insert 2 images in a post sigh…). Yes - totally use username/loginusername and password/loginpassword in step #5 - and don’t forget to ‘enable’ the placeholder!

From there, you ought to be able to have the creds pass through to each of Supermans websites via the Kee plugin. Personally, I’ve been paranoid and saved the database and reloaded the URLs before testing it, but that’s just me being perdanitc.

If you see the {REF… string - you know it’s not quite working. Hope that helps connect the dots for others, honestly, it’s the 3rd time I’ve tried to set this up!

[SecretKeeper]

Please replace the german screenshots with english ones. I have no idea which window is shown there.

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.

This can be easily mitigated by introducing an option that would allow a user to enter allowed placeholders, and that list would by default list only “REF”. This way the attack that you’ve described in a later post, that saving an entry with malicious placeholders will allow extracting data upon revisiting a site would become infeasible just like any other attack. And if a user decides to enter any other placeholder into that list, they will accept the risk they’re explicitly taking.

[caspadan]

I am not getting this right. I’ve done it before for other referenced entires and it works, but today I’m trying to get it to work for a referenced entry but am not getting anywhere.
Every time i enable placeholders in an entry for the username and password, the username type is changed automatically to radio. And if i go in to edit it, i cannot change it back to username as username is not an option to choose. I remember this happening previously, but I don’t remember how I got around it.
Checking my other entries that contain placeholders and are setup, password and username is enabled, while name and id remains blank for both. Is this correct? The entries work though.
But now, i cannot for the life of me get username to remain of type username and not become type radio.

[caspadan]

I managed to copy the KPRPC JSON custom field from an entry with working placeholders enabled, and copied it to the entry i’m trying to enable placeholders on. This way enabled the username placeholder without it changing to type “radio”. Although, this is just a workaround i could do since I had previous entries with placeholders working. Still not sure what is happening when I try enable it through the Kee tab in the edit entry dialog. Created a new test database and same thing, username type changes from type “username” to “radio”. Either it’s a bug or I’m not sure what I’m doing.

[thethinker]

Hi @luckyrat , do you may have any information and documentation about how to use the new DOM selector and DOM type? I visit some sites on which I am not able to fill the password (or certain other fields) with the typical name/id because they use some sort of randomizer. I was hoping with this new feature I can handle that part