Leveraging KeepassXC

[dev4openid]

I have used KeepassXC for quite a few years now. It has been a fantastic tool. Thank you to all that have built this!
This has been on all platforms Linux, MacOs and Windoze.

Scenario:
Currently, whenever I wish to create an account for a website, I have to go through the motions of the sign-up process.
The snag is that I have to create the account manually in KeepassXC and then add the additional account touches to the KeepassXC version, such as 2FA/TOTP or passkey. Note, I do use the KeepassXC add-on in my browser, however, it does not pick up the context of account etc.

This is a barrier to adoption. I have learnt this in the effort it takes to get users around me to adopt. Users rightfully are pretty lazy and do not want to go through the “duplication” of creating the account, as described in the scenario.

My suggestion is as follows:
I train the users to NOT launch the URL path in the browser (especially if the user has an account, e.g. Gmail). I train them to go to KeepassXC and launch it from there. This way, more often, the login uses the passkey version of the account vs. the TOTP path.

Perhaps is what is needed is to position KeepassXC as a URL launcher in the browser. In this manner, the user can easily launch the KeepassXC URL launcher from the browser. This will have to be facilitated in the add-on.

It must:
— trigger the KeepassXC password, if the utility is locked (the API already can support the lock/unlock)
— provide a “fuzzy” search for the “accounts” — search for Gmail and get a list of Gmail accounts (The structure should replicate the password repository breakdown/structure). It could have a “hot-list” of frequently used accounts as well?
— When singing up for a new website; facilitate account fields detection as and when the user is creating the new account on the website. This allows the creation of secure passwords, via KeepassXC, for that website account.

I appreciate that the requirement would mean a closer relationship with the KeepassXC add-on and the utility KeepassXC.

Passkeys are not ubiquitous presently, and this will remain the case for many years to come.

By having a closer relationship between the KeepassXC and add-on, as and when the user creates a new account; the add-on will have the possibility to be able to provide a passkey for that account when the website prompts for it.
Manually, when creating a passkey, KeypassXC provides the capture already and this can be expanded to then enable the above point.

My point in simple terms is that KeypassXC is not only a password manager, but is also a URL launcher.

On reflection, I accept that the sign-up process is inconsistent across many security “low-grade” websites and there is no adoption of standards — however, the major players such as Google/Amazon/MS/Apple would welcome this approach as it will drive further adoption of passkeys. The point is creating further pressure on the security “low-grade” to adopt a more common approach.
Perhaps the above could be progressed on a roadmap basis?

[dev4openid]

As a follow on - I have used the autotype feature - which is great in itself, but is not necessarily a great user experience (especially for adoption by the User community). I take this as a start on the road as a potential launcher with secure passwords. A way to go then

Surprised that there are no comments from the larger community. Maybe this is a dud?

[droidmonkey]

Your specific issue is incredibly rare. Probably 0.005% of websites and services requiring appending a rotating value to a password.