-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Add user verification to webauthn challenges #44442
Conversation
27c76c3
to
d6877db
Compare
Is it possible to add the security label to this PR (like #34389 had) ? @blizzz: I see you've changed the milestone, I wonder if it's possible to reconsider. I know you have several requests in the queue and need to prioritize things. But currently using a hardware token for passwordless authentication weakens authentication security in a way: anyone with physical access to that token can get an authenticated session. |
Hello there, We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process. Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6 Thank you for contributing to Nextcloud and we hope to hear from you soon! |
This comment was marked as off-topic.
This comment was marked as off-topic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the pull request 😃
I rebased, fixed conflicts, tested locally with 2 keys and made some necessary changes to the code.
My Changes
- Made
user_verification
column nullable to make it compatible with all databases. - Bumped
@since 29.0.0
to@since 30.0.0
etc. - Made some minor changes to avoid checking in already deprecated code.
Tests
It works good so far. I tested it with a key protected by a PIN (user verification) and one that has no pin. The PIN prompt is only shown when just the protected key is configured.
Bugs
However, there is one bug/caveat:
- Set up one key A with a PIN and one key B without.
- Observe the
oc_webauthn
table and see thatuser_verification
is correctly set to 1 and 0 (A, B). - Log out and log in using a device.
- Use the protected key (-> no PIN is prompted as expected).
- Observe the
oc_webauthn
table and see thatuser_verification
was overwritten to 0 and 0 (A, B).
The credential is saved and overwritten each time a log in is performed which causes the user verification to be reset. I stepped through the code and it seems that the Webauthn library calls our CredentialRepository::saveCredentialSource()
method on each login. Note that this only happens when at least one key without a PIN is configured.
I think we should handle this case a bit better by either not overwriting during logins or finding another solution.
Thanks for your review One solution would be to change the authentication challenge from DISCOURAGED to PREFERRED when one of the key doesn't have UV. It has the benefits to:
Downside:
I think the downside is dangerous. Not overwriting the key is probably a better solution |
If you think this is security related, please follow https://github.com/nextcloud/server/blob/master/SECURITY.md |
Require user verification if all tokens are registered with UV flag, else discourage it Signed-off-by: S1m <git@sgougeon.fr> Signed-off-by: Richard Steinmetz <richard@steinmetz.cloud>
This is the route I chose for now. Now, the user verification is never downgraded from Existing users won't be affected. Only new devices will be affected and if a user wants to benefit from UV they have to remove all existing keys and re-register them with UV. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested and works. Remaining feedback has been addressed.
Hello, is anything blocking this PR ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot
This drowned in my notifications, sorry
Left some minor feedback
lib/private/Authentication/WebAuthn/Db/PublicKeyCredentialEntity.php
Outdated
Show resolved
Hide resolved
So this PR is tagged with "to release" and won't be release ? This is sad because this is a security fix Fortunately there is a workaround for admin who cares about their user security: #41599 (comment) and users should be aware to not use passkeys until this is merged or there is the workaround |
Well I guess it just slipped, as CI didnt work for the fork and therefore the PR never turned green. I will send a local PR so CI passes and then it should go in |
Running in #47253 |
Thanks a lot for your feedback, I hope the CI will be OK |
|
THanks for the contribution @p1gp1g and sorry for the miss |
No problem for the miss, and thank you ! |
@p1gp1g @Be-ing, sorry for the late reply! Thanks @nickvergessen for the help, glad to see this moving forward!! |
Require user verification if all tokens are registered with UV flag, else discourage it
Summary
TODO
* Currently, this is always discouraged
Checklist