Multi-factor Authentication Tutorial

  1. What is Multi-factor Authentication?
  2. What is User Verification?
  3. Demo
    1. Registration
    2. Authentication
  4. Parameters explanation

What is Multi-factor Authentication?

Multi-factor Authentication (MFA) is an authentication method in which a computer user is granted access only after successfully presenting two or more pieces of evidence, or factors, to an authentication mechanism.
Those factors can be:

  • Something you knows: password, PIN, etc.
  • Something you have: security keys, smart cards, etc.
  • Something you are: biometrics

What is User Verification?

The scenario in Two-factor Authentication tutorial is an example of MFA. But when you kill password (as Passwordless Authentication tutorial), and may kill username too (as Usernameless Authentication tutorial), the authentication is no more MFA and it is not totally secure. The attackers can get access to your account if they know your username and have your security key.

With FIDO2 protocol, authenticator can verify its user by various authorization gesture. For example, through a touch plus pin code, password entry, or biometric recognition (e.g., presenting a fingerprint). This process is called User Verification (UV). userVerification parameter has 3 values:

  • required: the Relying Party (RP) requires user verification for the operation.
  • preferred: the RP prefers user verification for the operation if possible.
  • discouraged: the RP does not want user verification employed during the operation.

In order to enforce UV, userVerification parameter must be required when registering a new credential and when authenticating registered credential.

Note

  • Authenticator will perform UV using one of the available methods (biometrics, clientPin, etc.).
  • Authenticator may not support UV. Contact authenticator vendor for detail if your authenticator cannot perform UV.
  • In case your authenticator is already set a clientPin, UV will be asked even if userVerification = discouraged.

Demo

The Passwordless Authentication scenario is reused here. The only change is userVerification parameter.

1. Registration

Already have an account on this demo site? Jump to authentication!
  • 1

    Enter user information

    Specific username or e-mail address to identify user.
    A human-palatable name for the user account, intended only for display.

2. Authentication

Have not registered yet? Back to registration!
  • 1

    Enter username

    Username is required here in order to get the list of registered credential ID from server. Then the authenticator will select the appropriate credential and send back to server to authenticate.

    Registered username.

Parameters explanation

The parameters have been used when registering a credential: 


<script>
    // possible values: none (default), direct, indirect
    let attestation = "none"; // means that the Replying Party (RP) is not interested in authenticator attestation

    let authenticatorSelection = {
        // possible values: <empty> (default), platform, cross-platform
        'authenticatorAttachment': "", // means that the RP does not specify authenticator type. User can choose what they want.
        // possible values: preferred, required, discouraged (default)
        'userVerification': "required", // means that the Relying Party requires user verification for the operation
        // possible values: true, false (default)
        'requireResidentKey': false // means that the authenticator does not have to create a client-side-resident public key credential source when creating a public key credential.
    };
</script>

RPs can specify their preference regarding attestation conveyance during credential generation. The Attestation parameter has 3 possible values:

  • none: RP is not interested in authenticator attestation.
  • indirect: RP prefers an attestation, but allows the client to decide how to obtain the attestation statements.
  • direct: RP wants to receive the attestation statement as generated by the authenticator.

In this demo, the default value is using. If your RP server needs more security, you should use "direct" to force client to return full attestation.
UserVerification has been explained in What is User Verification?.
And the use of RequireResidentKey will be explain in Usernameless authentication scenario.

The parameters have been used when authenticating registered credential: 


<script>
    // possible values: preferred, required, discouraged (default)
    let 'userVerification': "required", // means that the Relying Party requires user verification for the operation
</script>

In case RP does not specify these parameters, FIDO2 authentication server will set these as default values.