Re: [FIDO-DEV] Digest for fido-dev@fidoalliance.org - 5 updates in 3 topics

[Perla nallely Guadalupe Alejandre Ramón]

Mi teléfono está sincronizado con el correo de mi esposo gracias a eso tengo las pruebas nombres de las personas estados de cuenta gastos que isieron y todo para meterlo a la cárcel porque no se vale no es justo más sin embargo solo quiero un documento firmado por las autoridades y una restricción 

El jue., 1 de diciembre de 2022 4:58 p. m., <fido...@fidoalliance.org> escribió:

fido...@fidoalliance.org

Google Groups

Topic digest
View all topics

• Chrome on Android - Passkeys | wrong error message on create credential flow - Bug - 1 Update
• Detached FIDO Authentication - 3 Updates
• Understanding dif authentication types - 1 Update

Chrome on Android - Passkeys | wrong error message on create credential flow - Bug

Tal Peretz <tal...@gmail.com>: Dec 01 12:50PM -0800 Device name:Samsung Galaxy S21+ Ultra (SM-G998B)   From "Settings > About Chrome" Application version: 107.0.5304.141 Operating system: Android 12; SM-G998B Build/SP1A.210812.016   URLs (if applicable): webauthn.io; console.ownid.com   Steps to reproduce: (1) Enter email (2) Press the FingerPrint widget (3) Create a passkey screen should popup (4) Press on the dark screen outside the create a passkey / Press "cancel"   You'll get the next error code and exception from WebauthN api:   *"The user attempted to register an authenticator that contains one of the credentials already registered with the relying party."*   Which isn't the case at all, the user doesn't have any credentials that already registered with the relying party.   It should be different error message - Like "User cancel the flow".   We are trying to understand if that's the normal behavior, we believe it's not.   Could someone explain what stands behind this error message?

Back to top

Detached FIDO Authentication

Dennis Kniep <kniep...@gmail.com>: Dec 01 04:12AM -0800 Hi FIDO-Community,   we developed "Detached FIDO Authentication" for applications without WebAuthn support.   https://denniskniep.github.io/posts/01-detached-fido-authentication/   Only if we enforce FIDO-only and block legacy authentication via SMS, Call, TOTP, Push etc. we are truly phishing-resistant.   WebAuthn is a requirement, but not always available. Some legacy Apps use WebViews without WebAuthn support.   "Detached FIDO Authentication" is our answer until applications support WebAuthn.   We are looking forward to your feedback and hopefully improvement ideas.

Emil Lundberg <em...@yubico.com>: Dec 01 04:21PM +0100 Hi Dennis,   I have a question: You state that "This “same device” check prevents phishing of the WebAuthn-incompatible WebView portion of the process.", but how does the "same device" check prevent this? If the page loaded in the legacy WebView is a phishing site, won't any remote requests done by it originate from the user's same client device as the remote requests in the WebAuthn-compatible browser? So in that case both the privateToken and any authentication cookies will be returned to the legacy WebView even though it's running malicious code.   Is it perhaps that if the cookies are set to HttpOnly they won't be accessible to any client-side JavaScript relaying credentials, so the request would have to originate from either a different host or a compromised browser in order to intercept the cookies? If so, I think it's worth highlighting HttpOnly in your proposal.   Emil Lundberg   Software Engineer | Yubico <http://www.yubico.com/>

Dennis Kniep <kniep...@gmail.com>: Dec 01 11:26AM -0800 Hi,   if we look at the phishing technique where the phishing website is hosted under a different Domain and all requests are proxied through a “man-in-the-middle" phishing proxy to the original website. Then the requests from the “man-in-the-middle" phishing proxy to the webserver and the requests from the Browser to the webserver have different IPs. The important part is that the requests from the Browser can not be intercepted by an “man-in-the-middle" phishing proxy, because we are authenticating with FIDO. (see diagrams in attachment) I'am going to update the blog post with this diagrams for clarification.   The attack vector you are referring to with "WebView is running malicious code" is XSS?   Cheers, Dennis     On Thursday, 1 December 2022 at 16:21:24 UTC+1 Emil Lundberg wrote:

Back to top

Understanding dif authentication types

Randy Johns <randyjohns...@gmail.com>: Dec 01 08:13AM -0800 I am new to this topic but have looked and many articles and want to make sure I am understanding what is available today for authentication types:   1. Password only (single factor authentication) 2. Password substitute (OTP, Bio, etc replace password) 3. MFA (Password and another factor...something the user has or is) 4. Passwordless (no password ever created...public and private key to device created)

Back to top

You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to fido-dev+u...@fidoalliance.org.