In dit artikel beschrijven we veelvoorkomende manieren om de indentiteit van een gebruiker vast te stellen. Binnen Multi Factor Authenticatie worden minstens twee manieren gebruikt. Meestal meldt een gebruiker zich aan met gebruikersnaam en wachtwoord en wordt een tweede manier gevraagd als extra verificatie. Deze manieren worden ‘factoren’ genoemd.

Factoren zijn ingedeeld in drie categorieën:

Als factoren gecombineerd worden, dan is het best practice om facturen uit verschillende categorieën te combineren en dus niet twee facturen uit de categorie “weten”.

Wachtwoord

Het wachtwood is de traditionele manier van verificatie van de identiteit van een gebruiker. Van oudsher identificeert de gebruiker zich met een gebruikersnaam en verifieert de identiteit door de invoer van iets dat allen bekend is bij de gebruiker en gevalideerd kan worden door het systeem.

Zekerheid op basis van een wachtwoord kan alleen gegeven worden als het wachtwood regelmatig gewijzigd wordt en voldoende complex is. Dan nog is er grote afhankelijkheid van het veiligheidsbewustzijn en de discipline van de gebruiker.

Wachtwoorden kunnen gestolen, geraden en gedeeld worden, waardoor het vertrouwen op alleen deze factor bij gevoelige transacties ontraden wordt. Het is gangbaar om het wachtwoord te combineren met ander factoren. Ook is ‘passwordless’ in opkomst, waarbij het wachtwoord wordt vervangen door een andere factor voor toegang tot eenvoudige transacties.

Veiligheidsvraag

Een veiligheidsvraag wordt meestal niet toegepast binnen de ‘flow’ voor aanmelding, maar vaker binnen flows voor resetten van het wachtwoord. Net zoals het wachtwoord is dit een kennis-factor (’weten’). Het veiligheidsniveau is minimaal en de toepassing is met name om ongewenste wachtwoordwijzigingsprocessen te voorkomen.

Authenticator Apps

Authenticator apps zijn een veelgebruikte extra verificatie. Meestal wordt de TOTP (’Timebased one-time password’) gebruikt. De app wordt gekoppeld aan het systeem door de uitwisseling van een geheim. Iedere 30 seconden wordt op basis van de tijd en het gedeelde geheim een nieuw wachtwoord gegenereerd. Het systeem heeft zekerheid dat de betreffende installatie van de app het wachtwoord heeft uitgegeven en omdat de wachtwoorden een hele korte levensduur hebben kunnen ze weinig kwaad als ze gestolen, gedeeld of gelekt zijn.

Een veelgebruikte authenticator app is de Google Authenticator, maar de grote platforms maken hun eigen apps, zoals de Microsoft Authenticator. Zolang ze de TOTP standaard gebruiken kunnen ze met de meeste systemen overweg.

Okta Verify

Okta maakt ook haar eigen authenticator app. Deze kan uiteraard met het Okta platform gebruikt worden, maar ook met andere systemen omdat de TOTP standaard toegepast wordt. In combinatie met het Okta platform is Okta Verify zeer gebruikersvriendelijk omdat ook de mogelijkheid tot ‘push’ gegeven wordt. Dit betekent dat bij het inloggen automatisch een push-bericht naar de app wordt gestuurd en in de app slechts op een Bevestigen-knop gedrukt hoeft te worden om de inlogpoging af te maken.

Branded Authenticator App

Binnen Consumer Identity and Access Management (CIAM) is het gebruik van een eigen Authenticator App aantrekkelijk. Vaak worden portalen al vergezeld van een mobiele app. De verificatie van de identiteit in een inlogpoging is dan slechts een kleine toevoeging binnen de app.

Okta stelt voor dit doel een ‘System development kit’ (SDK) beschikbaar waarmee organisaties verificatie kunnen integreren in hun eigen mobiele app of eenvoudig een eigen authenticator app kunnen ontwikkelen. De mogelijkheid van ‘push’ is dan ook in dit scenario aanwezig, waardoor een uiterst gebruikersvriendelijke ervaring geboden kan worden.

E-mail

Het sturen van een inlogcode via email is een laagdrempelige manier om de identiteit van de gebruiker te verifiëren. Er gaat een bepaalde mate van zekerheid vanuit dat de gebruiker ook exclusief toegang heeft tot zijn/haar email. Gegarandeerd is dat echter niet en er bestaat een afhankelijkheid met de wijze waarop toegang tot email is beveiligd.

SMS

Omdat vrijwel iedereen over de mogelijkheid beschikt om SMS-berichten te ontvangen, is dit een breed geaccepteerde manier om inlogcodes te ontvangen. Wat betreft het zekerheidsniveau ligt het het in toenemende mate onder vuur. Zo zijn er voorbeelden van mobiele telecomoperators die hun processen dusdanig niet op orde hadden dat derden telefoonnummers konden overnemen. Dit fenomeen heet sim-swapping. Daarnaast worden in toenemende mate e-sims gebruikt, waarbij het telefoonnummer niet meer gebonden is aan een fysiek object, maar aan een digitaal gegeven welke vaak niet beter beveiligd wordt dan met een wachtwoord.

Telefoon

Inlogcodes kunnen ook uitgesproken worden in een telefoongesprek. Wanneer dit telefoongesprek middels een mobiel nummer plaatsvindt, dan spelen dezelfde bezwaren als gesteld bij SMS. Als echter een vaste telefoonaansluiting wordt gebruikt, dan kan meer zekerheid gegeven worden.

Hardware tokens

Hardware tokens zijn fysieke objecten die inlogcodes genereren. Gebruik van hardware tokens biedt de meeste zekerheid, afhankelijk van het proces waarmee de tokens worden uitgereikt en de discipline van de gebruiker.

Het gebruiksgemak van hardware tokens is afhankelijk van het type. Zo zijn er token waarvan de inlogcode overgetypt moet worden, maar zijn er ook tokens die continue in de computer van de eindgebruiker aanwezig moeten zijn via USB. Tenslotte zijn er tokens die verbinding maken via NFC en in de buurt van een computer of telefoon gehouden moeten worden.

TouchID/FaceID

TouchID/FaceID is de enige biometrische verificatie. Er wordt gebruik gemaakt van de herkenning van fysieke kenmerken. Van de gebruiker, zoals de vingerafdruk bij TouchID of de gezichtscompositie bij FaceID.

Er bestaat een grote afhankelijkheid van het mobiele apparaat van de eindgebruiker en is zodoende niet altijd inzetbaar. Hardware tokens zijn soms ook voorzien van vingerafdrukherkenning.