Add support for default entry layouts

[droidmonkey]

Summary

Following the conversation in #863, this feature focuses on adding a set of default entry templates that are shared amongst the various KeePass compatible applications. Original conversation start: https://github.com/keepassxreboot/keepassxc/issues/863#issuecomment-1161421170

The 'system' for this approach is documentation over code since it will be implemented by multiple parties. Need to clearly document:

• The default templates and their ids
• What data types and key names each template requires
• some form of input validation (try not to be too strict)

Then we can move to allow a 'custom' template spec like I wrote above, if necessary.

Some good default templates that would get us 99% there:

• Secure note (title and notes only)
• Credit Card (title, CC numbers, expiration)
• Entry with email (add an email field to the entry)
• identification (Title, name, person data fields, address, etc)

Example: https://github.com/Kunzisoft/KeePassDX/wiki/Templates

The final table defining this feature is found below: https://github.com/keepassxreboot/keepassxc/issues/8228#issuecomment-1211902266

[strongbox-mark]

Sounds great! I've put together this as a starter/draft, not sure if Github Markdown is the best way to manage this but here goes :)

Layout Name	Custom Data "LayoutType" ID	Field Name(s)	Field Description/Meaning	Simple Regex Validator
Secure Note	SecureNote	Notes	Just display Title and Notes, ignore other fields. Uses the built-in Notes field	.*
Credit Card	CreditCard	CardNumber Expiry CVV	Credit Card No. e.g. 4555 5555 5555 5555 Month & Year (mm/yy or mm/yyyy) The CVV security code	[0-9]+ [0-9]{2}/[0-9]{2,4} [0-9]+
Entry with Email	EntryWithEmail	Email	Display an Email field with this entry.	.*
Identity	Identity	Name Phone AddressLine1 AddressLine2 AddressLine3 ZIP State Country	John Doe 555-5555 12a My Building Abbey Road NW8 9AY London United Kingdom	.* .* .* .* .* .* .* .*

What do you think?

[Hundhausen]

I would add an Secure Question with Question and Answer as Password field, so that I can copy it out easily.

Email should also include Password and Notes for Server Information. Maybe these even separate.

I think some not so important ones but maybe nice to have would be Wifi, Membercards with expiration date and 2FA Backups, but these would probably just be a duplicate with a secure note.

[droidmonkey]

For each default template we need to map certain attributes to our "core attributes" so that the copy/paste, browser, and auto-type integrations work with the template. So for example, Credit Card template would map "Credit Card Number" to the username field and CVV to the password field when interacting with that entry. This is mainly a KeePassXC problem since mobile apps don't have browser integration or auto-type.

This would be implemented in the backend (ie, within Entry.cpp) when a core attribute is requested it would check the template setting first then attempt to map the template to the requested attribute and return the value.

We also need to be cognizant of references and how those will play out. The KeePass standard to way too loose and you have to take into consideration so many contingencies.....

Also, Credit Card should include a field for type of card (eg, Debit, AMEX, MasterCard, Visa, etc). Same with Identity (e.g., License, Passport, Contact, etc) and identity should include an email field and multiple phone fields (mobile, office, home). I would implement that as showing one field initially with a drop arrow that would show "more". This is how most contact apps do it on Android and iOS.

[strongbox-mark]

For each default template we need to map certain attributes to our "core attributes" so that the copy/paste...

Yes, we'd also have to do something similar on the Strongbox side, but as you say, this is implementation specific.

Also, Credit Card should include a field for type of card (eg, Debit, AMEX, MasterCard, Visa, etc).

Yes, I suppose you're right. Do we need an exhaustive list or would the 3 main ones work (AMEX, Visa, Mastercard)?

Same with Identity (e.g., License, Passport, Contact, etc)

Do we have an exhaustive list for this, or is it free form? How would you expect it to work? e.g. do you display a License differently from a Passport, or a Contact? Or is it possible to live without this?

identity should include an email field and multiple phone fields (mobile, office, home)

The way Strongbox works is it allows you to add any fields and will display them on the same view as the normal (Username/Password/URL) fields, so for us this is fairly straightforward, you can add any fields you like, email/phone numbers etc.

Do you think that we need to define particular field names for phone number? e.g. PhoneNumber1...PhoneNumberN

For Email Strongbox almost treats this as a native field (like Username/Password). It always uses the field name "Email", and this can be part of any entry. I know in KeePassXC you don't treat an "Email" field as special, and you have extra fields on a separate tab which I suppose will make your implementation different.

In short, the way I see this feature is to define an entry as a particular type and say that there are the following well known fields (but there could be many more not "well known" fields too). The well known fields are probably:

• Displayed more prominently (e.g. Credit Card Number up front)
• Used to make AutoFill simple (e.g. Credit Card, Expiry, Addresses (from Identity entries))
• Perhaps makes Entry editing/creation more specialized/streamlined

Any extra fields that an entry has are also available, but perhaps not as prominently displayed. So, for me, I don't think we need to be exhaustive, just rather instead be minimal, e.g. we need:

• A minimal set of entry layouts as defined in the table above
• For each layout a minimal set of well known fields

Any extra fields are available but not specially displayed/processed by the App or the AutoFill component. What do you think?

[michaelk83]

Do we need an exhaustive list or would the 3 main ones work (AMEX, Visa, Mastercard)?

