Attestation security

41 views
Skip to first unread message

Zsolt Fehér

unread,
Feb 18, 2022, 11:31:00 AM2/18/22
to FIDO Dev (fido-dev)
Hi
I'm working on understanding WebAuthn attestation security, and run into some questions. Generally whether is there any official documentation regarding attestation security ? The specification mentions an RP "policy" however i was unable to find out what are a pros / cons of making different choices in that attestation policy ( i.e. whether require attestation from authenticators etc. ).

According to the specs my understanding is that by allowing no- / self-attestation the RP puts the security into the hands of the users since any ( possibly unsecure ) authenticator can be used. In contrast, from the websites that already allow using WebAuthn most of i checked ignore attestation check completely. Is there any general recommendation regarding attestation usage ? Am i missing some other security features of WebAuthn which makes it unnecessary or is just the implementations being in an early stage ? ( for example the FIDO2 members site itself is using "attestation": "none" )

Thank you for the help in advance,
Zsolt

Philipp Junghannß

unread,
Feb 18, 2022, 11:43:40 AM2/18/22
to Zsolt Fehér, FIDO Dev (fido-dev)
Well generally there are 3 main methods of dealing with attestations:

1) completely ignoring it and send the signal to not attest, this is the easiest method as you don't need to care what devices you are dealing with and sites and stuff won't warn the user about any data about the fido device being sent as there is no data to send

2) taking note of them, but generally not doing much with them, for example to have statistics or warn users of devices that have a security vulnerability or whatever.
The user will be warned that the website will get to know the maker and model of the device Seperately tho. 

3) full hands on approach with not just asking for attestation but also denying based on what device a user has, i would only do this in for example enterprise environments where you have either strict requirements about fips or whatever, or if the type of device used is known and no others should be allowed, there is iirc also an "enterprise" type attestation that iirc also tells about the specific device rather than just the model e. G. telling its serial number, which REALLY should only be used internally, especially as it iirc has some restrictions.

Regards 
My1

--
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/4aedf376-2403-4d32-92fa-ff9ceab2a309n%40fidoalliance.org.

Ackermann Yuriy

unread,
Feb 18, 2022, 4:51:41 PM2/18/22
to Zsolt Fehér, FIDO Dev (fido-dev)

--
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/4aedf376-2403-4d32-92fa-ff9ceab2a309n%40fidoalliance.org.
--
Yuriy Ackermann
FIDO, Identity, Standards
skype: ackermann.yuriy
github: @herrjemand
twitter: @herrjemand
medium: @herrjemand

Arshad Noor

unread,
Feb 18, 2022, 5:43:33 PM2/18/22
to Zsolt Fehér, FIDO Dev (fido-dev)
Zsolt,

Any time you use a security technology, you have to have an
understanding of the threats you're protecting from. The decisions you
make on the threats you choose to protect from, and how you protect
yourself, becomes the "policy" that guides your usage of the security
technology.

One of the problems with FIDO is that most web-developers think of it as
just another "library" to make their applications "cool". This is,
clearly, the wrong approach.

To effectively understand how to leverage FIDO, you need to not only
understand the various options and constraints that are available in the
protocol/API, but how to formulate a "policy" using those options and
constraints. Unfortunately, the moving target of the WebAuthn
specifications makes this challenging.

Take a look at this Policy Module we've implemented in our open-source
FIDO Server:

https://docs.strongkey.com/index.php/skfs-home/skfs-administration/skfs-security/skfs-policy

and this demonstration site of how policies can be formulated to
accomplish your security goals:

https://demo.strongkey.com/fidopolicy/

This will give you a better understanding of how to approach this problem.

Hope that helps.

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>.
> <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/4aedf376-2403-4d32-92fa-ff9ceab2a309n%40fidoalliance.org?utm_medium=email&utm_source=footer>.
Reply all
Reply to author
Forward
0 new messages