allowCredentials security/privacy concern
107 views
Skip to first unread message
Pravesh Shetty
Mar 11, 2024, 8:48:19 AMMar 11
to FIDO Dev (fido-dev)
Hi,
Is it okay to send credential IDs in allowCredentials from server for a non logged in user for the passkey authentication ceremony. Is there any security/ privacy concern here, since the api is public can be accessed by anyone to reveal other users credential IDs.
Note: I was thinking of using allowCredentials to restrict showing some passkeys to the user, since I already take user phone number input from the user and want to show only passkey associated with that phone number so that the user does not get confused.
Thanks,
Pravesh S Shetty
My1
Mar 11, 2024, 8:54:29 AMMar 11
to Pravesh Shetty, FIDO Dev (fido-dev)
AllowCredentials only shows the credential IDs or back in the age of U2F, Key Handles (in the end more or less the same thing), and according to spec it's either random or encrypted.
At worst you can see if a user has FIDO Devices and/or platform creds or how many different ones they have.
Additionally you also get a benefit if you work with allowlist. you do not have to use resident/discoverable credentials, which really helps users with physical Fido Devices as for Example Yubikeys store only 25 resident credentials, while with non-resident credentials, as they are basically stored by the relying party (aka website) there's basically no limit.
--
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 view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/ac90badf-778a-4f0a-9b5f-065a5a59c04fn%40fidoalliance.org.
Emil Lundberg
Mar 11, 2024, 8:57:09 AMMar 11
to My1, Pravesh Shetty, FIDO Dev (fido-dev)
See also the Privacy Considerations sections §14.6.2. Username Enumeration and §14.6.3. Privacy leak via credential IDs in the spec.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CACHSkNoyMTGqBLFWdJL-A30NaPESZHVaVBD0A-M1r2c8mNkpBg%40mail.gmail.com.
My1
Mar 11, 2024, 9:04:37 AMMar 11
to Emil Lundberg, Pravesh Shetty, FIDO Dev (fido-dev)
To be quite honest, some of the mentioned migitations make a pretty stupid procedure, like email verification then 2FA for login, or User/Password then FIDO2, from experience I can say enough users are already annoyed with Password requirements (including in some cases even the pure existence of a password or lockscreen), and FIDO2 is a comparatively decent standard in terms of usability while maintaining excellent security.
Especially as username enumeration is seen as a problem in places where usernames are practically public or there are enough other avenues (registration) to check for username availability.
Pravesh Shetty
Mar 11, 2024, 10:06:46 AMMar 11
to FIDO Dev (fido-dev), My1, Pravesh Shetty, FIDO Dev (fido-dev), Emil Lundberg
yes the mitigations don't make much sense to me as well, since the whole idea of moving to passkey for me is to totally avoid 2FA or User/Password. No point in using that before passkey.
Tim Cappalli
Mar 11, 2024, 10:20:58 AMMar 11
to Pravesh Shetty, FIDO Dev (fido-dev), My1, Emil Lundberg
If you want to avoid asking for a username, then it is recommended to use the autofill UI (and if not available, a "Sign in with a passkey" button).
On Mon, Mar 11, 2024 at 10:06 AM 'Pravesh Shetty' via FIDO Dev (fido-dev) <fido...@fidoalliance.org> wrote:
This message originated outside your organization.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/db916ee7-c091-4439-9dd5-a05d5170f29dn%40fidoalliance.org.
Arshad Noor
Mar 11, 2024, 12:46:27 PMMar 11
to Pravesh Shetty, FIDO Dev (fido-dev)
Pravesh,
The goal of allowCredentials is to make it easier for the user to
authenticate, and faster for the RP to determine which public-key to use
to verify a signed challenge during the authentication phase:
- User comes to login page
- User types in username
- RP retrieves credentialIds and sends it in allowCredentials
- Authenticators with the right credentialId "light up"
- User responds with TUP or UV
- Challenge is signed and returned
- RP uses public-key to verify response
- User is authenticated
If some attacker is trying to figure out if a specific username is (or
random usernames are) registered with the RP, the FIDO server can send
back a random credentialId and challenge to thwart the attacker.
Open-source FIDO servers
(https://sourceforge.net/projects/strongkeyfido/) are capable of
generating tens of thousands (or even millions) of random credentialIds
with public-keys that can never be verified to a real credentialId
regardless of how diligent the attacker is. (If you are NOT paying a
license fee per credentialId for a FIDO server, does it matter how many
unverifiable credentialIds you can store in a distinct FIDO server to
waste the attacker's time?)
If the attacker does not have an Authenticator that can match up with a
valid credentialId, he is NEVER going to respond successfully to a
challenge. So, whether the attacker learns that a specific username is
registered or not with the RP, how does it help the attacker compromise
the account?
Besides, with 35K publicly disclosed data breaches and 17.7B breached
records (https://privacyrights.org/data-breaches), what is private
anymore? As long as the user has their private key in a Security Key,
there is some assurance of security (to the extent you can trust the
Security Key).
With synchronized passkeys in the cloud, the RP has already chosen to
break the FIDO privacy guarantee to the user (and potentially, the
security of the user's private-key) by allowing the
passkey-service-provider to store the key-pair in the cloud. With IBM
and an HBR article claiming that 80% of all data breaches in 2023
originated in the cloud
(https://hbr.org/2024/02/why-data-breaches-spiked-in-2023), the
probability of a compromised credential is higher than with a known
credentialId in a Security Key under the control of the user.
Arshad Noor
StrongKey
The goal of allowCredentials is to make it easier for the user to
authenticate, and faster for the RP to determine which public-key to use
to verify a signed challenge during the authentication phase:
- User comes to login page
- User types in username
- RP retrieves credentialIds and sends it in allowCredentials
- Authenticators with the right credentialId "light up"
- User responds with TUP or UV
- Challenge is signed and returned
- RP uses public-key to verify response
- User is authenticated
If some attacker is trying to figure out if a specific username is (or
random usernames are) registered with the RP, the FIDO server can send
back a random credentialId and challenge to thwart the attacker.
Open-source FIDO servers
(https://sourceforge.net/projects/strongkeyfido/) are capable of
generating tens of thousands (or even millions) of random credentialIds
with public-keys that can never be verified to a real credentialId
regardless of how diligent the attacker is. (If you are NOT paying a
license fee per credentialId for a FIDO server, does it matter how many
unverifiable credentialIds you can store in a distinct FIDO server to
waste the attacker's time?)
If the attacker does not have an Authenticator that can match up with a
valid credentialId, he is NEVER going to respond successfully to a
challenge. So, whether the attacker learns that a specific username is
registered or not with the RP, how does it help the attacker compromise
the account?
Besides, with 35K publicly disclosed data breaches and 17.7B breached
records (https://privacyrights.org/data-breaches), what is private
anymore? As long as the user has their private key in a Security Key,
there is some assurance of security (to the extent you can trust the
Security Key).
With synchronized passkeys in the cloud, the RP has already chosen to
break the FIDO privacy guarantee to the user (and potentially, the
security of the user's private-key) by allowing the
passkey-service-provider to store the key-pair in the cloud. With IBM
and an HBR article claiming that 80% of all data breaches in 2023
originated in the cloud
(https://hbr.org/2024/02/why-data-breaches-spiked-in-2023), the
probability of a compromised credential is higher than with a known
credentialId in a Security Key under the control of the user.
Arshad Noor
StrongKey
> --
> 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>.
> 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 view this discussion on the web visit
> https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/ac90badf-778a-4f0a-9b5f-065a5a59c04fn%40fidoalliance.org <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/ac90badf-778a-4f0a-9b5f-065a5a59c04fn%40fidoalliance.org?utm_medium=email&utm_source=footer>.
My1
Mar 11, 2024, 1:38:28 PMMar 11
to Arshad Noor, Pravesh Shetty, FIDO Dev (fido-dev)
I don't think that was originally the goal of the allowlist.
the concept existed since U2F and I assume the goal was rather to have a 90% stateless device (as the device didnt need to keep track of anything except its secret, which doesnt change as there was no concept of resets, and the counter) meaning you need practically no storage on the device.
also most of the time the client did not tell me that there was no available credential on the device until after I went and confirmed, and especially with credprotect, FIDO Devices will not tell you if they know the credential or not before you did UV.
and to be entirely honest, using allowlist and remote-stored credentials is still what I believe to be ideal in most cases.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/d23afeed-7731-4dc7-a6aa-dedbc85f92cd%40strongkey.com.
Arshad Noor
Mar 11, 2024, 1:49:45 PMMar 11
to My1, Pravesh Shetty, FIDO Dev (fido-dev)
You are right that it was not the original goal - but now, you're
talking about capability that goes back a full decade ago. Things have
changed in the FIDO world, and APIs that were designed for a specific
purpose can be leveraged for other things (such as improving the
performance of servers as well as thwarting privacy attacks).
Remotely stored key-pairs with only the RP might be acceptable in some
use-cases to some RPs and users (as it allows a Security Key to store
"unlimited" credentials), but for some RPs, users and use-cases, having
the private key leave the secure element is anathema. Cheaper for users
to pay for multiple Security Keys than to worry if the Security Key
and/or RP implementation is flawed.
Arshad
On 3/11/24 10:38, My1 wrote:
> I don't think that was originally the goal of the allowlist.
>
> the concept existed since U2F and I assume the goal was rather to have a
> 90% stateless device (as the device didnt need to keep track of anything
> except its secret, which doesnt change as there was no concept of
> resets, and the counter) meaning you need practically no storage on the
> device.
>
> also most of the time the client did not tell me that there was no
> available credential on the device until after I went and confirmed, and
> especially with credprotect, FIDO Devices will not tell you if they know
> the credential or not before you did UV.
>
> and to be entirely honest, using allowlist and remote-stored credentials
> is still what I believe to be ideal in most cases.
>
> Am Mo., 11. März 2024 um 17:46 Uhr schrieb Arshad Noor
> <arsha...@strongkey.com <mailto:arsha...@strongkey.com>>:
> <mailto:fido-dev%2Bunsu...@fidoalliance.org>
> > <mailto:fido-dev+u...@fidoalliance.org
> <mailto:fido-dev%2Bunsu...@fidoalliance.org>>.
talking about capability that goes back a full decade ago. Things have
changed in the FIDO world, and APIs that were designed for a specific
purpose can be leveraged for other things (such as improving the
performance of servers as well as thwarting privacy attacks).
Remotely stored key-pairs with only the RP might be acceptable in some
use-cases to some RPs and users (as it allows a Security Key to store
"unlimited" credentials), but for some RPs, users and use-cases, having
the private key leave the secure element is anathema. Cheaper for users
to pay for multiple Security Keys than to worry if the Security Key
and/or RP implementation is flawed.
Arshad
On 3/11/24 10:38, My1 wrote:
> I don't think that was originally the goal of the allowlist.
>
> the concept existed since U2F and I assume the goal was rather to have a
> 90% stateless device (as the device didnt need to keep track of anything
> except its secret, which doesnt change as there was no concept of
> resets, and the counter) meaning you need practically no storage on the
> device.
>
> also most of the time the client did not tell me that there was no
> available credential on the device until after I went and confirmed, and
> especially with credprotect, FIDO Devices will not tell you if they know
> the credential or not before you did UV.
>
> and to be entirely honest, using allowlist and remote-stored credentials
> is still what I believe to be ideal in most cases.
>
> Am Mo., 11. März 2024 um 17:46 Uhr schrieb Arshad Noor
>
> Pravesh,
>
> The goal of allowCredentials is to make it easier for the user to
> authenticate, and faster for the RP to determine which public-key to
> use
> to verify a signed challenge during the authentication phase:
>
> - User comes to login page
> - User types in username
> - RP retrieves credentialIds and sends it in allowCredentials
> - Authenticators with the right credentialId "light up"
> - User responds with TUP or UV
> - Challenge is signed and returned
> - RP uses public-key to verify response
> - User is authenticated
>
> If some attacker is trying to figure out if a specific username is (or
> random usernames are) registered with the RP, the FIDO server can send
> back a random credentialId and challenge to thwart the attacker.
> Open-source FIDO servers
> (https://sourceforge.net/projects/strongkeyfido/
> <https://sourceforge.net/projects/strongkeyfido/>) are capable of
> Pravesh,
>
> The goal of allowCredentials is to make it easier for the user to
> authenticate, and faster for the RP to determine which public-key to
> use
> to verify a signed challenge during the authentication phase:
>
> - User comes to login page
> - User types in username
> - RP retrieves credentialIds and sends it in allowCredentials
> - Authenticators with the right credentialId "light up"
> - User responds with TUP or UV
> - Challenge is signed and returned
> - RP uses public-key to verify response
> - User is authenticated
>
> If some attacker is trying to figure out if a specific username is (or
> random usernames are) registered with the RP, the FIDO server can send
> back a random credentialId and challenge to thwart the attacker.
> Open-source FIDO servers
> (https://sourceforge.net/projects/strongkeyfido/
> generating tens of thousands (or even millions) of random credentialIds
> with public-keys that can never be verified to a real credentialId
> regardless of how diligent the attacker is. (If you are NOT paying a
> license fee per credentialId for a FIDO server, does it matter how many
> unverifiable credentialIds you can store in a distinct FIDO server to
> waste the attacker's time?)
>
> If the attacker does not have an Authenticator that can match up with a
> valid credentialId, he is NEVER going to respond successfully to a
> challenge. So, whether the attacker learns that a specific username is
> registered or not with the RP, how does it help the attacker compromise
> the account?
>
> Besides, with 35K publicly disclosed data breaches and 17.7B breached
> records (https://privacyrights.org/data-breaches
> <https://privacyrights.org/data-breaches>), what is private
> with public-keys that can never be verified to a real credentialId
> regardless of how diligent the attacker is. (If you are NOT paying a
> license fee per credentialId for a FIDO server, does it matter how many
> unverifiable credentialIds you can store in a distinct FIDO server to
> waste the attacker's time?)
>
> If the attacker does not have an Authenticator that can match up with a
> valid credentialId, he is NEVER going to respond successfully to a
> challenge. So, whether the attacker learns that a specific username is
> registered or not with the RP, how does it help the attacker compromise
> the account?
>
> Besides, with 35K publicly disclosed data breaches and 17.7B breached
> records (https://privacyrights.org/data-breaches
> anymore? As long as the user has their private key in a Security Key,
> there is some assurance of security (to the extent you can trust the
> Security Key).
>
> With synchronized passkeys in the cloud, the RP has already chosen to
> break the FIDO privacy guarantee to the user (and potentially, the
> security of the user's private-key) by allowing the
> passkey-service-provider to store the key-pair in the cloud. With IBM
> and an HBR article claiming that 80% of all data breaches in 2023
> originated in the cloud
> (https://hbr.org/2024/02/why-data-breaches-spiked-in-2023
> <https://hbr.org/2024/02/why-data-breaches-spiked-in-2023>), the
> there is some assurance of security (to the extent you can trust the
> Security Key).
>
> With synchronized passkeys in the cloud, the RP has already chosen to
> break the FIDO privacy guarantee to the user (and potentially, the
> security of the user's private-key) by allowing the
> passkey-service-provider to store the key-pair in the cloud. With IBM
> and an HBR article claiming that 80% of all data breaches in 2023
> originated in the cloud
> (https://hbr.org/2024/02/why-data-breaches-spiked-in-2023
> > <mailto:fido-dev+u...@fidoalliance.org
> <mailto:fido-dev%2Bunsu...@fidoalliance.org>>.
> > To view this discussion on the web visit
> >
> https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/ac90badf-778a-4f0a-9b5f-065a5a59c04fn%40fidoalliance.org <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/ac90badf-778a-4f0a-9b5f-065a5a59c04fn%40fidoalliance.org> <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/ac90badf-778a-4f0a-9b5f-065a5a59c04fn%40fidoalliance.org?utm_medium=email&utm_source=footer <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/ac90badf-778a-4f0a-9b5f-065a5a59c04fn%40fidoalliance.org?utm_medium=email&utm_source=footer>>.
> >
>
> --
> 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%2Bunsu...@fidoalliance.org>.
> --
> 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 view this discussion on the web visit
> https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/d23afeed-7731-4dc7-a6aa-dedbc85f92cd%40strongkey.com <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/d23afeed-7731-4dc7-a6aa-dedbc85f92cd%40strongkey.com>.
>
> --
> 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
> --
> 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 view this discussion on the web visit
> https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CACHSkNr6Mv_5RYS_YLZtpKccY2-CyBvNfthTypCujvOZ8MuwNQ%40mail.gmail.com <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CACHSkNr6Mv_5RYS_YLZtpKccY2-CyBvNfthTypCujvOZ8MuwNQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> <mailto:fido-dev+u...@fidoalliance.org>.
> To view this discussion on the web visit
Reply all
Reply to author
Forward
0 new messages