You'd need to at least add "Other" for the remaining types. There are functions to determine the type from the CC number, so this can be auto-filled or even left read-only. I don't recall the card type ever being asked on websites, and the title is enough for identification by the user, so IMO a read-only field or indicator would be more than enough. If you want to go the extra mile, you can check that the CC number is a valid (there's some sort of checksum), and display the card type logo next to the number field, or a red X if it's invalid (or just leave the logo blank when the number is invalid or the type is unrecognized).

I would add an Secure Question with Question and Answer as Password field

These are usually related to a particular entry, so it'd be best to allow adding (multiple) security questions to a regular entry, in the same way that you would add multiple phone numbers. But since this is more about regular entries, it may be outside the scope of the custom layouts feature. (This was recently raised in #8274 ).

[droidmonkey]

Yah sorry I took the list of fields as those that are shown. Title would suffice for card type and we can dynamically determine it for image and validation purposes on our side.

Secure question and answer should be recognized as a feature with a defined name on any entry, but not shown by default. Same with multiple phone numbers. This does bleed a little into the custom template discussion, but it is rather trivial to have PhoneNumber-1 and PhoneNumber-2 and support a ui that can add multiple "rows". This is usually accomplished in mobile by having the floating + sign in the bottom right that let's you add to a card or what not.

[strongbox-mark]

You'd need to at least add "Other" for the remaining types. There are functions to determine the type from the CC number, so this can be auto-filled or even left read-only. I don't recall the card type ever being asked on websites, and the title is enough for identification by the user, so IMO a read-only field or indicator would be more than enough.

@droidmonkey - Do you think then that we can eliminate the need for Credit Card Type field? If we can determine simply from the card number?

I would add an Secure Question with Question and Answer as Password field, so that I can copy it out easily.

I'm not sure about this one, as @michaelk83 said above, I think a lot of people just include these as extra fields in an entry rather than an entry by itself. Also as @droidmonkey says, this feels like a separate feature bleeding into another issue.

I think that we need to be minimal here and use a small set of very popular types initially to reach lots of people and get a feel for how well this "convention" system works.

That's my own personal take, I think we should lock the scope down now to the 4 above (Note, Credit Card, Email, Identity). We can always extend later if we like this method/paradigm.

[droidmonkey]

@strongbox-mark I think I answered your questions above your post

[strongbox-mark]

@droidmonkey Sorry, I wasn't a 100% on your answer...

Title would suffice for card type and we can dynamically determine it for image and validation purposes on our side.

When you say "Title would suffice for card type", what do you mean by Title? Like the Title field? What would it look like, e.g. I have an entry with the Title "Mark's Banking Card"? How do you determine card type from that?

Do you mean:

When there is an entry marked as a "CreditCard" entry, we would look at the "CardNumber" field and then be able to automatically determine the type of this card?

That is kind of how I saw this working. Sorry if I'm being dense! 🤦‍♂️

[droidmonkey]

The user can decide to write in the card type in the title field (like I do now) if they choose. No need for a separate field.

Separately, the keepass apps may choose to use the credit card number field to determine the card vendor and show an image for display purposes.

Sorry my brain merged those two sentences as I was typing before.

[strongbox-mark]

Got it, sounds good to me! 😀

@varjolintu - Any thoughts? would the above "convention" work well for you in the AutoFill context? e.g. the 4 "types" (Note, Credit Card, Email, Identity) and their associated "well known" fields?

[varjolintu]

@strongbox-mark Concerning browser integration there's ne exact preference how I'd like this to be done at KeePass/database side. Mapping the data from template to extension shouldn't be that difficult to do.

The credit card type is a tricky one. Now the extension's draft supports it but I haven't tested it. Few sites use it, and they usually excpect a string value for the <select> HTML element. If we discard the card type from the template, that is something users must fill manually when needed. Plus the card holder's name is often needed too.

Using an email template with browser makes me think about how the permissions for that are handled. Every page with a username/email field has access to that template automatically? Or do we have to explicitly ask a permission for that too (meaning.. almost every page would do it)? Maybe some global permission (at least for email template) is needed. Something like "Allow automatic access to this template" etc. With more secure data like Credit Card template, a separate permission is always needed.

[strongbox-mark]

The credit card type is a tricky one. Now the extension's draft supports it but I haven't tested it. Few sites use it, and they usually excpect a string value for the <select> HTML element. If we discard the card type from the template, that is something users must fill manually when needed. Plus the card holder's name is often needed too.

OK, yes, it is a tricky one... However, if you have the card number, I think it should be possible to figure out the type as discussed above by @michaelk83 ... If you have this auto-determined type then could your extension fill in the type for the user?

Plus the card holder's name is often needed too.

Yes and usually the address (billing and shipping) too... But this should then be made available by marking entries as "Identity" type. This includes name, address, postcode fields etc, which could then be automatically filled?

Using an email template with browser makes me think about how the permissions for that are handled. Every page with a username/email field has access to that template automatically? Or do we have to explicitly ask a permission for that too (meaning.. almost every page would do it)? Maybe some global permission (at least for email template) is needed. Something like "Allow automatic access to this template" etc. With more secure data like Credit Card template, a separate permission is always needed.

For sure, I think this is a KeePassXC specific issue, each KeePass client will have to manage this in their own way I think.

[droidmonkey]

I'd imagine the extension can determine the card type/vendor from the card number itself, same as the app. Alternatively we can send that calculation to the extension, it doesn't have to be a static field.

Card holder name might be a good field to add though! Forgot about that.

[varjolintu]

For sure, I think this is a KeePassXC specific issue, each KeePass client will have to manage this in their own way I think.

Yeah. This is just something I have to think all the time :) Using Identity template fields for filling a possible address during Credit Card fill also needs some permission adjustments.

[strongbox-mark]

Card holder name might be a good field to add though! Forgot about that.

Yes, here you go:

Layout Name	Custom Data "LayoutType" ID	Field Names	Field Description/Meaning	Simple Regex Validator
Secure Note	SecureNote	Notes	Just display Title and Notes, ignore other fields. Uses the built-in Notes field	.*
Credit Card	CreditCard	CardNumber CardHolderName Expiry CVV	4555 5555 5555 5555 John Doe Month & Year (mm/yy or mm/yyyy) The CVV security code	[0-9]+ .* [0-9]{2}/[0-9]{2,4} [0-9]+
Entry with Email	EntryWithEmail	Email	Display an Email field with this entry.	.*
Identity	Identity	Name Phone AddressLine1 AddressLine2 AddressLine3 ZIP State Country	John Doe 555-5555 12a My Building Abbey Road NW8 9AY London United Kingdom	.* .* .* .* .* .* .* .*

