The process by which a physical person is linked to his/her digital identity information and to his/her authentication credential is critical to deter registration fraud.
Therefore, SURFconext Strong Authentication is designed as such to ensure that:
- A person with the applicant’s claimed attributes exists, and those attributes are sufficient to uniquely identify a single person;
- The applicant whose token is registered is in fact the person who is entitled to use the identity;
Registration process
The registration process of authentication tokens is structured as follows:
- First, a self registration portal is accessed by the user (using first-factor login). This portal enables the user to select a type of second-factor token (SMS, Tiqr or YubiKey), and to prove that the user already owns an instance of that token type. The result of this is an activation code that is sent to the user by e-mail.
- Second, the user has to appear in person at the registration authority’s (RA) desk and present the registration code, a valid passport or identity card and the second-factor token. The RA accesses the RA Management portal of the service (using first- and second-factor login), looks up the registration associated with the activation code, verifies that the passport or identity card belongs to the user, verifies that the name attributes as issued federatively by the IdP match with what is written in the passport. The user also shows to the RA that he or she can authenticate using the second factor.
- The RA is vetted (i.e., issued a second-factor token) itself, initially, in a bootstrap procedure where SURFnet acts as a central RA. Once vetted, the initial (super-)RA can delegate his/her powers to other sub-RA staff members within the institute.
- All steps taken by the RA and users other events related to the SURFconext Strong Authentication service are logged, and logs are kept for an appropriate amount of time. (specify!)
Controls to ensure correct binding of token to identity
There are two general categories of threats to the registration process. SURFconext Strong Authentication has implemented different controls in its architecture and infrastructure to address these threats.
| Threat | Description | Controls |
|---|---|---|
| Impersonation of a claimed identity | An applicant claims an incorrect identity, supporting the claim with a specific set of attributes created over time or by presenting false credentials. | Controls are in place to verify that the token is indeed bound to the correct identity (federated login, e-mail verification, activation code, face to face ID-vetting) |
| Compromise or malfeasance of the infrastructure | Lack or poor implementation of security measures and policies undermine the reliability of the registration. | Infrastructure threats are addressed by implementing necessary security controls (e.g., separation of duties, record keeping, independent audits, etc.). |
Do not use SMS for password reset
Some institutions use SMS as a communication channel to the user to perform password reset.
For example, an IdP which knows a user’s mobile phone number can send that user an SMS text message with a new password when the user (through some self-service portal) indicates that he or she forgot the original password. This would degrade the security of the whole to just single factor authentication.
Please note that a second authentication factor like SMS should never be used for password reset in situations where it is also used for additional identity assurance in the context of SURFconext Strong Authentication.