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.

[Jerroder]

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?

[keepassium]

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.

[unoukujou]

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.

[keepassium]

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

[danielwagn3r]

Would be great to have passkey support in AutoFill line Apples and Microsofts Tool already offer.

[FrankUlbrich]

I am very curious about this feature. Thanks lot for all the time. I decided to buy the software license.

[fizmhd]

Hi Team, any update ??
On passkey

[infirms]

Looking forward for passkeys

[keepassium]

Look what's coming in the next beta :)
Just need to make sure changes are preserved even if AutoFill crashes while saving…

passkey-creation.mp4

[keepassium]

Just uploaded 1.54.156 to TestFlight (beta testing) and a macOS build here.

It covers the main functionality: creating passkeys and using them to sign in. Some pieces are still work-in-progress, though. Specifically, recovering when AutoFill runs out of memory and crashes while saving. (This won't corrupt the DB, just no passkey would not be created.)

Early feedback is welcome!

[jasperweiss]

Great to see this in KeePassium! I have just downloaded the TestFlight build. I found a couple of issues:

• The "Create a Passkey?" prompt seems to be covered by the keyboard on newly created databases sometimes (see debug.mp4). It seems like the passkey prompt is supposed to dismiss the keyboard/search but sometimes the keyboard opens a little later than the passkey prompt. So they appear to be racing each other.
• At the bottom of the entity list it says conversation entity: ?
• When signing in with a passkey, the autofill dialog filters out entities that don't contain a passkey but if there are no entities with a passkey at all in the selected database, all entities are shown as an option and tapping on them exits the autofill dialog without doing anything (see debug2.mp4)
• Perhaps not an issue per se, but it would be nice if you could select the folder and edit other attributes of the entity before saving (as if creating a new entity within the app itself) or you end up with a root folder full of iconless entities with the domain as their name (as is the case with KeePassXC unfortunately)

debug.mp4

debug2.mp4

[keepassium]

@jasperweiss , thank you! I think I've fixed most of these for the upcoming beta.

At the bottom of the entity list it says conversation entity: ?

In English it says Caller ID: ? (that is, the identify of the page or app that asked for auto-filling). I have fixed the question mark, but is "Gespreksidentiteit" as suitable translation?

Perhaps not an issue per se, but it would be nice if you could select the folder and edit other attributes of the entity before saving (as if creating a new entity within the app itself) or you end up with a root folder full of iconless entities with the domain as their name (as is the case with KeePassXC unfortunately)

Yes, the current thing is really minimalistic. Unfortunately, this is a balancing act. Too many nice-to-haves and we end up with a full-blown entry editor, when most people might only need a "Save" button. So this will evolve based on feedback, I just want to see which parameters really need to be customizable immediately in AutoFill, and which can be left for later. (For instance, favicon downloading is likely in the latter camp.)

[jasperweiss]

In English it says Caller ID: ? (that is, the identify of the page or app that asked for auto-filling). I have fixed the question mark, but is "Gespreksidentiteit" as suitable translation?

It seems a bit out of place. I would read that as my identity for a given conversation. The other translations seem to translate "Caller ID" quite literally. The German and French translations are "Anruf-ID" and "ID D'appel" respectively, which you'd really use in the context of a telephone conversation, I think. The Spanish translation "Identificación de la persona que llama" quite literally means "identification of the person who is calling".

In the context of "Relying party" (which I think is the phrasing used in the spec), "Vertrouwende partij" seems appropriate in Dutch. "Vertrauende Partei" in German or "Partie de confiance" in French. These all roughly mean "Trusting party" but I can only really comment on the Dutch translation.

If Caller ID is the desired phrasing, "Aanvrager-ID" would work in Dutch. (Literally "applicant/requester ID")

[keepassium]

@jasperweiss , wow, quite a bedlam there… Clearly, "Caller ID" was not the best choice, if it leads to such diverse interpretations. I'll replace it with a more generic "Context", it should work in all the possible scenarios:

• Context: https://accounts.example.com/somepage
• Context: passkeys.io
• Context: com.company.appName

[jasperweiss]

Looks like the new build is working pretty well on the phone.
It seems creating a passkey using Chrome on a desktop (MacBook) by scanning the QR code does not work. I get this error on Github and Proton in the browser console

(So this is by using the "Use phone, tablet or security key" option in Chrome. Then scanning the code using the phone and creating a passkey in KeePassium)

[Jerroder]

With the latest build (1.54 (157)) I tried creating a Passkey for Paypal but the button to add it to an existing entry was greyed out

I created a new entry, but couldn't save the updated database

so I just clicked "saved as..." in order to create a new one, it did and came back to this screen and I couldn't do anything. The new entry is in the new database, but when I go back to Paypal after this, it said it couldn't create a Passkey.

just to try, I tried to delete the newly created database, but couldn't

So the quick fill has permissions to create a database, but not to modify or delete an existing one?

[keepassium]

It seems creating a passkey using Chrome on a desktop (MacBook) by scanning the QR code does not work.

@jasperweiss , thanks, I never thought of testing this and indeed it does not work via QR codes.After an hour of testing, I did not find any obvious problems, so this will need a deeper dive. (Given the season, probably already in January.)

[keepassium]

@Jerroder, thank you for the detailed feedback. It seems you managed to encounter everything that could possibly go wrong :) Some of this is kind of expected, just not all at once.