[michaelk83]

Email is an interesting one:

• It's a very common field in online accounts, maybe common enough to include by default. (This has been requested multiple times.)
• It's sometimes used in addition to a username, but often instead of one.
• If you include a phone number in Identity, it makes sense to include an email as well. Other contact info can be left to custom fields, but almost everyone has an email these days.

I think it should be reconsidered as a standard field in the default entry type, alongside Username and Password, included also in the Identity type, and then Entry with Email can be dropped.

In KPXC, it may be useful to add a radio button to select whether Username or Email should be copied with Copy Username for each entry (and if one of them is empty, default to the other one).

[strongbox-mark]

I think it should be reconsidered as a standard field in the default entry type, alongside Username and Password, included also in the Identity type, and then Entry with Email can be dropped.

I'd love if KeePassXC did this too, Strongbox does it by default, but I think it's the only client doing it unfortunately. It uses the field name "Email" for this, and displays it as a standard "native" field like username/password etc.

then Entry with Email can be dropped.

That would be an excellent bonus.

If you include a phone number in Identity, it makes sense to include an email as well. Other contact info can be left to custom fields, but almost everyone has an email these days.

Makes sense I think... Will add if no objections...

[droidmonkey]

I think in lieu of having a template just for "and also email" I will strongly consider making it a first class feature on the normal entry page. It could even be hidden by default and "added" to an entry if the user wants it by clicking a drop down arrow or button.

[strongbox-mark]

Maybe for now then we could just go with the nice minimal set of three layouts:

Layout Name	Custom Data "LayoutType" ID	Field Names	Field Description/Meaning	Simple Regex Validator
Secure Note	SecureNote	Notes	Just display Title and Notes, ignore other fields. Uses the built-in Notes field	.*
Credit Card	CreditCard	CardNumber CardHolderName Expiry CVV	4555 5555 5555 5555 John Doe Month & Year (mm/yy or mm/yyyy) The CVV security code	[0-9]+ .* [0-9]{2}/[0-9]{2,4} [0-9]+
Identity	Identity	Name Phone Email AddressLine1 AddressLine2 AddressLine3 ZIP State Country	John Doe 555-5555 [email protected] 12a My Building Abbey Road NW8 9AY London United Kingdom	.* .* .* .* .* .* .* .* .*

It'd be cool to see Email added as a "native" field in KeePassXC too 😀

[mainrs]

I am not sure if this needs extra consideration for the templates, but I wanted to bring it up nevertheless. Some of the templates would benefit from custom "actions" a user can perform to share them. For example the Identity type could use the vCard format and QR codes to make it easier to share the data. The same would hold true for custom WiFi templates.

P.S.: Is there any official specification of the backing Keepass 2.x file format (namely KDBX 4)?

[PoisonFrog]

What do you think?

Credit card also needs a PIN field.

[strongbox-mark]

Credit card also needs a PIN field.

Yes, good idea I think... Updated table:

Layout Name	Custom Data "LayoutType" ID	Field Names	Field Description/Meaning	Simple Regex Validator
Secure Note	SecureNote	Notes	Just display Title and Notes, ignore other fields. Uses the built-in Notes field	.*
Credit Card	CreditCard	CardNumber CardHolderName Expiry CVV PIN	4555 5555 5555 5555 John Doe Month & Year (mm/yy or mm/yyyy) The CVV security code The PIN Code	[0-9]+ .* [0-9]{2}/[0-9]{2,4} [0-9]+ [0-9]+
Identity	Identity	Name Phone Email AddressLine1 AddressLine2 AddressLine3 ZIP State Country	John Doe 555-5555 [email protected] 12a My Building Abbey Road NW8 9AY London United Kingdom	.* .* .* .* .* .* .* .* .*

