KeePassium
KeePassium copied to clipboard
keepassium
Passkey support
Keepass[XC] don't support this yet, but I wanted to open an issue here to track it anyways as progress could be made even before the others apps do, for instance by storing passkeys in custom entry fields.
As per this blog post, iOS and macOS have introduced a passkey provider API already:
Apple has also publicly revealed their own passkey provider API in the form of additional functionality added to the existing ASCredentialProviderViewController, “a view controller that a password manager app uses to extend Password AutoFill:”
prepareInterface(forPasskeyRegistration:)(link)prepareInterfaceToProvideCredential(for:)(link)provideCredentialWithoutUserInteraction(for:)(link)Documentation for these methods are light on details so that’s about all I could make sense of. These new instance methods say they’ll become available for third-party passkey providers to use in iOS 17, iPadOS 17, and macOS 14.
For tracking: https://github.com/keepassxreboot/keepassxc/issues/1870
@keepassium on keepassxc side passkey support merged :) any progress on keepassium side?
@keepassium on keepassxc side passkey support merged :) any progress on keepassium side?
@hkaancaliskan It's not released yet. Some breaking changes might still be made so it's probably a good idea for KeePassium to wait for KeePassXC to release their final implementation.
@hkaancaliskan @jasperweiss KeePassXC's passkey release is currently pending this issue: https://github.com/keepassxreboot/keepassxc/issues/10197
KeePassXC passkey support is now released and seems to be working great (tested with GithHub and passkey.org in Firefox)
Perhaps I should explain why this takes so long.
- Passkeys can be created and used only via AutoFill API. This is different from passwords, which can be created in the main app and then just used in AutoFill. So we need to have the database editable in AutoFill.
- AutoFill process has very limited memory allowance — only around 120 MB for everything: the code, libraries and the database. (This is a system-imposed constraint.)
- KeePassium core was written in early 2018, before the introduction of AutoFill in iOS 12. Memory consumption was not a concern at the time, so the app loads the database in a rather memory-hungry way. It loads the whole encrypted file, then decrypts the full thing in memory, then processes the underlying XML content using a DOM parser (which keeps the whole thing — you guessed it — in memory).
- This works fine in the main app, but AutoFill can barely load a modest 3-5 MB database before hitting the 120 MB threshold and getting terminated by the system. Generating and encrypting an updated version of the database will guarantee a crash, it just won't fit.
In order to make database editable in AutoFill, we need to rewrite database processing to use small data chunks. This should drastically reduce the memory consumption of AutoFill. However, this requires rewriting the DB processing code from the ground up — which is quite a hefty task.
Albeit slowly, we are walking the path. A few days ago I finished optimization of the XML parsing process, it will make AutoFill a bit leaner already in the next update. But we also need to switch to chunked encryption/decryption. This is happening right about now, but will take a couple of months to complete (unless something else requires urgent firefightning…) Might also have to offload entry attachments to disk temporarily, since attachments are the worst offenders memory-wise.
Once the ground work is done, it will unlock entry editing in AutoFill (#87). And then there will be passkeys.
Thanks for the detailed update and working on this, sounds like a lot of work!
Might also have to offload entry attachments to disk temporarily, since attachments are the worst offenders memory-wise.
Just an idea that might make this doable with less complexity, obviously I'm not familiar with any of the details so I don't really know if it would be practical or even simpler, but here it goes:
Maybe you could save the position+length in the stream where the attachment (or whatever untouched data) is. Then when saving the modified DB, also re-create/reset the read stream and seek to get the untouched data back.
I'm assuming it'd be simpler since it'll avoid needing code to juggle extra files, and could re-use the necessary reading code.
@ThinkChaos , thanks! Yes, this is also an option. I'm a bit concerned about performance overheads, though, since skipping to a position of a multilayer (cypher + gzip + another cypher) stream implies doing all the work nevertheless. And for the earlier kdbx3 format getting to an attachment is really a piece of cake. Really thick multi-layer cake: external cypher + gzip + xml + base64 + inner cypher + gzip again :)
I've been thinking to just save chunks of attachments when loading the database. Each chunk padded with a random-length garbage to obscure its size, and encrypted with a random key, unique for each chunk. When the time comes to reassemble and save the database, it would be just reading and decrypting the cached chunks. And if the device is compromised and someone gets to the cached chunks, these would be just piecemeal binary blobs with random names and sizes.
Passkeys can be created and used only via AutoFill API. This is different from passwords, which can be created in the main app and then just used in AutoFill. So we need to have the database editable in AutoFill.
I don't know how much work it would be, or if it would be worth it, to at least temporarily only allow using already existing passkeys and not allow creating them?
I don't know how much work it would be, or if it would be worth it, to at least temporarily only allow using already existing passkeys and not allow creating them?
This was the case for TOTPs for a while :) But passkey implementation seems far from trivial, so I'd rather deep-dive into it only once. Otherwise there will be much time left on context switching.
This is happening right about now, but will take a couple of months to complete (unless something else requires urgent firefightning…)
Hey. Is there any ETA on this? Just wondering about the progress because I'm really looking forward to it.
@unoukujou , just to be clear, that "couple of months" referred to one of the building blocks (chunked encryption/decryption), rather than the whole feature.
As for ETAs, I'd rather not share any timelines until everything is implemented and ready for release. We are not at that stage yet.