the button to add it to an existing entry was greyed out

This is by design at the moment. Just checking how many people need that function (strongly enough to ask about it). A side effect of no-analytics-collected policy.

so I just clicked "saved as..." in order to create a new one, it did and came back to this screen and I couldn't do anything. The new entry is in the new database, but when I go back to Paypal after this, it said it couldn't create a Passkey.

Unfortunately, it could not do much better under the circumstances:

• Passkey got saved to another database, so it did not appear in the current one.
• When you selected the passkey in another database, AutoFill responded to system with an "existing passkey selected" mode. But the system expected a "passkey created" kind of response. (They have different formats.)
• So PayPal rightfully said that passkey creation failed.

I created a new entry, but couldn't save the updated database
So the quick fill has permissions to create a database, but not to modify or delete an existing one?

These are the unexpected parts, and I suspect they are related. Is the original database stored in "On My iPhone / KeePassium"? Was the new one saved there as well?

[Jerroder]

Just #297 (comment) how many people need that function (strongly enough to ask about it).

It is a nice-to-have feature indeed but not must-have for me. Depending on the entry I'll probably need to go in there manually to rename or remove some older TOTP methods or sormthing.

AutoFill responded to system with an "existing passkey selected" mode. But the system expected a "passkey created" kind of response. (They have different formats.)
So PayPal rightfully said that passkey creation failed.

That's what I thought, it makes sense.

Is the original database stored in "On My iPhone / KeePassium"? Was the new one saved there as well?

Yes and yes.

[keepassium]

Is the original database stored in "On My iPhone / KeePassium"? Was the new one saved there as well?

Yes and yes.

Good! Then it looks like bad luck mixed with a bug :)

Due to some technical quirks, AutoFill cannot access KeePassium's folder easily. If you restart the device and open AutoFill before launching the main KeePassium app, AutoFill would get a "permission denied" from the system. As a plan-B, AutoFill loads an internal backup file instead — in read-only mode. (It should also show a message that the database is unreachable.)

And then there is a bug. Since AutoFill is very new to this whole "database editing" thing, it does not check whether the file is read-only — it just tries to write it. And fails, because the database is actually unreachable.

Long story short, there should have been a "Database is read only" message instead of passkey creation dialog. We'll get that fixed. Thanks again!

[Sereby88]

@keepassium
„Is the original database stored in "On My iPhone / KeePassium"? “
I use it from a WebDAV share and read / write to it from multiple devices. Ist this planned?

and yes, adding passkeys to an existing entry would be my wish, too

[keepassium]

@Sereby88 , noted. Regarding WebDAV: already done.

[Sereby88]

@keepassium
The WebDAV part was a linked question to passkeys support. You wrote about local files and problems that may occur if not locally stored.

I would use the database from a WebDAV share (like now) and would like to use Passkeys and add them to existing entries to the database on the share. Hopefully this will work without having to change to local database per device

I hope you understand what I mean :-)

[keepassium]

@Sereby88 , the problem was because of a locally stored DB :) Remote files should work even better in this regard.