Proyectos de Subversion Moodle

Rev

Rev 1 | Mostrar el archivo completo | | | Autoría | Ultima modificación | Ver Log |

Rev 1 Rev 1441
Línea 17... Línea 17...
17 
* fido-u2f ✅
 17 
* fido-u2f ✅
18 
* none ✅
 18 
* none ✅
19 
* packed ✅
 19 
* packed ✅
20 
* tpm ✅
 20 
* tpm ✅
Línea -... Línea 21...
- 
 
 21 
 
21 
 
 22 
> [!NOTE]
Línea 22... Línea 23...
22 
This library supports authenticators which are signed with a X.509 certificate or which are self attested. ECDAA is not supported.
 23 
> This library supports authenticators which are signed with a X.509 certificate or which are self attested. ECDAA is not supported.
Línea 23... Línea 24...
23 
 
 24 
 
24 
## Workflow
 25 
## Workflow
Línea 58... Línea 59...
58 
their organization.
 59 
their organization.
Línea 59... Línea 60...
59 
 
 60 
 
60 
### no attestation
 61 
### no attestation
61 
just verify that the device is the same device used on registration.
 62 
just verify that the device is the same device used on registration.
- 
 
 63 
You can use 'none' attestation with this library if you only check 'none' as format.
- 
 
 64 
 
62 
You can use 'none' attestation with this library if you only check 'none' as format.
 65 
> [!TIP]
Línea 63... Línea 66...
63 
* this is propably what you want to use if you want simple 2FA login protection like github, facebook, google, etc.
 66 
> this is propably what you want to use if you want secure login for a public website.
64 
 
 67 
 
65 
### indirect attestation
 68 
### indirect attestation
66 
the browser may replace the AAGUID and attestation statement with a more privacy-friendly and/or more easily
 69 
the browser may replace the AAGUID and attestation statement with a more privacy-friendly and/or more easily
67 
verifiable version of the same data (for example, by employing an anonymization CA).
 70 
verifiable version of the same data (for example, by employing an anonymization CA).
- 
 
 71 
You can not validate against any root ca, if the browser uses a anonymization certificate.
- 
 
 72 
this library sets attestation to indirect, if you select multiple formats but don't provide any root ca.
68 
You can not validate against any root ca, if the browser uses a anonymization certificate.
 73 
 
Línea 69... Línea 74...
69 
this library sets attestation to indirect, if you select multiple formats but don't provide any root ca.
 74 
> [!TIP]
70 
* hybrid soultion, clients may be discouraged by browser warnings but then you know what device they're using (statistics rulez!)
 75 
> hybrid soultion, clients may be discouraged by browser warnings but then you know what device they're using (statistics rulez!)
71 
 
 76 
 
72 
### direct attestation
 - 
 
Línea -... Línea 77...
- 
 
 77 
### direct attestation
- 
 
 78 
the browser proviedes data about the identificator device, the device can be identified uniquely. User could be tracked over multiple sites, because of that the browser may show a warning message about providing this data when register.
- 
 
 79 
this library sets attestation to direct, if you select multiple formats and provide root ca's.
73 
the browser proviedes data about the identificator device, the device can be identified uniquely. User could be tracked over multiple sites, because of that the browser may show a warning message about providing this data when register.
 80 
 
74 
this library sets attestation to direct, if you select multiple formats and provide root ca's.
 81 
> [!TIP]
75 
* this is probably what you want if you know what devices your clients are using and make sure that only this devices are used.
 82 
> this is probably what you want if you know what devices your clients are using and make sure that only this devices are used.
76 
 
 83 
 
Línea -... Línea 84...
- 
 
 84 
## Passkeys / Client-side discoverable Credentials
- 
 
 85 
A Client-side discoverable Credential Source is a public key credential source whose credential private key is stored in the authenticator,
- 
 
 86 
client or client device. Such client-side storage requires a resident credential capable authenticator.
77 
## Client-side discoverable Credentials
 87 
This is only supported by FIDO2 hardware, not by older U2F hardware.
78 
A Client-side discoverable Credential Source is a public key credential source whose credential private key is stored in the authenticator,
 88 
 
79 
client or client device. Such client-side storage requires a resident credential capable authenticator.
 89 
>[!NOTE]
80 
This is only supported by FIDO2 hardware, not by older U2F hardware.
 90 
>Passkeys is a technique that allows sharing credentials stored on the device with other devices. So from a technical standpoint of the server, there is no difference to client-side discoverable credentials. The difference is only that the phone or computer system is automatically syncing the credentials between the user’s devices via a cloud service. The cross-device sync of passkeys is managed transparently by the OS.
81 
 
 - 
 
Línea 82... Línea 91...
82 
### How does it work?
 91 
 
83 
In a typical **server-side key** process, the user provides their username (and sometimes password)
 92 
### How does it work?
84 
and the server responds with a list of all the public key credential identifiers that the user has registered.
 93 
In a typical server-side key management process, a user initiates a request by entering their username and, in some cases, their password.
85 
The authenticator then selects the first credential identifier it issued and responds with a signature
 94 
The server validates the user's credentials and, upon successful authentication, retrieves a list of all public key identifiers associated with that user account.
Línea 86... Línea -...
86 
that can be verified using the public key registered during the registration process.
 - 
 
87 
 
 - 
 
88 
In a client-side key process, the user does not need to provide a username or password.
 - 
 
89 
Instead, the authenticator searches its own memory to see if it has saved a key for the relying party.
 95 
This list is then returned to the authenticator, which selects the first credential identifier it issued and responds with a signature that can be verified using the public key registered during the registration process.
90 
If a key is found, the authentication process proceeds in the same way as it would if the server had sent a list
 96 
 
91 
of identifiers. There is no difference in the verification process.
 97 
In a client-side key process, the user does not need to provide a username or password.
92 
 
 98 
Instead, the authenticator searches its own memory to see if it has saved a key for the relying party (domain).
Línea 93... Línea 99...
93 
Both Apple and Windows 10/11 (with Firefox and Chromium) support Resident Credential.
 99 
If a key is found, the authentication process proceeds in the same way as it would if the server had sent a list
94 
However, older operating systems such as Windows 7 do not support it and instead fall back to using FIDO U2F.
 100 
of identifiers. There is no difference in the verification process.
- 
 
 101 
 
Línea 95... Línea 102...
95 
 
 102 
### How can I use it with this library?
96 
### How can I use it with this library?
 103 
#### on registration
Línea 97... Línea -...
97 
#### on registration
 - 
 
98 
When calling `WebAuthn\WebAuthn->getCreateArgs`, set `$requireResidentKey` to true,
 - 
 
99 
to notify the authenticator that he should save the registration in its memory.
 - 
 
100 
 
 - 
 
101 
#### on login
 - 
 
102 
When calling `WebAuthn\WebAuthn->getGetArgs`, don't provide any `$credentialIds` (the authenticator will look up the ids in its own memory and returns the user ID as userHandle).
 104 
When calling `WebAuthn\WebAuthn->getCreateArgs`, set `$requireResidentKey` to true,
103 
 
 105 
to notify the authenticator that he should save the registration in its memory.
104 
#### disadvantage
 106 
 
105 
The RP ID (= domain) is saved on the authenticator. So If an authenticator is lost, its theoretically possible to find the services, which the authenticator is used and login there.
 107 
#### on login
106 
 
 108 
When calling `WebAuthn\WebAuthn->getGetArgs`, don't provide any `$credentialIds` (the authenticator will look up the ids in its own memory and returns the user ID as userHandle).
107 
## Passkeys
 - 
 
Línea 108... Línea 109...
108 
Passkeys is a technique that allows sharing credentials stored on the device with other devices. So from a technical standpoint of the server,
 109 
Set the type of authenticator to `hybrid` (Passkey scanned via QR Code) and `internal` (Passkey stored on the device itself).
109 
there is no difference to client-side discoverable credentials. The difference is only that the phone or computer system is automatically
 110 
 
110 
syncing the credentials between the user’s devices via a cloud service. The cross-device sync of passkeys is managed transparently by the OS.
 111 
#### disadvantage
111 
 
 112 
The RP ID (= domain) is saved on the authenticator. So If an authenticator is lost, its theoretically possible to find the services, which the authenticator is used and login there.