Skip to main content
Version: 7.2402.x.x RR

Direct authentication credentials

Password​

Password authentication is the most used of all credential types, but it is a weak authentication method.

The table lists all password policy parameters.

Ticket​

A one-time ticket contains a generated random value and can usually only be used once. The ticket credential also gets removed after a successful login with a certificate. By means of the ticket policy, the ticket may be configured to be re-used.

The table lists all ticket policy parameters.

Temporary strong password​

The purpose of a temporary strong password is to replace another strong authentication credential, for example a certificate or SecurID. This is important for users who lost, or forgot their other strong authentication credential, but still want the benefits of strong authentication.

It is called temporary because it is only valid for a single login operation. Therefore, it could also be described as a password that can be used only once, which is considered an exceptionally strong authentication method.

In case the user somehow finds, or remembers their other strong authentication credential, that they were trying to replace, and they use it for login, then the temporary strong password is considered unnecessary, and is removed after the successful login, even though it was not used.

The table lists all temporary strong password policy parameters.

OTP​

A one-time password (OTP) is used for a challenge/response (C/R) authentication.

A so-called OTP card, also known as grid card, contains an indexed table of small passwords. During authentication, the authentication service asks the user for a certain password on the OTP card by specifying only the coordinates of the table cell on the OTP card. The user then returns the content of that table cell to the authentication service.

The table lists all OTP policy parameters.

Vasco Digipass token​

Vasco Digipass tokens can handle challenge/response authentication and response-only authentication, depending on the Vasco Digipass device used.

During authentication with challenge/response, nevisIDM uses the token to create a challenge. The user then has to enter the challenge into the Vasco Digipass device to get the correct response. For response-only authentication, the user gets the response directly from the device.

Certificate​

An X509 certificate enables a user to authenticate himself without interaction (besides the password he might have to enter for the private key). It also adds extra security to the connection (two-way SSL), which makes it harder for man-in-the-middle proxies to intercept the traffic or to execute man-in-the-middle attacks. A certificate can only be registered once within a nevisIDM client (tenant).

The ability to log in without interaction makes certificate authentication very suitable for technical clients, for example, SOAP clients.

nevisIDM requires the information encoded in the certificate. To avoid that the certificate has to be parsed every time, the table TIDMA_CERT_INFO was introduced. It is located in Certificate - policy parameters.

SuisseID​

The SuisseID is the digital equivalent of the Swiss passport. From a technical perspective - from nevisIDM's perspective - the SuisseID is a pair of certificates belonging to a single SuisseID number. However, only one, the Identity and Authentication Certificate (IAC), is used for the login. Therefore, nevisIDM treats it as a single certificate credential and there is no credential type SuisseID.

info

For more information about the SuisseID, see http://www.adnovum.ch

PUK​

A PUK (Personal Unblocking Key) is a strong type of password that can be used for authentication or to unlock other passwords. The value of a PUK can only be generated by nevisIDM; it cannot be set by web service or on the GUI.

The PUK can be generated together with a normal password (sometimes also called PIN). In this case, a new password credential will be generated automatically as well. If the user already has a password credential, it will be reset.

The table lists all PUK policy parameters.

URL ticket​

A URL ticket is a special password that is communicated to the user as part of a personalized link. The value of a URL ticket can be generated in the nevisIDM. It cannot be set by web service or on the GUI. The URL tickets cannot be regenerated. A URL ticket can be used only once; it will be deleted automatically after a successful authentication.

The format of the personalized link is as follows:

  • {URLPrefix}{calculated value depending on loginId/clientId/URL ticket}

The table lists all URL ticket policy parameters.

Device password​

A device password credential is similar to a normal password credential, with the exception that the user is allowed to have several device password credentials. This is useful for users who have multiple devices (smartphone, PC, laptop, etc.).

The device password credential provides the same features as a normal password credential. To log in using the device password, the user must provide an additional identifier that uniquely defines the credential/device to use. This identifier is called the device password ID.

Device password credentials support the same policy parameters as password credentials. The table lists all these policy parameters.

Context password​

A context password credential is similar to a normal password credential, with the exception that the user is allowed to have several context password credentials. The context password credential provides the same features as a normal password credential.

Additionally, it has a mandatory context attribute that is unique for each user. To log in using the context password, the context must be given by the user, which uniquely defines which context password to use.

The table lists all context password policy parameters.

Security question​

The security question credential holds the user's answers to one or more security questions, e.g., What was the name of your first pet? In the default setup, only the owner of the credential is allowed to add or modify answers. This behavior can be changed with the Security Question policy parameter restrictModifyToOwner.

We recommend using security questions as an additional authenticator in combination with other credentials only.

OATH​

OATH credentials are OTP credentials based on the specification of the Initiative for Open Authentication (OATH). They support two modes, HOTP and TOTP. HOTP is a HMAC-based one-time password algorithm that is counter-based, which means that the user has to click to get a new password/token. TOTP is similar to HOTP but is time-based, which means the system automatically creates a new password/token after a set amount of time. We recommend TOTP unless specified otherwise.

The OATH credential is used in combination with a mobile app or hardware token that supports TOTP and/or HOTP, for example, Google Authenticator.

  • The table in the chapter OATH lists all OATH attributes.
  • The table in the chapter OATH - policy parameters contains all OATH policy parameters.

FIDO UAF​

This FIDO UAF credential type respects the FIDO Universal Authentication Framework protocol, which describes a passwordless login experience. It is also possible to use the FIDO UAF credential as a second factor or for mobile authentication. A nevisIDM user may have zero, one or more FIDO UAF credentials.

A FIDO UAF credential is uniquely identified by the combination of its authenticator attestation identifier and its key identifier.

The standard describes multiple flows and variants, see the FIDO specification.

The table in the FIDO UAF chapter lists all FIDO UAF attributes.

Recovery code​

Users need recovery codes to access their account if they cannot receive two-factor authentication codes anymore. This may happen, for example, if they loose access to their device. One recovery code credential consists of 16 codes. The user can use each code only once to authenticate. It is possible to regenerate 16 new codes any time (for example, if the user runs out of unused recovery codes).

caution

You have to treat recovery codes with the same level of attention as passwords.

The table in the Recovery code chapter lists all attributes of the recovery code credential.

FIDO2​

This FIDO2 credential type respects the FIDO2 protocol (webAuthn + CTAN) which describes a passwordless login experience. A nevisIDM user may have zero, one or more FIDO2 credentials.

The standard describes multiple flows and variants, see the FIDO specification.

The table in the FIDO2 chapter lists all FIDO2 attributes.

Last updated on