@droidmonkey Do you think we could commit to the Custom Data Attribute Name for this feature, something like KPEX_LayoutType ? What do you think?

[droidmonkey]

I like it!

[mainrs]

@strongbox-mark Would it not make sense to make it possible to have more than a single phone number for an identity? A lot of people have a mobile number and a land line. That logic can be extrapolated to all other fields as well. But I think that phone numbers are a common enough scenario that it would make sense to support them.

[strongbox-mark]

HI @mainrs

This is just the minimal well-known set of fields so that browser extensions and display/input templates can have a minimal set to work with. The idea would be to try to keep these to an absolute minimum.

The way I see it, this doesn't mean you can't add as many fields/phone numbers etc as you like to an entry on top of this, and they would perhaps be displayed as 'Additional Fields' etc.

We're really trying to minimize scope creep here, which as you can see from the above thread has been a key goal, because this could easily get unwieldy. I mean, what about a Fax number? Work number vs Home number? How about social media handles/usernames as part of Identity? A photo or avatar attachment.

The line is a little arbitrary I'll admit, but if you can add additional fields to an Identity entry then you should be covered, and I think there's probably an 80/20 rule here that most people have a single number in most cases, which is what this spec should aim to cover.

That's just my humble opinion though :) Happy to hear others.

[mainrs]

Hey! I didn't read every comment to be honest and missed the statement that the set should be kept minimal! I totally agree with you! Sorry for the extra noise in this issue :)

[strongbox-mark]

Updated table to include the Custom Data attribute name (KPEX_LayoutType) above.

Layout Name	KPEX_LayoutType	Field Names	Field Description/Meaning	Simple Regex Validator
Secure Note	SecureNote	Notes	Just display Title and Notes, ignore other fields. Uses the built-in Notes field	.*
Credit Card	CreditCard	CardNumber CardHolderName Expiry CVV PIN	4555 5555 5555 5555 John Doe Month & Year (mm/yy or mm/yyyy) The CVV security code The PIN Code	[0-9]+ .* [0-9]{2}/[0-9]{2,4} [0-9]+ [0-9]+
Identity	Identity	Name Phone Email AddressLine1 AddressLine2 AddressLine3 ZIP State Country	John Doe 555-5555 [email protected] 12a My Building Abbey Road NW8 9AY London United Kingdom	.* .* .* .* .* .* .* .* .*

[tunbridgep]

I have been looking for template support similar to the Keepass Templates addon (https://github.com/mitchcapper/KPEntryTemplates) for Keepass-compatible programs outside of the original Keepass for a while now.

I was thinking of adding a $300AU bounty to this issue, with $100 going to keepassxc, $100 going to strongbox, and $100 going to Keepass2Android upon completion, as an incentive to get this implemented ASAP across the products that I use.

I don't actually use Strongbox but I can see the strongbox developers have been very integral to getting this implemented judging by the above comments on the issue.

How would I go about doing this in an official capacity?

I think in lieu of having a template just for "and also email" I will strongly consider making it a first class feature on the normal entry page. It could even be hidden by default and "added" to an entry if the user wants it by clicking a drop down arrow or button.

Can we get "and also a PIN" feature too? More and more devices and applications are now using "quick-unlock" style unlocking, where they have a regular normal password and a PIN for easy unlocking afterwards. Ctrl-Shift-C would be a great shortcut to copy the PIN as well.

[gmckeown]

I was going to open a feature request to support credentials that don't fit the standard username/password format, but I think this covers what I'm thinking of. Specifically for me, this arises because I'm working with the MS Graph API a lot currently, so I'm storing quite a few OAuth2 "credentials". The key information items for these entries are the Tenant ID, the Client ID and the Client Secret.

I am using Advanced -> Additional Attributes to store them currently, but it would be great to be able to create a specific OAuth2 Client Credentials Grant entry that had these fields immediately visible (not hidden in a separate tab as now) and would treat the Client Secret like a password.

Based on what I've read above, I think this fits within the proposal in this feature request?