Open ThinkChaos opened 1 year ago
Yes, good point, thank you!
For tracking: https://github.com/keepassxreboot/keepassxc/issues/1870
See draft pull request for current implementation
@jasperweiss , @hkaancaliskan , the nudges are well noted, thanks :)
@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
It appears that KeePassXC moved that issue to 2.8.0 and released 2.7.7.
KeePassXC passkey support is now released and seems to be working great (tested with GithHub and passkey.org in Firefox)
Now it would be nice to have passkey support in KeePassium
Perhaps I should explain why this takes so long.
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.
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: