Webservice authenticatie ontwerp

[Remco]

Wij zitten met een ontwerp probleem voor een webservice. Misschien dat één van jullie enig idee hebben hoe we het zouden kunnen oplossen.

Huidige situatie;
Momenteel hebben externe klanten de mogelijkheid om gegevens te bekijken via een webinterface. Dit gaat in combinatie met een digipass key. Deze situatie werkt goed, echter is dit niet te koppelen aan een backoffice pakket van de klant zelf.

Wenselijke situatie;
Wij willen dezelfde informatie ook aanbieden als een webservice zodat de externen de mogelijkheid hebben hun backoffice programmatuur hierop te kunnen aansluiten. Deze aansluiting moeten ze dan vanuit hun backoffice programma zelf regelen met hun eigen ontwikkelaar.
Uiteraard willen we dit op een degelijke manier beveiligen. En daar zit een beetje het euvel. We weten niet goed welk mechanisme we hiervoor zouden kunnen gebruiken.

Bedachte oplossingen;
Het liefst doen wij dit door alleen bepaalde ip-adressen toegang te geven aan de webservice, maar helaas gaat dat hier niet op. Statische ip-adressen zijn niet mogelijk op reguliere ADSL en Cable aansluitingen. Wil je wel een statisch ip adres hebben, dan ben je genoodzaakt over te stappen naar een SDSL aansluiting, die als eerste instap een € 450,- per maand kost. Dit is dus helaas een optie die we niet zo kunnen verkopen.

Verder hebben we nog gedacht om per klant een certificaat uit te reiken voor authenticatie. Echter dit weerhoudt de klant of ontwikkelaar er niet van het certificaat te exporteren en op een andere machine te installeren. En dat willen wij voorkomen.

Ook gedacht is aan authenticatie door middel van username/password. Dat kan, maar weer weerhoudt ook de klant of ontwikkelaar er niet van om deze gegevens op andere plekken te gaan gebruiken.

De vraag;
Wie weet een authenticatie oplossing die wij kunnen implementeren met de volgende eisen;
- Het moet mogelijk zijn om per klant de toegang te kunnen ontzeggen.
- We willen zeker zijn dat degene die inlogt, ook degene is waaraan de toegang is verleend.
- Het moet implementeerbaar zijn in hun eigen backoffice pakket. Een oplossing met digipass keys o.i.d. is dus niet wenselijk.

Het zijn medische gegevens die de klant opvraagt, dus is het van belang dat dit op een degelijke manier gebeurd.

Wie o wie kan ons een beetje de juiste richting opsturen?

[Boss]

Ik denk dat je dit technisch niet kan oplossen, omdat je geen controle over de client hebt. Iedereen moet een client kunnen maken voor jouw service, maar tegelijkertijd wil je verbieden dat diezelfde client op meerdere locaties oid gebruikt kan worden.

Kan je niet per request gaan afrekenen? Of in de voorwaarden opnemen dat de key niet overdraagbaar is en dan gaan monitoren in de logs of er geen requests vanaf verschillende plekken komen?

[Remco]

Daar waren we al bang voor dat het technisch niet kon...

Wat bedoel je met afrekenen per request? Je bedoelt daar echt factureren mee? Zo ja, dan zal het geen oplossing zijn. Wij moeten de service gratis beschikbaar stellen volgens de wet. Dus dat zal niet gaan.

Monitoren in logs zou kunnen, maar aangezien iedereen dynamische adressen heeft, en deze daadwerkelijk iedere dag veranderen zal dat een heidens karwei worden vrees ik.

[DRaakje]

Koppelen aan IP, en klant het laten wijzigen als het veranderd? Of anders een een controle op IP er niet binnen x dagen van meer dan 1 ip ingelogd kan worden?


ik zie nu je commentaar van iedere dag een ander IP. Certificaat bijhouden wie er verbinding maakt met welk IP, als er ingelogd word met IP X 10 min later met IP Y en daarna weer IP X dan lijkt me dat er iets niet klopt.

[Voor 41% gewijzigd door DRaakje op 24-05-2012 17:02]

[Remco]

DRaakje schreef op donderdag 24 mei 2012 @ 17:00:
Koppelen aan IP, en klant het laten wijzigen als het veranderd? Of anders een een controle op IP er niet binnen x dagen van meer dan 1 ip ingelogd kan worden?

Nee, dat is geen oplossing. We hebben hier zo vaak verbindings problemen dat men een modem moet resetten. Krijg je weer een ander ip adres. En je wilt niet de eindgebruikers dat moeten laten doen.
Controleren op IP zal ook niet gaan, wat als iemand anders het ip kreeg wat een andere klant de dag ervoor had?

[Glashelder]

Je zou kunnen overwegen om te werken met een combinatie gebruikersnaam/wachtwoord en die digipass key. Bij een eerste login poging wordt er gevraagd om de code van de digipass key. Hierna koppel je het account van de gebruiker aan het gebruikte IP adres.

Verandert het IP adres dan dient men opnieuw in te loggen met behulp van de digipass key.

Als de ontwikkelaars van het backoffice pakket van de klant dit niet kunnen implementeren (waarom kunnen ze dit niet?) dan kun je overwegen om gewoon de toegang tijdelijk te ontzeggen. Na het verifiëren herstel je de toegang weer. Ik zie het probleem niet zo om de gebruiker op een website zijn account te laten verifiëren. Alle belastingpakket die aangiftes versturen (uitgezonderd pakketen met BAPI certificaten) doen dat op een soortgelijke manier want die sturen je ook door naar de DigID website

Over het algemeen geld hoe beter de beveiliging hoe ongebruiksvriendelijker. Maar je schrijft dat het over medische gegevens gaat dus in dit geval gaat privacy en de veiligheid van de gegevens duidelijk boven gebruikersgemak.

[Boss]

Wel apart dat gebruikers vaak een nieuw IP krijgen. Bij de meeste providers (ook albieden ze geen vast IP aan) zal het IP toch niet zo vaak meer wijzigen?

Je kan ookaaneen bank-achtige oplossing werken: gebruikers krijgen dan een stukje hardware dat een key genereerd. Of als ze willen inloggen stuur je een code/link naar een e-mail adres dat vooraf is overeengekomen. Die link blijft dan een paar minuten geldig. Of een (papieren) lijst met codes, zoals de TAN codes van de ING?

[MikeN]

Uh, als het hier om medische gegevens gaat, zou je dan niet iemand met verstand van dit soort beveiligingen er naar laten kijken?

IP adressen zijn geen authenticatiemiddel, daar kan iedere gebruiker achter zitten. Ik snap je probleem met client certificaten niet wat dat betreft. Verder lijkt het mij goed om onderscheid te maken tussen de applicatie en de gebruiker van de applicatie. Je huidige voorgestelde oplossingen authenticeren de applicatie, niet de gebruiker (wat je huidige digipass oplossing wel doet).

[Herko_ter_Horst]

Certificaten zijn de manier om applicaties zich bij elkaar te laten autoriseren (let op dat dit twee kanten op moet: jullie server moet weten dat het om een vertrouwde client gaat, maar de client moet ook weten dat hij met de juiste server communiceert).

M.b.t. het kopieren van certificaten: wat is de reden dat je kopiëren hiervan wilt voorkomen? Wat is het probleem als dat toch gebeurt?

[F_J_K]

Inderdaad. Bedenk: als iemand diep genoeg in het klantsysteem kan komen om het certificaat te kopieren (en slim genoeg is om te zorgen dat het jou niet opvalt dat het certificaat 2x tegelijk wordt gebruikt), zal diegene ook enige andere authenticatie behalve fysiek langsfietsen kunnen omzeilen. Iets meer veiligheid geeft misschien de combi met een fysieke dongle in de server (bijv. eentje om naar jouw VPN in te bellen) maar dat lijkt me niet praktisch..

Begrijp ik goed dat je een maatwerk service gaat maken en niet een of andere industriestandaard volgt? En dus ook iedere backofficeleverancier gaat koppelen met jouw dienst. Denk alvast even na over je versiebeheer, maak er niet te veel

Remco schreef op donderdag 24 mei 2012 @ 16:19:
- Het moet mogelijk zijn om per klant de toegang te kunnen ontzeggen.

Bedoel je per persoon/medewerker of per klant/bedrijf? Dat eerste is nogal veel moeilijker want vereist dat ieder systeem dat ook kan doorgeven - en dat iedere geautoriseerde medewerker bekend is bij jou (en je het ook weet als die opstapt). Maar dat is meer een organisatorisch probleem.

[ieperlingetje]

In het geval van de dynamische IP adressen, kun je die niet koppelen aan een dns update tool (zoals bijv. dyndns doet) en dan een lijst aanmaken van toegestane domeinen? Met behulp van reverse lookups kun je dan controleren of het om een geldig IP gaat of niet.

[RobIII]

Het feit alleen al dat er wordt overwogen iets met een IP te doen (anders dan logging en de mogelijkheid 't te bannen wegens brute-force attacks, DDOS'es etc.) maakt me triest...

[Voor 3% gewijzigd door RobIII op 24-05-2012 22:39]

[Glashelder]

Leg eens uit dan? Als enige maatregel is het waardeloos, ben ik met je eens. Maar als extra maatregel kan je genoeg dingen met een IP adres. Als een IP midden in een sessie wijzigt of er zijn meerdere sessies actief van verschillende adressen, dan is er iets niet pluis.. Als je daarnaast ook nog die digipass inzet heb je 't redelijk dicht staan lijkt mij.

[F_J_K]

Glashelder schreef op vrijdag 25 mei 2012 @ 01:06:
iets niet pluis.. redelijk dicht staan lijkt mij.

Dat zijn termen die inderdaad toch wel eng zijn in combinatie met medische gegevens waar het toch wel een faillisement en een krantenbericht of twee betekent als ze gaan rondslingeren

[Herko_ter_Horst]

IP adressen zijn wel bruikbaar voor de paar zaken die jij noemt, om achteraf misbruik (of verdenking daarvan) vast te stellen, maar niet als authenticatiemechanisme. Dat is waar over gesproken werd.

In plaats van - of in combinatie met - certificaten kun je OAuth overwegen. Dit systeem wordt door steeds meer webservices gebruikt (o.a. Google maakt hier gebruik van voor alle APIs).

In het kort werkt dit als volgt:
1. Jij legt een registratie aan van toegestane client-apps, waarin je per app een id en een secret (dit zou een certificaat kunnen zijn) vastlegt.
2. Bij het opstarten van de client-app verifieer je de app eenmalig door een gebruiker te laten inloggen. De client-app krijgt dan een autorisatietoken terug met een beperkte geldigheidsduur.
3. Met dit autorisatietoken kan de client-app vervolgens een sessie-token opvragen en optioneel een refreshtoken.
4. Hiermee kan de applicatie z'n werk doen (met het refresh-token kunnen zonder tussenkomst van een gebruiker nieuwe sessie-tokens worden aangevraagd).

Zie: http://oauth.net/documentation/getting-started/

[Yarno]

Kan je niet iets met het MAC adres?
Tuurlijk is dit ook weer te klonen, maar misschien een combinatie van IP+MAC adres?

[Anoniem: 26306]

Yarno schreef op vrijdag 25 mei 2012 @ 08:00:
Kan je niet iets met het MAC adres?
Tuurlijk is dit ook weer te klonen, maar misschien een combinatie van IP+MAC adres?

Vertel eens hoe die webservice aan het mac-adres komt.

[Boss]

Anoniem: 26306 schreef op vrijdag 25 mei 2012 @ 08:07:
[...]
Vertel eens hoe die webservice aan het mac-adres komt.

Door de service niet in een webserver te hangen maar op een hoger niveau te zetten, met bijvoorbeeld zijn eigen ingebouwde webserver.

Niet dat dat handig is, maar onmogelijk is het niet :-)

[Anoniem: 26306]

Boss schreef op vrijdag 25 mei 2012 @ 09:08:

Door de service niet in een webserver te hangen maar op een hoger niveau te zetten, met bijvoorbeeld zijn eigen ingebouwde webserver.

Het mac-adres van de client Sjaak.

[Paul]

Herko_ter_Horst schreef op vrijdag 25 mei 2012 @ 01:30:
IP adressen zijn wel bruikbaar voor de paar zaken die jij noemt, om achteraf misbruik (of verdenking daarvan) vast te stellen, maar niet als authenticatiemechanisme. Dat is waar over gesproken werd.

Iemand die vanaf het verkeerde IP-adres komt kan zich niet eens authenticeren; dat maakt het mijns inziens deel van het beveiligingsproces?

Zelfs al krijg je het ip-adres gespooft _en_ komt het antwoord bij je terug dan zit er in dat component al een stukje security through obscurity. En voordat mensen alleen die 3 woordjes lezen en daar op triggeren, merk op dat ik niet zeg dat het enige is, enkel dat dit het voor een kwaadwillend persoon moeilijker maakt. Als iemand die gegevens eenmaal heeft is er één horde genomen; je maakt echter de pool aan potentieel kwaadwillende personen wel een stuk kleiner.

[eamelink]

Remco schreef op donderdag 24 mei 2012 @ 16:19:
Deze situatie werkt goed, echter is dit niet te koppelen aan een backoffice pakket van de klant zelf.

Dan lossen ze dat op. Juist zo'n hardware token als dit voldoet aan alle randvoorwaarden

[Equator]

Even buiten de box denkende:
Is het niet mogelijk om een webservice proxy bij de klant zelf te plaatsen (desnoods virtueel) waartegen de klant applicatie aan gaat praten. De proxy zelf laat je aanmelden m.b.v. een certificaat. Wil de klant dit niet (of hebben ze geen plek voor een (virtuele) proxy, dan zijn ze verplicht om via gebruikersnaam en wachtwoord met IP restrictie te werken. En het probleem met die wachtwoorden kan de klant zelf oplossen met een SSO oplossing (bijvoorbeeld)

[Voor 11% gewijzigd door Equator op 25-05-2012 10:30]

[Boss]

Anoniem: 26306 schreef op vrijdag 25 mei 2012 @ 09:34:
[...]
Het mac-adres van de client Sjaak.

Ook die, als hij niet achter een router zit... Dus zal eigenlijk meestal niet opgaan.

[DiedX]

Certificaat op een smartcard?

[P.O. Box]

Remco schreef op donderdag 24 mei 2012 @ 16:19:
Wij zitten met een ontwerp probleem voor een webservice. Misschien dat één van jullie enig idee hebben hoe we het zouden kunnen oplossen.

Huidige situatie;
Momenteel hebben externe klanten de mogelijkheid om gegevens te bekijken via een webinterface. Dit gaat in combinatie met een digipass key. Deze situatie werkt goed, echter is dit niet te koppelen aan een backoffice pakket van de klant zelf.

geen oplossing voor jou, maar meer een nieuwsgierigsheidsvraag / heb-je-hier-aan-gedacht-vraag van mijn kant:
nu kunnen klanten via een webinterface de medische gegevens van iemand zien... om die gegevens zelf op te slaan zullen ze enige moeite moeten doen...
als je klanten de gelegenheid geeft de medische gegevens in een eigen backoffice systeem in te lezen, verlies je dan niet nog meer de controle over je data? wie zegt dat het backoffice systeem van de klant veilig is? de data versnipperd over vele, potientieel onveilige, klanten...
ik weet dat op de huidige manier de gegevens ook eenvoudig te kopieren zijn en dus onveilig opgeslagen kunnen worden, maar m.i. is de huidige werkwijze toch net iets beter (voorkomen dat mensen dingen kopieren kun je toch niet, maar in de huidige situatie kopieren mensen de gegevens bewust, terwijl in de nieuwe situatie de klant "onbewust" veel informatie opslaat in een systeem dat buiten jouw controle staat)

[JH66]

Interessante discussie, maar na het lezen vraag ik me even af.

Hoe ver wil je gaan met de verantwoording van toegang tot jullie infrastructuur? Terwijl die deels bij de klant zou kunnen/moeten liggen? Als dienstverlener zorg je er uiteraard voor dat je infrastructuur goed beveiligt is en weet aan welke partijen je toegang verstrekt (certificaat, username/ password etc). Maar je zal nooit kunnen afdichten dat die partij er ook verantwoord mee omgaat. Als toegang gegevens eenmaal verzonden zijn is het maar raden hoe de klant ermee omgaat.

Aangezien er veel dynamische ip's worden gebruikt zou ik de verantwoording eerder contractueel/procedureel heel goed vastleggen.

Daarbij denk ik aan:
-Gebruiksvoorwaarden van de dienst en eisen aan beheer van gegevens (certificaat beheerder/ procedures van gebruikersnaam/wachtwoord beheer).
-Eventuele sancties bij constatering misbruik gegevens?
-Certificering van backoffice systemen die connectie maken (eisen opstellen van/aan implementatie?).
-Beschikbaar maken van logging en rapportages voor klanten.

[Herko_ter_Horst]

Paul schreef op vrijdag 25 mei 2012 @ 09:38:
[...]
Iemand die vanaf het verkeerde IP-adres komt kan zich niet eens authenticeren; dat maakt het mijns inziens deel van het beveiligingsproces?

Als je kon rekenen op vaste IP adressen, dan is dit inderdaad een drempel (maar nog steeds geen authenticatie). Zoals al in de TS staat, is dat echter niet mogelijk/betaalbaar/af te dwingen.

Hoe meer ik er over nadenk, hoe meer ik er van overtuigd raak dat OAuth de oplossing is voor het probleem. Volgens mij voldoet dit aan alle eisen van de TS, is het een goed gedoucmenteerde industriestandaard en zijn er in diverse talen (open source) libraries voor beschikbaar, waardoor het goed te integreren is.

@ReneDD hieronder: die aanpak lijkt wel een beetje op OAuth, alleen heeft OAuth ook de mogelijkheid om een refresh-token te genereren, waarmee zonder voortdurende tussenkomst van de gebruiker nieuwe sessies gestart kunnen worden.

[Voor 38% gewijzigd door Herko_ter_Horst op 25-05-2012 12:50]

[ReneDD]

In het verleden wel eens een webservice ontwikkeld met gevoelige gegevens (oa. betaalachterstanden per klant, beperkte medische gegevens). Naast allerlei certificaten hadden enkele veiligheidsjongens de volgende constructie bedacht (voor zover ik het mij goed herinner). Zelf hoefde ik alleen een klein stukje te bouwen en dat is alweer even terug .

De afnemer stuurt een username en encrypted wachtwoord naar een authenticatie service. Deze service stuurt een bepaalde (SHA1?) hash terug die tijdelijk wordt uitgegeven. Daarna is het de bedoeling dat de afnemer zijn username, wachtwoord en (SHA1?) hash achter elkaar plakt wederom in een hash stopt die met een bepaald keyword wordt versleuteld. Daarna kan de afnemer met deze gegevens een aanroep doen naar de service, welke dit controleert (username, password en laatst uitgegeven hash voor de betreffende user + hashed met gedeelde sleutel tussen de 2 partijen). De uitgegeven hash blijft gedurende 1 minuut actief (voor maximaal 1 request), waardoor bij een volgende aanroep het hele proces weer opnieuw begint.

De gedeelde sleutel kan uiteraard per afnemer verschillen. Tevens kun je heel makkelijk een account blokkeren.

[Voor 17% gewijzigd door ReneDD op 25-05-2012 14:47]

[Remco]

Zo, ik zal weer eens reageren....
Bedankt allemaal voor het meedenken. Hierbij even wat antwoorden/reacties:

MikeN schreef op donderdag 24 mei 2012 @ 21:45:
Uh, als het hier om medische gegevens gaat, zou je dan niet iemand met verstand van dit soort beveiligingen er naar laten kijken?

We laten er ook wel degelijk iemand anders naar kijken. Wij zijn opdrachtgever, een extern developer bureau zal het product maken, en deze zal dan door een andere partij weer ge-audit worden. Ik praat dan alleen over de webservice die wij gaan aanbieden.
Maar wij willen als opdrachtgever graag vooraf de (on)mogelijkheden weten.

MikeN schreef op donderdag 24 mei 2012 @ 21:45:
IP adressen zijn geen authenticatiemiddel, daar kan iedere gebruiker achter zitten.

Dat begrijp ik. Maar het kan er wel voor zorgen dat ik niet poort 443 aan de hele wereld open hoef te zetten. Niemand ziet de poort behalve die ip-adressen die toegang hebben. Het is gewoon een extra stukje security.

Herko_ter_Horst schreef op donderdag 24 mei 2012 @ 22:08:
Certificaten zijn de manier om applicaties zich bij elkaar te laten autoriseren (let op dat dit twee kanten op moet: jullie server moet weten dat het om een vertrouwde client gaat, maar de client moet ook weten dat hij met de juiste server communiceert).

M.b.t. het kopieren van certificaten: wat is de reden dat je kopiëren hiervan wilt voorkomen? Wat is het probleem als dat toch gebeurt?

Dat begrijp ik, en dat gebruiken we momenteel ook voor andere webservices. Deze andere webservices hebben echter maar 1 andere partij (de webserver) waarmee gepraat wordt. De communcatie gebeurd onder andere door middel van certificaten en firewall beperkingen. Ja, de webserver heeft wel een statisch adres, en dus lossen we meteen een heleboel problemen daarmee op.

Equator schreef op vrijdag 25 mei 2012 @ 10:29:
Even buiten de box denkende:
Is het niet mogelijk om een webservice proxy bij de klant zelf te plaatsen (desnoods virtueel) waartegen de klant applicatie aan gaat praten. De proxy zelf laat je aanmelden m.b.v. een certificaat. Wil de klant dit niet (of hebben ze geen plek voor een (virtuele) proxy, dan zijn ze verplicht om via gebruikersnaam en wachtwoord met IP restrictie te werken. En het probleem met die wachtwoorden kan de klant zelf oplossen met een SSO oplossing (bijvoorbeeld)

Dat is inderdaad een leuke oplossing.

RobIII schreef op donderdag 24 mei 2012 @ 22:39:
Het feit alleen al dat er wordt overwogen iets met een IP te doen (anders dan logging en de mogelijkheid 't te bannen wegens brute-force attacks, DDOS'es etc.) maakt me triest...

Wellicht is het niet goed in mijn ts naar voren gekomen, maar iets doen met de ip-adressen was slechts een onderdeel van de hele security. Wij willen juist niet de poort van de webservice aan iedereen aanbieden, maar slechts aan een deel. Het is een extra drempeltje, meer niet...

Herko_ter_Horst schreef op vrijdag 25 mei 2012 @ 01:30:
In plaats van - of in combinatie met - certificaten kun je OAuth overwegen. Dit systeem wordt door steeds meer webservices gebruikt (o.a. Google maakt hier gebruik van voor alle APIs).

Dank je, hier gaan we even naar kijken.

P.O. Box schreef op vrijdag 25 mei 2012 @ 12:08:
[...]
geen oplossing voor jou, maar meer een nieuwsgierigsheidsvraag / heb-je-hier-aan-gedacht-vraag van mijn kant:
nu kunnen klanten via een webinterface de medische gegevens van iemand zien... om die gegevens zelf op te slaan zullen ze enige moeite moeten doen...
als je klanten de gelegenheid geeft de medische gegevens in een eigen backoffice systeem in te lezen, verlies je dan niet nog meer de controle over je data? wie zegt dat het backoffice systeem van de klant veilig is? de data versnipperd over vele, potientieel onveilige, klanten...
ik weet dat op de huidige manier de gegevens ook eenvoudig te kopieren zijn en dus onveilig opgeslagen kunnen worden, maar m.i. is de huidige werkwijze toch net iets beter (voorkomen dat mensen dingen kopieren kun je toch niet, maar in de huidige situatie kopieren mensen de gegevens bewust, terwijl in de nieuwe situatie de klant "onbewust" veel informatie opslaat in een systeem dat buiten jouw controle staat)

Je hebt gelijk, zodra de data in handen van de klant is hebben wij daar geen controle meer over. Maar dat hoeft ook niet. Een en ander is hier bij wet afgevangen en geregeld. Wel wordt verwacht dat wij het maximale doen om ongeautoriseerde toegang te ontzeggen.