-
Notifications
You must be signed in to change notification settings - Fork 98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Passkey support #297
Comments
Yes, good point, thank you! |
For tracking: keepassxreboot/keepassxc#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? |
@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: keepassxreboot/keepassxc#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!
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: |
@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. |
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:
The text was updated successfully, but these errors were encountered: