Het proces waarin een fysieke persoon gelinkt wordt aan zijn digitale identiteit en zijn authenticatiemiddels is cruciaal om identiteitsfraude tegen te gaan. SURFconext Sterke Authenticatie is daarom zo ontworpen dat vastgesteld kan worden dat:
- Een persoon met bepaalde attributen bestaat, en dat deze attributen voldoende zijn om een persoon uniek te identificeren
- De gebruiker wiens token geregistreerd wordt, inderdaad is wie hij zegt te zijn.
Registratie proces
Het registratieproces van tokens (SMS, Tiqr, YubiKey) is op hoofdlijnen als volgt opgezet:
- Allereerst logt de gebruiker in op een Registratieportal met zijn instellingsaccount (username/password). In deze registratieportal selecteerd de gebruiker zijn gewenste token (SMS, Tiqr of YubiKey), bewijst hij via e-mailverificatie dat de geauthenticeerde gebruiker is die deze aanvraag doet en bewijst hij met een authenticatie dat hij controle heeft over het token. De gebruiker ontvangt daarna een activatiecode per e-mail.
- Vervolgens gaat de gebruiker fysiek langs bij een Service Desk om zijn token te laten activeren door een geauthoriseerde medewerker (RA) op basis van de activatiecode de tokenregistratie van de gebruiker opzoekt in het systeem. Na een succesvolle authenticatie met het aangevraagde token en een succesvolle ID-controle, wordt het token voor de gebruiker geactiveerd.
De RA heeft 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.
- De RA-admin 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.
- Alle stappen van een RA en gebruikers in het uitgifteproces van SURFconext Sterke Authenticatie service worden gelogd. Logs worden bewaard zodat in geval van incidenten de nagegaan kan worden wat er wanneer tijdens tokenregistratie gebeurd is. (specify!)
Maatregelen voor correcte binding van token aan identiteit
Op verschillende plekken in het registratieproces zitten 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.). |
Gebruik SMS niet voor password reset!
Sommige instellingen gebruiken SMS ook als middel voor gebruikers om een password reset te doen. Gebruikers die een password reset aanvragen, bijv. via een self-service portal, ontvangen dan via SMS een nieuw wachtwoord. Een dergelijk scenario verlaagt echter de security SMS als tweede factor tot slechts een enkele factor.
SMS mag daarom nooit gebruikt worden voor password reset, wanneer SMS ook als authenticatiemiddel voor sterke authenticatie wordt ingezet.