Het proces waarin een fysieke persoon gelinkt wordt aan zijn digitale identiteit en zijn authenticatiemiddels is cruciaal om misbruik en 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 selecteert de gebruiker zijn gewenste token (SMS, Tiqr of YubiKey), bewijst hij via e-mailverificatie dat hij inderdaad 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). De RA logt middels sterke authenticatie in bij de RA Managementportal. Daar zoekt de RA de tokenregistratie van de gebruiker op in het systeem op basis van de activatiecode die de gebruiker mee brengt. Na een succesvolle authenticatie met het aangevraagde token door de gebruiker en een succesvolle ID-controle, wordt het token voor de gebruiker geactiveerd.
- De RA-admin die RA-rechten kan delegeren aan andere gebruikers, wordt tijdens een bootstrap procedure door een SURFnet-medewerker aangemaakt. Om dit te kunnen doen zal deze RA-admin een YubiKey moeten aanvragen via de Registratieportal op dezelfde manier waarop een normale gebruiker dit zal doen.
- 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.
Maatregelen voor correcte binding van token aan identiteit
Wanneer je sterke authenticatie gebruikt om toegang tot online diensten te beveiligen moet je er op kunnen vertrouwen dat een token alleen aan de juiste gebruiker gekoppeld kan worden. SURFconext Sterke Authenticatie heeft verschillende maatregelen genomen in zowel de architectuur als infrastructuur om eventuele risico's te minimaliseren.
| Risico | Omschrijving | Controlemaatregelen |
|---|---|---|
| Impersonation | De aanvrager claimt de ideniteit van iemand anders, bijvoorbeeld met gestolen credentials. | De combinatie van verschillende controlemaatregelen zorgen er voor dat dit niet mogelijk is: federated login, e-mail verificatie, activatiecode, en face-to-face ID-controle door een RA. |
| Security van de infrastructuur | Gebrek aan of slechte implementatie van security maatregelen kunnen de betrouwbaarheid van de registratie ondermijnen. | In de infrastructuur zijn de nodige securitymaatregelen getroffen. Denk aan: scheiding van rollen, opslaan van audit logs etc. Een security audit op de softwarecode en infrastructuur is voor live-gang van de dienst uitgevoerd, om objectief vast te laten stellen dat de dienst geen securitylekken heeft. |
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.