Met een mobiele app inloggen op een mijnomgeving? Of met je socialmedia-account een ‘third-party application’ benaderen? Zo eenvoudig als dit voor de gebruiker is, zo complex zijn de protocollen die dit achter de schermen regelen. Hoe richt je als dienstverlener het proces van berichten, codes en tokens uitwisselen veilig in?
Wie inlogt op een online dienst, zet een complex radarwerk in gang. Dat proces kan er bij gebruik van een broker als volgt uitzien:
- De gebruiker voert zijn gebruikersnaam en wachtwoord in voor authenticatie bij de identityprovider.
- De broker koppelt vervolgens een autorisatiecode van de identityprovider terug naar het apparaat van de gebruiker dat reageert met het verzoek om een access token te sturen.
- Met deze token kan de gebruiker de gewenste resources (zoals de accountgegevens) benaderen.
Ruimte voor hackers
Er zijn meerdere protocollen die een loginproces in goede banen kunnen leiden, waaronder de Security Assertion Markup Language (SAML). Met name in het groeiende ‘mobiele domein’ zien we dat het OpenID Connect-protocol steeds vaker wordt gebruikt. Dit protocol is gebaseerd op de OAuth 2.0-specificatie.
De populariteit van OAuth en OpenID Connect heeft een keerzijde: voor hackers wordt het aantrekkelijker om misbruik te maken van deze protocollen. Zo verspreidden Russische hackers in 2017 een valse veiligheidswaarschuwing, zogenaamd afkomstig van Google. In de melding riepen de hackers de slachtoffers op om ‘Google Defender’ te installeren. Wie op ‘Toestaan’ klikte, droeg echter zijn OAuth-tokens over aan de hackers. De aanvallers hadden vervolgens zonder wachtwoord toegang tot het Google-account van het slachtoffer.
Al in 2014 waarschuwde een student uit Singapore voor een gat in OAuth en OpenID Connect, door hem ‘Covert Redirect’ genaamd. Door de kwetsbaarheid was het mogelijk om argeloze websurfers via een geposte link op bijvoorbeeld Facebook een pop-up te tonen die om autorisatie vraagt. Het slimme hieraan was dat het slachtoffer de legitieme url van een bekende website te zien kreeg. Na autorisatie van de app kwamen de data van de gebruiker echter niet bij de legitieme website terecht, maar bij de aanvaller.
Vijf aandachtspunten
Het risico van OAuth en OpenID Connect schuilt in de complexiteit van deze protocollen. Een veilige implementatie vereist veel kennis en aandacht. Deze volgende vijf tips kunnen dienstverleners helpen bij een veilige implementatie van OpenID Connect.
Verbied ‘implicit flows’. Er zijn meerdere manieren om OpenID Connect te benaderen. Eén daarvan is de ‘implicit flow’. De gebruiker identificeert zichzelf bij de identityprovider en ontvangt direct de toegangscodes. De autorisatiestap en het verzoek tot een toegangscode worden dus overgeslagen.
Dit ‘verkorte proces’ op een mobiele apparaat is echter niet zonder risico’s. Malafide applicaties kunnen access tokens onderscheppen of de gebruiker wordt gedwongen z’n credentials in te vullen in de applicatie zelf.
Dwing PKCE af op mobiele devices. Een gangbare ‘flow’ is de ‘Authorization Code Grant Flow’. Een gebruiker logt in waarna de client een autorisatiecode ontvangt en ‘secrets’ zoals wachtwoorden of geheime sleutels stuurt naar bijvoorbeeld de Connectis Identity Broker. Die koppelt vervolgens een access token terug. Deze aanpak werkt echter niet voor native apps die geen unieke secrets kunnen hebben.
Proof Key for Code Exchange (PKCE) biedt hiervoor een oplossing. PKCE introduceert een secret dat door de aanroepende applicatie is gecreëerd en dat door de autorisatieserver kan worden geverifieerd. Dit geheim wordt de ‘code verifier’ genoemd. Zonder die code verifier kan een aanvaller een onderschepte autorisatiecode niet inwisselen voor een access token. Niet verwonderlijk dat de Connectis Identity Broker toepassing van PKCE bij mobiele applicaties afdwingt: dit maakt het risico op misbruik aanzienlijk kleiner.
Beveilig tokens en secrets. Aanvallers die de beschikking hebben over secrets en access tokens kunnen hier gevaarlijke dingen mee doen. Zo kunnen ze met een access token inloggen uit naam van iemand anders, of met een secret een phishingaanval uitvoeren.
Het is dus belangrijk dat uitgewisselde tokens worden opgeslagen in een goed beveiligde database. Zaken als toegangscontrole, de fysieke beveiliging en encryptie van de data moeten op orde zijn. Maar denk ook aan het automatisch wissen van tokens, op gezette tijden of als een account wordt verwijderd.
Maak gebruik van een broker. Het gebruik van een broker levert op het gebied van security meerder voordelen op. Is een identityprovider bijvoorbeeld gehackt, dan kan de broker de verbinding met de getroffen provider verbreken. Op het moment dat gebruikers inloggen, leidt de broker ze naar een andere identityprovider.
Schakel de juiste hulp in. Een correcte implementatie van OpenID Connect is een complexe aangelegenheid. En die implementatie is eigenlijk ook nooit ‘af’. Nieuwe dreigingen kunnen er altijd weer voor zorgen dat aanpassingen nodig zijn. Dan is het fijn als een gespecialiseerde partner die zorg uit handen neemt.
