GitHub is on that same page too:
GitHub is on that same page too:
Re. “Webauthn as a first factor authenticator”, there’s discussion for for level 2 of the standard to mention the privacy implications this can have: https://github.com/w3c/webauthn/pull/1250/
Re. security key naming, I agree for the reasons outlined on the RubyGems.org PR.
I also suggested there to add a “last used for login at” timestamp in addition to security key nickname to help disambiguate them and spot potential malicious activity.
At work (which is a high security context) we also have an alert that emails you after a security key has been unused for 90 days, prompting you to either use it or remove it from your account.
I think implementing that at 360 days might be a good idea?
Great idea. Having a lower interval would be annoying as we use “infinite” sessions and I think most people will have a day to day key plus a backup one in a drawer. Not counting multiple devices native security keys.
I am pleased to announce that I have just merged the PR for this feature, so we can kick some webauthn tires very, very soon!
Just added my Android fingerprint, Yubikey via NFC and Yubikey via USB-C, using Chrome Android and Firefox Desktop and all looks ok so far.
Works fine on Desktop view:
Some random feedback
This does not look right:
We should follow the composer here on margin and color of cancel.
Instead of `Password reset email" feels a bit like it does not belong here.
Forgot password? <- in light grey
Password entry looks way big, should be a bit smaller.
I think this should say “Remove” or “Delete”
If you try to add a yubikey that you already added a cryptic error shows up.
Argh, I knew I was missing a route in review. Good catch
I think it’s been like this for a while, but yes these are good changes
Agree, good change.
Perhaps we can re-use the built-in chrome copy here? “You have already registered this security key. You don’t have to register it again.” is a nice clear copy.
Thanks @Falco and @sam for your feedback. I didn’t realise there was a different route for mobile login either! I will start work on these fixes including the password labelling/button changes tonight, hopefully even open a new PR to fix!
I’m really glad this worked on your Android as well (even though the mobile view is not working correctly) — I didn’t have an Android to test with.
May I recommend the Xiaomi Mi 9?
I’m not sure I’m ready to return to Android – I love my iPhone 8 too much
Here is the PR to fix up the above
Who said return? That is old world thinking! Modern people own multiple devices
This is very nice!
One minor niggle though: on Safari/Mac, Web Authentication is a developer-only feature, off by default. When enabled, it works well. But we should likely show a message or a warning when Web Authentication is not enabled. Currently, on default Safari, nothing in the UI indicates that the registration process won’t work (the console has an error):
We can feature detect using
navigator.credentials I assume.
Some people have a hard time justifying the extra expense even though it’s nice
Argh I did that feature check on navigator.credentials.get but not create sorry about that, will be a quick fix!
The most recent commit seems to be working. I was able to use 2-factor (with fingerprint!) on my android phone just now.
Hey Penar, I’ve got a fix up for this now, are you able to check it out on Safari? [FIX] Check webauthn support when registering security keys by mjrbrennan · Pull Request #8146 · discourse/discourse · GitHub . I’m just not sure if the method of feature detection I’m using will work with Safari having the feature turned off.