Passkeys don't require it, but relying-parties may: https://github.com/keepassxreboot/keepassxc/issues/10407#iss... If enough RPs ban clients that let users manage their own data in the name of "security," then it is effectively required by passkeys. The passkey spec could have been written to be resilient against this type of abuse, but instead this abuse is explicitly considered a feature of the spec.
In Things I learnt about passkeys when building passkeybotkeepassxreboot
keepassxc
C++2017–2026
keepassxreboot / keepassxc
keepassxc
KeePassXC is a cross-platform community-driven port of the Windows application “KeePass Password Safe”.
147Distinct people
211Mentions
2Explicit recommenders
30KGitHub stars
What to know before exploring
What it is
KeePassXC is a cross-platform community-driven port of the Windows application “KeePass Password Safe”.
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
I love that the "big guys" get to support syncing passkeys between devices... but others don't (wasn't it KeePas who had issues where they were threatened by being blocked from…
FireBeyond used a recommendation phrase. 2 indexed comments match. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- keepassx/keepassx · linked in 2 of the same discussions
- kunzisoft/keepassdx · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 9:28:18 AM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year211 dated mentions
Observed mentions: 2017-01-19 23:33:12 UTC to 2026-10-14 23:38:36 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 19 | 1 | 18 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 10 | 0 | 10 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 7 | 1 | 6 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 24 | 2 | 22 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 47 | 3 | 44 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 45 | 0 | 45 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 37 | 0 | 37 |
From the project README
An excerpt from the repository, fetched Nov 14, 2026.
Read the project’s introduction
KeePassXC
KeePassXC is a modern, secure, and open-source password manager that stores and manages your most sensitive information. You can run KeePassXC on Windows, macOS, and Linux systems. KeePassXC is for people with extremely high demands of secure personal data management. It saves many different types of information, such as usernames, passwords, URLs, attachments, and notes in an offline, encrypted file that can be stored in any location, including private and public cloud solutions. For easy identification and management, user-defined titles and icons can be specified for entries. In addition, entries are sorted into customizable groups. An integrated search function allows you to use advanced patterns to easily find any entry in your database. A customizable, fast, and easy-to-use password generator utility allows you to create passwords with any combination of characters or easy to remember passphrases.
Quick Start
The QuickStart Guide gets you started using KeePassXC on your Windows, macOS, or Linux computer using pre-compiled binaries from the downloads page. Additionally, individual Linux distributions may ship their own versions, so please check your distribution's package list to see if KeePassXC is available. Detailed documentation is available in the User Guide.
Features List
KeePassXC has numerous features for novice and power users alike. Our goal is to create an application that can be used by anyone while still offering advanced features to those that need them.
Core Features
Create, open, and save databases in the KDBX format (KeePass-compatible with KDBX4 and KDBX3)
All information is encrypted at rest and never exposed outside the program
Store sensitive information in entries that are organized by groups
Password generator
Search for entries
TOTP storage and generation
YubiKey/OnlyKey challenge-response support
Auto-Type passwords into applications
Browser integration with Google Chrome, Mozilla Firefox, Microsoft Edge, Chromium, Vivaldi, Brave, and Tor-Browser
Support for passkeys using the browser integration
Entry icon download
Import databases from CSV, 1Password, Bitwarden, Proton Pass, and KeePass1 formats
Advanced
Database reports (password health, HIBP, and statistics)
Database export to CSV, XML, and HTML formats
TOTP storage and generation
Field references between entries
File attachments and custom attributes
Entry history and data restoration
Command line interface (keepassxc-cli)
SSH Agent integration
FreeDesktop.org Secret Service (replace Gnome keyring, etc.)
Additional encryption choices: Twofish and ChaCha20
For a full list of changes, read the CHANGELOG document.
For a full list of keyboard shortcuts, see KeyboardShortcuts.adoc
Building KeePassXC
Detailed instructions are available in the Build and Install page and in the Wiki.
Contributing
We are always looking for suggestions on how to improve KeePassXC. If you find any bugs or have an idea for a new feature, please let us know by opening a report in the issue tracker on GitHub, or join us on Matrix community channel or Matrix development channel, or on IRC in Libera.Chat channels #keepassxc and #keepassxc-dev.
You may directly contribute your own code by submitting a pull request. Please read the CONTRIBUTING document for further information.
Contributors are required to adhere to the project's Code of Conduct.
Generative AI
Generative AI is fast becoming a first-party feature in most development environments, including GitHub itself. If the majority of a code submission is made using Generative AI (e.g., agent-based or vibe coding) then we will document that in the pull request. All code submissions go through a rigorous review process regardless of the development workflow or submitter.
License
KeePassXC code is licensed under GPL-2 or GPL-3. Additional licensing for third-party files is detailed in COPYING.
Read the full README on GitHubWhat Hacker News says
45 sourcesThe passkey spec authors think websites should be able to ban clients which allow users to manage their own data[1,2]. It makes me really hesitant to adopt passkeys if my client could get banned because it's open source and lets me control my client how I want to. It appears to be more useful for vendor lock-in than anything else[3]. A shame, since it could've been a cool tech if they had built it to be resilient to this kind of abuse, but it's clear they think vendor lock-in is actually a core feature of the protocol.
[1] Spec author quote: "To be very honest here, you risk having KeePassXC blocked by relying parties." https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
[2] https://www.smokingonabike.com/2025/01/04/passkey-marketing-...
[3] https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-shatt...
In Things I learnt about passkeys when building passkeybot> Care to cite this statement?
Yes, literally from you: "Passkeys should never be allowed to be exported in clear text." https://github.com/keepassxreboot/keepassxc/issues/10407 Also, "You absolutely should be preventing users from being able to copy a private key!"
> You can use any credential manager you choose. You don't have to use Apple Passwords / iCloud Keychain.
But I want to use Apple Passwords. And I do use Apple Passwords for passwords.
What you're saying, in contrast, is that in order to use passkeys, I would be forced to change how I currently store credentials, which is not in iCloud. "You can choose any method you like, except the one you currently like" is a pernicious interpretation of "choice".
In Yep, Passkeys Still Have ProblemsQuoting your comments on github [0]
>> There is no passkey certification process
> This is currently being defined and is almost complete.
>> no signed stamp of approval from on high
> see above. Once certification and attestation goes live, there will be a minimum functional and security bar for providers.
Will I always be able to use any credential manager of my choice? Any naturally also includes software that I might have written myself. And would you be in support of an ecosystem where RPs might block my implementation based on my AAGUID?
[0] https://github.com/keepassxreboot/keepassxc/issues/10406#iss...
In Yep, Passkeys Still Have ProblemsPasskeys relying parties can block providers. Tim Cappalli threatened the KeypassXC developers so.[1] The restrictions demanded now do not restrict user freedom significantly arguably. But the incentives and capabilities are clear.
[1] https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
In Yep, Passkeys Still Have ProblemsVendor lock-in a serious concern. Just reading through this KeePass issue again and seeing how much pressure the industry is trying to exert to prevent the users from being able to export their own private keys should be concerning. I come back to this discussion every time I see someone arguing in favor of passkey adoption.
>The unfortunate piece is that your product choices can have both positive and negative impacts on the ecosystem as a whole. I've already heard rumblings that KeepassXC is likely to be featured in a few industry presentations that highlight security challenges with passkey providers
https://github.com/keepassxreboot/keepassxc/issues/10407
In Yep, Passkeys Still Have ProblemsQT6 port is still not ready https://github.com/keepassxreboot/keepassxc/pull/11651
The main issue for me with keepassxc is the broken autotype on wayland
In KDE Plasma 6.8 Will Go Wayland-Exclusive in Dropping X11 Session SupportKeepassXC (a must-have application and dealbreaker) is still broken on Wayland.
The recommended "solution" is to edit the .desktop file to resemble the following:
QT_QPA_PLATFORM=wayland ECORE_EVAS_ENGINE=wayland_egl ELM_ENGINE=wayland_egl SDL_VIDEODRIVER=wayland _JAVA_AWT_WM_NONREPARENTING=1 keepassxc
https://github.com/keepassxreboot/keepassxc/issues/2973
In KDE Plasma 6.8 Will Go Wayland-Exclusive in Dropping X11 Session SupportBeing locked into a set of a handful of vendors who offer "secure" sync (of course, this is not a true PKI and actual key material is being synced, meaning it's only as secure as the syncing protocol and your authentication to it).
Authenticator implementations who allow exports outside of the vendor cartel are threatened to be blacklisted: https://github.com/keepassxreboot/keepassxc/issues/10407
> My primary hardware key can be from a completely different vendor than the backup one, so I don't quite buy the conspiracy angle.
The fundamental flaw is that enrolling an authenticator requires it to be present, making a backup strategy much less resilient as it means your secondary device needs to be constantly present and thus exposed to the same local/environmental risks the primary one is (theft/fire/faulty USB port that fries everything p
Read the rest
lugged in and you only realize after nuking both your keys). It makes an offline backup scenario like with SSH (where you copy a public key and otherwise leave the authenticator out of reach in a safe place) impossible.
Making it hard/impractical to maintain a reliable backup yourself sure makes those proprietary sync-based services attractive, which also doubles as reducing security since key material is being synced and can potentially be extracted (impossible with a true HSM + PKI implementation).
> preventing anyone from creating "paired" hardware authenticators
Don't certain types of keys involve writing something to the authenticator, fundamentally preventing this (as the backup authenticator won't get this written value)?
> cabal
It doesn't have to be explicit coordinated action like intentionally wanting to prevent people from self-managing passkeys (in fact any hint of it being intentional would be a liability in a potential anti-trust situation, so that's a big no-no); it can be done by simply omitting this scenario, by accident or for "security" purposes, or deprioritizing it to hell. In fact the Credential Migration spec is still a draft and appears quite recent, despite passkeys being heavily promoted for a while: https://fidoalliance.org/specs/cx/cxp-v1.0-wd-20241003.html - you'd think that such as basic feature would be sorted before the push to switch to passkeys no?
In fact you see this exact strategy playing out: https://github.com/keepassxreboot/keepassxc/issues/11363#iss...
> For the initial delivery of Credential Exchange, we focused on the most wide use case [emphasis mine]
"Initial" delivery focuses on the most widespread use-case (how convenient it also happens to be the most corporation-friendly use-case), with everything else coming "later", meaning never. I'm sure it'll rot in some Jira backlog as a liability shield so they can promise they did plan for it and just never got around to it, but everyone understands it will never actually get implemented.
You have never been skilled at being considerate:
https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
In Hard Rust requirements from May onwardThis is the same maintainer who broke KeePass on Debian and then flipped off everyone in the thread. Someone needs to pull him aside and let him know the world does not revolve around him and the problems he chooses to manufacture to justify his paycheck.
https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
In Hard Rust requirements from May onwardIf anyone has a problem with the language used in the email, I would remind you that this is the same person who is maintainer for debian's keepassxc packages.
Here's a thread of them insulting upstream developers & users of the Debian packages.
https://github.com/keepassxreboot/keepassxc/issues/10725
In Hard Rust requirements from May onwardWebsites can choose to not accept your passkey manager ("accept" not "block" since it will obviously be enforced as whitelist). What could possibly go wrong ? If only there was a similar example with an existing system like TOTP and a big company like Steam..........
Link unrelated https://github.com/keepassxreboot/keepassxc/discussions/9591
Eventually get debanked and go live in the woods ig
In Passkeys: They're not perfect but they're getting betterI hadn't heard this story. Source: https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
In Passkeys: They're not perfect but they're getting better> I read about Passkey comittee being against open source passkey managers during start of this year (can't reference it, sorry) but with open source password/key managers already supporting passkeys, i don't think it turned out to be true.
Here's an Okta employee threatening to use the attestation (anti)feature of passkeys to block open-source implementations, because they allow you to export your passkeys: https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
In Passkeys: They're not perfect but they're getting betterShowing the 15 most recent of 45 sources. Enable JavaScript to search and browse every indexed mention.