Skip to content
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

Improve NFC hardware key UX #11093

Open
StarGate01 opened this issue Jul 22, 2024 · 6 comments
Open

Improve NFC hardware key UX #11093

StarGate01 opened this issue Jul 22, 2024 · 6 comments

Comments

@StarGate01
Copy link
Contributor

Summary

When (re-)opening a database using a NFC key via PC/SC, the workflow to select the hardware key is somewhat cumbersome, especially with tokens which require a hand to hold to the reader. Ideally, the last used NFC token would be cached and the user be prompted to present it, without first having to scan for tokens.

I would appreciate a discussion how this process could be improved.

@droidmonkey
Copy link
Member

droidmonkey commented Jul 22, 2024

The last used is cached. As long as the token is presented on refresh, it'll be selected. Honestly, I can't help with the physical nature of NFC. It's definitely not the preferred method due to how challenge response works.

@StarGate01
Copy link
Contributor Author

StarGate01 commented Jul 22, 2024

I encountered the caching - it works great when the database is already opened and just asking for a tap when changes are saved. I think my main UX issue boils down to having to click "refresh" instead of the PCSC cards showing up when presented, just like the USB ones do. That could be cached as well, just list the last used PC/SC token regardless of it being connected or not - if it is not connected, prompt the user for a tap.

I am aware that presence detection is a bit different in PC/SC than just handling a USB event. There is the SCardGetStatusChange API, which blocks the calling thread until a smart card (un/) plug status event occurs. We could run that in a separate watcher thread instead of having the user click rescan.

I'd be willing to draft a PR, is there a preferred way how threads are handled in KeePassXC? How are USB events handled?

@droidmonkey
Copy link
Member

I'm not sure how prevelant NFC use is out there. I much prefer the "always show if NFC cache" option instead of continuous scanning.

@StarGate01
Copy link
Contributor Author

StarGate01 commented Jul 22, 2024

I agree that caching across lock / unlock operations would be a nice solution. Do you have some pointers how this could be implemented?

Just to be pedantic though, the events / yields emitted by SCardGetStatusChange are not the result of any active scan, but rather delivered by the OS PC/SC driver when a hardware plug event occurs.

how prevelant NFC use is out there

Ever since KeePassXC has gained PC/SC support is has been the tool of choice for the highly motivated (albeit small) chip implant community (https://forum.dangerousthings.com/) . Other users just like having a NFC reader in/on their desk and tapping their Yubikey / smartcard instead of fumbling with USB ports.

I do agree that the userbase might be narrow but I am willing to put the effort in myself to support them.

@droidmonkey
Copy link
Member

I see, if you can get the event listener approach to work I'm game

@GrimzEcho
Copy link

Just want to chime in that the UX flow of having a banner asking you to "Please present or touch your YubiKey to continue" when saving the database works well and is intuitive, especially for those accustomed to scanning NFC tokens with phone-based apps.

It would be great if the same or similar interface could be used for opening the database.

Small aside, but it would also be nice if the timeout to present the key could be increased to something like 10 - 15 seconds (I think it is 5 seconds right now).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants