Improving Passkey Support #19314
Comments
benarent
added
feature-request
|
Some interesting web-specific advice here, including auto-fill, "upselling" logins, etc: https://passkeys.dev/docs/use-cases/bootstrapping/. All interesting to consider. |
|
I have also noticed that you can not log into Teleport Connect as Connect expects a hardware security token (see attached screenshot). Using the fingerprint reader does not work. This also breaks the flow for Connect My Computer since that requires the use of Teleport Connect. So the onboarding flow for Connect My Computer (which I think was created to show fast time to value) does not work if you use passwordless login.
You also can not go back and create a password login because that flow requires a hardware key or authenticator app.
|
|
FYI @ravicious, see Taylor's comment above. |
|
I'm not familiar with how macOS passkeys support interacts with Touch ID and our auth. However, doesn't the problem described by @twakes boil down to Touch ID being scoped by application? If you add a passwordless Touch ID device to your Teleport account through a browser, you cannot use this device to log in through tsh or Connect. It's still an UX issue, but it's not unique to Connect. Well, it's two issues:
See also #35770 that I just created, the passwordless docs should explain how Connect interacts with Touch ID. |
|
There's really no way around the per-app limitation for the credentials, that's baked into macOS' security model. Using the "modern" version of macOS passkeys could solve it, but sadly it's gated behind APIs we can't use either (as they require an explicit associated domain, and we can't do that because of on-prem installs). We could do some of it for Cloud, but not on-prem. @ravicious thanks for taking a look and for the insights. @twakes, did you register your passwordless credential directly in the browser, using touch ID? Have you tried the same flow using a Yubikey (or similar) as the passwordless authenticator? |
|
did you register your passwordless credential directly in the browser,
using touch ID?
yes
Have you tried the same flow using a Yubikey (or similar) as the
passwordless authenticator?
no
If using Touch ID breaks a lot of UX, perhaps we don’t allow for it?
…On Fri, Dec 15, 2023 at 7:53 AM Alan Parra ***@***.***> wrote:
There's really no way around the per-app limitation for the credentials,
that's baked into macOS' security model. Using the "modern" version of
macOS passkeys could solve it, but sadly it's gated behind APIs we can't
use either (as they require an explicit associated domain, and we can't do
that because of on-prem installs). We could do some of it for Cloud, but
not on-prem.
@ravicious <https://github.com/ravicious> thanks for taking a look and
for the insights.
@twakes <https://github.com/twakes>, did you register your passwordless
credential directly in the browser, using touch ID? Have you tried the same
flow using a Yubikey (or similar) as the passwordless authenticator?
—
Reply to this email directly, view it on GitHub
<#19314 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA4YG3PMDXGIR4JOZK3LXV3YJRI7BAVCNFSM6AAAAAAS4RTRKCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNJXHEYTQOJQGY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Finding out what kind of authenticator is used ranges from difficult to impossible depending on cluster settings. Cluster admins could forbid Touch ID using attestation settings, although many other authenticators might end up being blocked in process. This is in a way the root of the problem, as we often can't say if the user has only Touch ID, so it makes it difficult to show a good error message. Adding to that, if the user isn't authenticated yet we shouldn't leak anything about what MFA devices they have. We could, based on cluster settings (specifically "connector=passwordless"), make an educated guess about the problem, but that won't catch all cases. Forbidding Touch ID also feels bad, as it is very practical and has good security properties. I don't have any great suggestions at the ready, but my gut is that we should figure out a way to show better errors or somehow make it work. |
I agree |
|
My passkey manager (Bitwarden) supports adding, removing and verifying it's passkey. But it does not support logging in with that passkey manager. What I mean is that when adding a passkey Teleports first prompts the browser for any available passkey managers, where Bitwarden responds. But when it comes to accually log in to Teleport it will skip/fail to prompt Bitwarden and go for Windows Hello/Hardware keys. Teleport version: 15.0.2 Edit: Browser Extensions for Chromium based browsers |
|
@OskyEdz I don't think there's much we can do here, it sounds like this is all browser behavior. You can check https://webauthn.io/ and see if you can repro the problem there, if you can then I suggest opening an issue in your browser of choice (or even Bitwarden itself). |
|
@codingllama I'm mostly confronting to there being a difference in the code between the Teleport login screen and the account setup options screen for MFA's and Passkeys. There also seam to be a more overall issues with browser extension passkeys. The way it is done on the login screen might be the most secure way and it works on the settings page because it is an internal page and does not need all the bells for detecting attacks. |
I can second this. For me passkey is working on the options Screen, but not in the login page. I'm also using bitwarden |
Tasks (in order of priority)
The text was updated successfully, but these errors were encountered: