Wat alle UX-designers zouden moeten weten over inloggen en beveiliging

In 2013 werden verschillende Nederlandse retailbanken het slachtoffer van DDoS-aanvallen. En dit jaar werden Kickstarter en Skype aangevallen door hackers. Dit waren niet de enige incidenten. Naarmate online dienstverleners hun UX maturity verhogen, ontwikkelt ook de gemeenschap van cybercriminelen zich sterk. Tot de digitale vandalen behoren nu internationale spionnen, cyberstrijders in uniform en gepromoveerde criminelen, rechtstreeks uit een Bond-film (Bron: “Why security without usability leads to failure“, Forbes (2013)).

Bovendien bewegen technologische infrastructuren zich steeds verder buiten (relatief veilige) beveiligingsmuren. Data en software worden onderdeel van de cloud en zijn toegankelijk via een reeks apparaten. We moeten ons steeds vaker identificeren om toegang te krijgen tot ons eigen digitale eigendom. En we willen overal en altijd eenvoudig en snel toegang hebben tot onze gegevens. Maar we zijn niet de enigen.

Nu hoor ik je denken “Dat is allemaal heel zorgelijk, maar waarom is dat mijn probleem als UX-designer? We hebben enterprise-architecten en beveiligingsmedewerkers om dit probleem op te lossen.”

Donald A. Norman heeft een andere kijk op deze kwestie. Zijn slogan is: "Hoe veiliger je iets maakt, hoe minder veilig het wordt." Waarom? Wanneer beveiliging een sta-in-de-weg wordt, ontwikkelen verstandige, goedbedoelende, toegewijde mensen hacks en workarounds die de beveiliging omzeilen. Denk aan alle wachtwoorden op Post-its die op je monitor geplakt zijn, of je huissleutels onder de deurmat. Gebruiksvriendelijkheid en gebruikerservaring zijn belangrijke pijlers van een veilig en veilig internet (Bron: “When security gets in the way“, Donald A. Norman (2010)).

Daarom is het belangrijk dat UX-designers basiskennis hebben van beveiligingsgerelateerde processen en terminologie. Het is tijd om verantwoordelijkheid te nemen en de (digitale) wereld veiliger te maken, ook vanuit UX-perspectief.

Of iemand toegang krijgt tot specifieke data of niet, wordt gespecificeerd in het toegangscontroleproces, dat is gebaseerd op drie stappen:

1. Identificatie ("Ik ben persoon A")
2. Authenticatie ("Het is waar, u bent persoon A"), en…
3. Autorisatie ("Ik zie dat u persoon A bent, met toegang tot B.")

Laten we bijvoorbeeld zeggen dat ik wil inloggen op LinkedIn. Ik voer mijn gebruikersnaam (identificatie) en wachtwoord (authenticatie) in. Dan heb ik wel toegang tot LinkedIn, maar niet tot de Premium-diensten, want daar ben ik niet geautoriseerd voor. Je identificeert je vaak met een gebruikersnaam. In plaats daarvan worden steeds vaker biometrische kenmerken als vingerafdruk, irisscan of tokens (smartcard, certificaat) gebruikt als identificatiemiddel. Na identificatie moet u enig bewijs van uw identiteit overleggen om u te authenticeren. In de offline wereld wordt vaak een paspoort gebruikt voor authenticatie. In de digitale wereld zijn er traditioneel drie soorten bewijs voor authenticatie:

1. iets dat je weet
2. iets dat je bezit, en…
3. iets dat je bent.

‘Iets wat je weet’ is bijvoorbeeld een wachtwoord of een geheime zin. Een hacker zal vaak iemands identiteit proberen over te nemen door een wachtwoord te raden of te kraken. Om dit te voorkomen worden vaak complexe regels toegepast op wachtwoorden. Met alle mogelijke gevolgen, zoals eerder besproken.

‘Iets dat je bezit’ is een item dat het authentiserende systeem heeft opgeleverd. Dat kan een bepaald type token zijn, of een item waarvan het systeem heeft gecontroleerd dat het in uw bezit is, bijvoorbeeld uw mobiele telefoon.

‘Iets dat je bent’ is een uniek persoonskenmerk dat is opgeslagen in een authenticatiedatabase. Bijvoorbeeld uw vingerafdruk, stem, een scan van uw iris of gezicht.

Zoals u wellicht is opgevallen, kunnen identieke soorten items of kenmerken zowel voor identificatie als voor authenticatie worden gebruikt. Een item of kenmerk dat wordt gebruikt voor identificatie kan echter niet ook worden gebruikt voor authenticatie binnen hetzelfde proces voor toegangscontrole.

Single factor authenticatie (SFA) is identificatie gecombineerd met één enkel bewijsstuk. Bij meervoudige authenticatie (MFA) worden meerdere bewijsstukken uit verschillende categorieën (kennis, eigendom of kenmerk) gebruikt. Een login met gebruikersnaam, wachtwoord (bewijs: kennis) en sms-code (bewijs: eigendom) is een voorbeeld van meervoudige authenticatie of tweefactorauthenticatie (2FA).

Bij adaptieve authenticatie wordt een vierde type of factor van bewijs voor authenticatie toegevoegd: context. Context omvat parameters zoals tijd, locatie, apparaat, browser en applicatie. Op individueel niveau worden beveiligde profielen opgesteld met daarin een of meer contextitems. Deze profielen worden samengesteld door een zogenaamde risk engine. Nadat de gebruiker met een enkele factor is ingelogd, wordt zijn context gecontroleerd aan de hand van een of meer beveiligde profielen. Als er een match is, wordt de context geaccepteerd als de tweede authenticatiefactor. Zo niet, dan zal de gebruiker de tweede factor actief moeten authenticeren.

Zo doe ik elke zondagmiddag mijn betalingen via internetbankieren. Ik log in met mijn browser. Omdat het een terugkerend patroon is, worden de contextitems tijd (zondagmiddag), locatie (IP-adres) en browser (IE) opgeslagen als een beveiligd profiel. Ik hoef de tweede factor niet actief te authenticeren. Mijn gebruikersnaam en wachtwoord zijn voldoende.

Naast profielen op individueel niveau kunnen organisaties specifieke inhoudsitems of acties toewijzen om altijd aanvullende authenticatie te vereisen. Denk bijvoorbeeld aan inloggen voor internetbankieren van buiten uw continent (item), of het uitvoeren van een betaling (actie).

Nu we weten hoe we in één omgeving kunnen inloggen, is het interessant om kort in Single Sign On (SSO) te duiken. Bij SSO logt een gebruiker slechts één keer in om toegang te krijgen tot alle omgevingen binnen dezelfde SSO-set. Wanneer de gebruiker uitlogt, wordt hij uitgelogd uit alle omgevingen binnen dezelfde SSO-set.

SSO is gebaseerd op het principe van ‘Federated Identity Management’ (FidM), dat de identiteit en toegangsrechten van gebruikers voor verschillende organisaties en platformen beheert. Dit wordt steeds belangrijker door de decentralisatie van ICT-infrastructuren, zoals we eerder aangaven. SSO omvat het beheer van identiteit, maar niet van toegangsrechten (autorisatie).

Wat gebeurt er eigenlijk met SSO? Van elke omgeving waarin u inlogt, is uw digitale identiteit bekend. Zo herkent de ene omgeving mij als ‘Wprins’, terwijl de andere ‘Sm@rtyP@nts83’ gebruikt voor herkenning. Het is duidelijk dat beide omgevingen niet weten dat dezelfde persoon achter beide aliassen zit. Wat voor SSO dus nodig is, is een verbinding tussen beide digitale identiteiten in de verschillende omgevingen. Vanuit technisch oogpunt zijn er verschillende oplossingen die in het domein van enterprise architecten liggen. Maar voor degenen die geïnteresseerd zijn in dit probleem, zoek gewoon eens naar SSO of 'Federated Identity Management'.

Om de zaken wat meer te verduidelijken, zijn er mogelijkheden zoals OpenID (of vergelijkbaar Facebook Connect of Windows Live ID). Deze zijn niet hetzelfde als SSO. Deze oplossingen vergemakkelijken het gebruik van identieke inloggegevens voor afzonderlijke omgevingen (bijvoorbeeld inloggen in Runkeeper met Facebook Connect). In tegenstelling tot SSO moet je toch weer in elke afzonderlijke omgeving inloggen. Geen single sign on, maar same sign on.

Genoeg theorie voor nu, laten we een paar voorbeelden bekijken.

Retailbanken maken al lange tijd gebruik van multi-factor authenticatie. Een van die banken introduceerde in 1986 elektronisch bankieren met behulp van een papieren tokenlijst. Er zijn nog steeds mensen die van dergelijke lijsten gebruik maken.

Bij meerdere retailbanken logt u in op de online bankomgeving met een gebruikersnaam en wachtwoord – single factor authenticatie. Het uitvoeren van een transactie vereist een step-up authenticatie. Bijvoorbeeld door de juiste token uit de eerder genoemde papieren lijst in te voeren.

Ik herinner me dat ze tijdens mijn werk bij een Nederlandse retailbank (2012/2013) bezig waren met de implementatie van adaptieve authenticatie. Helaas ben ik niet op de hoogte van een daadwerkelijke implementatie ervan.

Er is maar één Nederlandse bank die tokens gebruikt (op papier en via sms). Alle andere retailbanken gebruiken een soort apparaat voor internetbankieren dat cijfers genereert. Tokenlijsten en apparaten zoals deze zijn beide voorbeelden van de bewijsfactor voor authenticatie – ‘Iets dat je bezit’.

In tegenstelling tot de internetbankieromgevingen gebruiken de mobiele apps van alle retailbanken een pincode om in te loggen. Voor deze apps geldt dat het apparaat waarop de app is geïnstalleerd, moet worden geregistreerd voordat de app kan worden gebruikt. Dit betekent dat de bank-apps daadwerkelijk multi-factor authenticatie uitvoeren: een pincode ('iets dat je weet') en het geregistreerde apparaat ('iets dat je bezit'). Vaak kun je zonder step up authenticatie maar een beperkt bedrag overmaken, omdat je al geauthenticeerd bent met twee factoren.

Momenteel werk ik aan een beveiligingsgerelateerd project voor een verzekeringsmaatschappij. In dit project wordt de zakelijke vereisten voor SSO gecombineerd met een wettelijke vereisten voor MFA. Of zoals onze overheid het verwoordde: “Voor elk type informatie moet er een passend slot zijn”. En dat is nu net het punt.

Terwijl getrapte authenticatie alleen wordt toegepast voor banktransacties, stelt het systeem voor om getrapte authenticatie te gebruiken wanneer de gebruiker toegang wil tot geheime informatie, wat als een bijkomend risico wordt gezien. Informatie zoals persoons-, financiële- en zorggegevens zitten helaas niet netjes bij elkaar, maar zijn verdeeld over verschillende pagina's in meerdere omgevingen in de SSO-set. Om frustratie te voorkomen, is het belangrijk dat gebruikers begrijpen wanneer en waarom meer authenticatie vereist is. Het doel is om een goede balans te vinden tussen veiligheid en een probleemloze inlogervaring. Een interessante uitdaging.

Dit artikel is slechts een deel van het volledige verhaal. Wil je meer weten, zoek dan op ‘Human Computer Interaction & Security’ (HCISec), een discipline die volledig aan het onderwerp is gewijd.

Inloggen, registreren en beveiligingsinstellingen zijn niet de kernfuncties van een product of website en krijgen daarom vaak minder aandacht dan andere functionaliteiten. Deze ondersteunende functies zijn echter essentieel voor het proces van veilige toegangscontrole. Besteed dus speciale aandacht aan de bruikbaarheid en gebruikerservaring van deze functies. Vaak zit ‘the devil in the details’.

Gelden bijvoorbeeld dezelfde beveiligingsregels voor alle inhoud en functies of juist niet? Denk aan een stapsgewijze authenticatie om een transactie in een internetbankierenomgeving uit te voeren. Begrijpt de gebruiker waarom aanvullende authenticatie vereist is? Misschien voor een transactie, maar wanneer je stapsgewijze authenticatie implementeert om toegang te krijgen tot specifieke inhoud (bijvoorbeeld toegang tot persoonlijke facturen van een zorgaanbieder), wordt het moeilijker. Als u authenticatie nodig heeft, moet dit altijd een conventionele gebruikersnaam en wachtwoord zijn. Momenteel hebben veel gebruikers een smartphone die gemakkelijke (maar niet noodzakelijkerwijs veiligere) methoden biedt om in te loggen. U kunt nu bijvoorbeeld inloggen door een pushbericht naar een geregistreerde smartphone te sturen, zodat de gebruiker alleen op OK hoeft te drukken. Dit is veel gemakkelijker dan het onthouden en invoeren van een permanent wachtwoord of een eenmalig wachtwoord.

Probeer uw (ontwerp)project op te splitsen in beveiligingsniveaus (enkelvoudig of meervoudig) en aanvullende authenticatiefactoren om de gebruiker een passende, begrijpelijke en probleemloze inlogervaring te bieden.