Is OpenID wel zo fantastisch?

Wie wil er nu honderd paswoorden en accounts bijhouden? Niemand toch? Of je gebruikt telkens hetzelfde paswoord. Knappe koppen denken natuurlijk wat verder en kwamen met een oplossing: OpenID. Ideaal, zo leek het. Eén paswoord/login combo onthouden en de rest gebeurt automagisch op elke site die OpenID ondersteunt.

Maar is OpenID wel zo fantastisch? De voornaamste kritiek op OpenID valt samen te vatten als deze: “On the Internet, nobody knows you’re a dog.” Of beter, het decentrale karakter van OpenID betekent verzwakte de sterkte de identiteit die je claimt. Meer hierover vind je hier.

Los van die discussies, heb ik zelf uit harde ervaring geleerd dat OpenID niet het nirvana betekent. Mijn kritiek is eerder technisch van aard en beperkt zich tot het protocol zelf. De laatste maanden heb ik mij gebezigd met een OpenID plugin voor WordPress. Dat betekende dus een OpenID consumer implementeren en die koppelen met één van de API haken van WordPress. Om precies te zijn: in het wp-comments-post.php script. De OpenID specificatie leert ons dat alle oproepen tussen een consumer en een identity provider via HTTP GET requests moeten worden afgehandeld. Helaas hebben de makers van WordPress het bewuste script zo gepatched dat HTTP GET requests worden afgeblokt. Helaas betekent het ook meteen het afblokken van OpenID in comments op een propere manier. Ik kan via allerlei truken de nieuwe beveiliging omzeilen. Maar echt ideaal is dat niet.

Hadden de makers van WordPress die patch moeten doorvoeren? Vanuit het standpunt van beveiliging en anti-spam: zeker. Een script dat HTTP GET requests aanvaardt kan vrij gemakkelijk worden misbruikt. Zeker als het gaat om het dumpen van spam is er geen kunst aan om code te schrijven dat massaal HTTP GET requests afstuurt op onbeveiligde webscripts. Neen. Het probleem ligt in de OpenID specificatie. Die legt juist het gebruik van HTTP GET requests op en laat geen ruimte voor mogelijke alternatieven. In mijn ogen dwingt OpenID dus hier een mogelijk veiligheidsrisico af. Nochtans zijn er andere, betere alternatieven om data over HTTP door te sturen zonder gebruik te maken van de onveilige HTTP GET requests. Ik denk dan aan RPC protocollen zoals XML-RPC (er zit een XML-RPC module in WordPress!) en SOAP.

Persoonlijk sluit ik daarom dus liever mijn OpenID experiment voorlopig af en kijk ik de kat wat uit de boom vooraleer ik er verder mee ga.

4 replies

  • Een spamscript maken dat POST is niet veel moeilijker dan een dat GET requests uitvoert 😉

    Semantisch gezien voert OpenID ook exact GET requests uit, geen POST, er wordt enkel informatie opgevraagd van andere servers.

    Het commentaar verwerkscript van WP dient inderdaad wel enkel POST toe te laten.

    Een mogelijke oplossing voor je probleem: een tussenpagina gebruiken die zichzelf POST. Iets als

    user verstuurt form -> OpenID gevraagd? -> Redirect naar OpenID provider page, met als return URI http://mijnblog.com/tussenpagina.php?name=abc&comment=blabla, dan in tussenpagina GET variabelen ophalen, in een plaatsen en dat POST’en via JavaScript.

    Niet helemaal netjes natuurlijk…

    Andere mogelijkheid:
    user verstuurt comment -> openid gewenst? sla comment text op in session, redirect naar openid login page, return naar pagina van comment form, form al ingevuld adhv session data, javascript post form, en gedaan.

    ’t Is ook niet zo netjes, maar zo direct zie ik geen andere oplossing (er zal er wss wel een zijn hoor…)

  • Mja, dat klopt. Ik heb met die idee zitten spelen. Ik ben er anders gezegd wel geen fan van om scripts in de wp-content/plugins folder rechtstreeks uit te voeren. Ik geloof dat dat zelfs een security issue is! Idealiter zitten daar scripts met methoden die veilig via de haken in de normale WP scripts worden uitgevoerd.

    Het stoort me dat er betere oplossingen voor de communicatie tussen identity provider en consumer, bestaan die niet worden benut. In dit geval krijg je nu een situatie waarbij restricties op de input door de eindgebruiker aan de consumer, de communicatie tussen identity provider en consumer sterk beperkt.

  • Hoe zou je dan authenticatie doorvoeren gebruik makend van directe communicatie tussen consumer en provider? (mss best via mail discussiëren, aangezien comment replies checken nog steeds een van die heikele puntjes van blogs is)

  • Best wel. 🙂 Wel, ik ben gisterenavond nog maar tot dat besef gekomen. Ik zou er even over moeten kunnen nadenken.

    Op zich is er met niks mis met het OpenID protocol. Wel met de onderliggende technologie die voor het transport wordt gebruikt.

Commentaar is gesloten