Passkey support

[ThinkChaos]

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.

[keepassium]

Yes, good point, thank you!

[hkaancaliskan]

For tracking: keepassxreboot/keepassxc#1870

[jasperweiss]

See draft pull request for current implementation

[keepassium]

@jasperweiss , @hkaancaliskan , the nudges are well noted, thanks :)

[hkaancaliskan]

@keepassium on keepassxc side passkey support merged :) any progress on keepassium side?

[jasperweiss]

@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.

[Calmquist]

@hkaancaliskan @jasperweiss KeePassXC's passkey release is currently pending this issue: keepassxreboot/keepassxc#10197

[Calmquist]

It appears that KeePassXC moved that issue to 2.8.0 and released 2.7.7.

[nitn3lav]

KeePassXC passkey support is now released and seems to be working great (tested with GithHub and passkey.org in Firefox)

[aliaksandrsen]

Now it would be nice to have passkey support in KeePassium

[keepassium]

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.

[ThinkChaos]

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.

[keepassium]

@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.