State of passwordless authentication

146 views
Skip to first unread message

Emanuele Cesena

unread,
Mar 23, 2019, 3:39:01 PM3/23/19
to FIDO Dev (fido-dev)
Hi,

I have two questions on passwordless authentication as I’m trying to understand how far are we from prime time, outside the windows/microsoft ecosystem.

1. What’s the general feeling about passwordless authentication without resident keys?
I’d like to understand security and usability considerations.
My understanding is that the only feature one would loose is the ability for a user to have multiple accounts on a service, that I think could be ok for many services, for example Facebook or Linkedin.

2. What’s the current state and plan of browser support for resident keys?
To my knowledge Edge on Windows and Safari Preview on Mac are the only browsers currently supporting resident keys. Unsure about Chrome on Android as I haven’t had the opportunity to test it.

Thank you,
-- 
Emanuele Cesena <emanuel...@gmail.com>
https://solokeys.com 

Il corpo non ha ideali

Thomas Duboucher

unread,
Mar 23, 2019, 7:14:42 PM3/23/19
to fido...@fidoalliance.org
Hi Emanuele,

My feeling is that RPs will transition from FIDO as a second factor,
i.e. username + password + test of user presence, to FIDO as a strong
authentication, i.e. username + device passphrase, for roaming
authenticators alongside username-less for platform authenticators. This
way, RPs can change their authentication flow step by steps without ever
requiring the user to register again their FIDO devices.

Resident keys only enables username-less authentication. You do not need
it at all for passwordless authentication. Also you can still have
multiple accounts per device without resident keys just like U2F did.

Resident keys will be useful for platform authenticator and bring a
really fluid authentication flow. But roaming authenticators will still
have a low limit of the total number of resident credentials it can hold
to the point I believe it won't be really practical: it will be limited
to enterprise usage like logging in on a device. I assume that RPs will
have to support both username and username-less authentication flows.

On the side of browsers, by the end of next month, all major browsers on
Windows 10, Edge, Chrome and Firefox, will support the WebAuthn API
provided by Windows 10 1809 and higher. As a result, all of them should
support resident keys at the same time. It is also my understanding that
Google had partially working code for resident keys, but it is currently
too buggy and deactivated.

Best regards,
> <mailto:emanuel...@gmail.com>>
> https://solokeys.com 
>
> Il corpo non ha ideali
>
> --
> You received this message because you are subscribed to the Google
> Groups "FIDO Dev (fido-dev)" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to fido-dev+u...@fidoalliance.org
> <mailto:fido-dev+u...@fidoalliance.org>.
> To post to this group, send email to fido...@fidoalliance.org
> <mailto:fido...@fidoalliance.org>.
> Visit this group at
> https://groups.google.com/a/fidoalliance.org/group/fido-dev/.
> To view this discussion on the web visit
> https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/FB352146-0D64-4185-8C8A-307D56F9AB84%40gmail.com
> <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/FB352146-0D64-4185-8C8A-307D56F9AB84%40gmail.com?utm_medium=email&utm_source=footer>.

--
Thomas Duboucher
0x9FE89D94949EDC25.asc
signature.asc

Emanuele Cesena

unread,
Mar 24, 2019, 1:18:05 PM3/24/19
to Thomas Duboucher, fido...@fidoalliance.org
Thank you Thomas for these details.

On one level I agree with you, my idea was in fact to explore passwordless without resident keys.

On the other hand, I was feeling that “passwordless authentication” is very poorly defined, and in some sense your comments are supporting my fear, which is why I’m a bit resistant to deploying passwordless.

On the security side I see two major issues that don’t seem to be clearly addressed in the specs, namely account enumeration and pin support. And as a result I fear my implementation could be either completely broken or completely confusing to the users.

1. account enumeration
If you want to implement passwordless auth without RK, then you need an API endpoint that -given a username- returns a challenge and a list of credential ids. In particular you know if an account exists. In my case account enumeration is not an issue (but it could be for other services — ok they can use RK). However the privacy implications of returning a list of credential ids are not clear to me. Also, how is this communicated to the user when she enables passwordless login? This seems a major problem to me.

2. pin support
Pin seems to be defined either on resident keys (although I saw that working on Edge, but couldn’t use it on Safari), or at device level. This seems absurd to me. As a user, with passwordless auth I want a pin, and with 2FA I don’t. As a service provider it’s even worse because browser implementation seems pretty random, thus the only viable solution is requesting userVerification preferred, which means nothing. Back to the user that’s enabling passwordless login, I not only have to explain privacy implications, I also have to refer them to a guide to add a pin to their device.

In summary, I feel that the WebAuthn specs just focus on the low level primitives create/get, they offer a million options, but they don’t define clearly what is 2FA and what is passwordless auth. As a result, the user experience is terribly confusing and I fear insecure. As much as I’d like, I don’t feel particularly confident releasing passwordless to million of users.

Best,


To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To post to this group, send email to fido...@fidoalliance.org.

-- 
Emanuele Cesena <e...@solokeys.com>

Emil Lundberg

unread,
Mar 26, 2019, 1:06:46 PM3/26/19
to FIDO Dev (fido-dev), tho...@duboucher.eu
Hi Emanuele,

I don't know enough to answer about (2) pin support, but I would like to give my view on (1) account enumeration.

It is true that passwordless authentication without RK means account enumeration is possible, and it's one of the privacy considerations mentioned in the WebAuthn spec [1]. In most cases where usernames are a primary identifier and unique, that shouldn't really matter much because the account creation page would already tell you whether a username exists. Anyway, there are ways to mitigate the problem in the cases where it does matter. For example, the RP could respond with a randomly generated list of credentials for nonexistent usernames (but it would have to be persistent to not betray the illusion - perhaps deterministically derived from the username).


/Emil

https://solokeys.com 

Il corpo non ha ideali

-- 
You received this message because you are subscribed to the Google
Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to fido-dev+u...@fidoalliance.org

To post to this group, send email to fido...@fidoalliance.org

-- 
Thomas Duboucher

-- 
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To post to this group, send email to fido...@fidoalliance.org.
Visit this group at https://groups.google.com/a/fidoalliance.org/group/fido-dev/.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/2acd294f-7719-3c61-03cc-35202d64dc0b%40duboucher.eu.
<0x9FE89D94949EDC25.asc>

Nicolas Stalder

unread,
Mar 26, 2019, 8:01:38 PM3/26/19
to FIDO Dev (fido-dev), tho...@duboucher.eu
Adding to the PIN topic:

- PIN is set on device
- RP does not cause pinAuth data to be sent by client
Then the authnr should simply set "uv" flag to 0.

Assuming my reading is correct (we are changing implementation based on this, https://github.com/solokeys/solo/pull/155):

This in my opinion runs counter to a reasonable (especially in the UAF case) user expectation that "if I set a PIN, nobody can use the key without knowing the PIN".

On the other hand, I understand the authnr can't tell the client to request a PIN.
So, for our authnr, we couldn't even optionally enforce the PIN authnr-side, if the RP fails to enforce user verification.

Is this correct?

If so, it seems the authnr (and it's user) are treated as pretty "dumb" endpoints, with all power in the hands of RP + client.

Cheers,
Nicolas - SoloKeys

James Manger

unread,
Mar 26, 2019, 11:03:22 PM3/26/19
to FIDO Dev (fido-dev), tho...@duboucher.eu
The WebAuthn spec does describe measures to limit username enumeration, though they imply that users must be offered separate "Create account" and "Login" options. The measures might need adjustment when an RP has a mix of FIDO and non-FIDO accounts.

An extra wrinkle with FIDO is that it isn't just the username that is enumerated, but also authenticator key handles. A key handle value should be fairly meaningless, though its length hints at the type of authenticator (eg 128, 256, 512, & 520 bits for Yubico resident key, Win Hello face/PIN, Yubico stateless key, & Android platform authenticator respectively). Perhaps the number & approximate type of authenticators isn't generally too sensitive once a large population are using FIDO? Though leaking that detail for a specific given username isn't ideal.

--
James Manger

On Wednesday, 27 March 2019 04:06:46 UTC+11, Emil Lundberg wrote:

Kobus Grobler

unread,
Apr 9, 2019, 9:19:47 AM4/9/19
to FIDO Dev (fido-dev)
I have been struggling with the interpretation of this part of the specification as well.

My understanding is also that if pinAuth is not sent, then the assertion is still allowed but with UV set to 0.
In fact I think this is required to pass the conformance tests.

While I also have my reservations about this, I think the idea is that the RP determines the security policy.

It does make sense in a way - if you are a bank you will want to enforce UV, while on some social media account the user experience is more important than forcing UV every time.
Also the RP can adjust the verification requirements depending on the type of transaction performed.

So, yes, the authenticator and user are pretty "dumb" endpoints...

Best
Kobus
--

Emanuele Cesena

unread,
Apr 9, 2019, 12:11:50 PM4/9/19
to Kobus Grobler, FIDO Dev (fido-dev)
I agree on your description from the user and authenticator perspective.

From the bank/social media, however, there’s a caveat. If you set required UV, and the user didn’t enable PIN on her authenticator (yet), then the authenticator isn’t shown, or (now back to the user’s point of view) it doesn’t work. I encourage you to try this out.

Because of this:
- no social media will ever require UV => no user will ever set UV
- banks requiring UV will just receive tech support calls of “my key doesn’t work"

So in summary, the communication authenticator-rp is pretty clear, but the user experience inside the browser is still a bit fragile imo.

Best,


-- 
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To post to this group, send email to fido...@fidoalliance.org.
Visit this group at https://groups.google.com/a/fidoalliance.org/group/fido-dev/.

Kobus Grobler

unread,
Apr 9, 2019, 3:29:51 PM4/9/19
to Emanuele Cesena, FIDO Dev (fido-dev)
The RP is supposed to use the authenticator info and PIN api to figure out whether a pin is set or not (and whether the authenticator supports PINs).
This works well with a Microsoft account and Edge - ie. even if a PIN is not enabled yet, the user is prompted to set a PIN etc. and the registration process works as expected.

If it does not work, then the RP implementation is probably buggy.

We're probably veering a bit off topic, but with which browser and service did you experience this so I can check it out?
Reply all
Reply to author
Forward
0 new messages