image

Juridische vraag: Mag ik de API van mijn bank anders dan met de Mobiel Bankieren App aanroepen?

woensdag 14 juni 2017, 14:16 door Arnoud Engelfriet, 15 reacties

Ict-jurist Arnoud Engelfriet geeft elke week antwoord op een interessante vraag over beveiliging, recht en privacy. Heb jij een vraag? Stuur hem naar juridischevraag@security.nl.

Vraag: De app van mijn bank is leuk en aardig, maar ik wil eigenlijk bepaalde kerncijfers in mijn thuisdashboard getoond hebben. Technisch kom ik daar wel uit, maar mag ik die API aanroepen voor mezelf? Het is in principe dezelfde informatie heen en weer als de app zou doen, maar ik doe het niet op de officiële manier. Krijg ik dan problemen?

Antwoord: Zuiver juridisch gezien zie ik hier geen probleem mee. Als je gerechtigd bent een API aan te roepen, dan is het niet strafbaar of onrechtmatig om die aan te roepen. Je gaat hier dus niet voor de cel in, en de bank zal ook geen schadeclaim kunnen indienen.

Als je rare trucs gaat toepassen om de API dingen te laten doen die niet de bedoeling zijn, dan kan dat anders liggen. Informatie opvragen waar je eigenlijk niet bijhoort, mag je niet zomaar doen. In theorie is dat computervredebreuk.

Praktisch gezien kun je er wel problemen mee krijgen, in ieder geval één simpele: als de bank jouw aanroepen ziet als misbruik of bedreiging, dan blokkeren ze die. Dat zal al snel betekenen dat je ook via de officiële app niet meer bij je bankgegevens kunt of overboekingen kunt doen, en dat lijkt me erg vervelend voor een consument. Want zonder internetbankieren je bankzaken doen is een hele uitdaging tegenwoordig.

Ik zou dit dus alleen doen als de bank het goedvindt, of als je zeker weet dat de aanroepen niet te onderscheiden zijn van 'echte' aanroepen.

Arnoud Engelfriet is Ict-jurist, gespecialiseerd in internetrecht waar hij zich al sinds 1993 mee bezighoudt. Hij werkt als partner bij juridisch adviesbureau ICTRecht. Zijn site Ius mentis is één van de meest uitgebreide sites van Nederland over internetrecht, techniek en intellectueel eigendom. Hij schreef twee boeken, De wet op internet en Security: Deskundig en praktisch juridisch advies.

Reacties (15)
14-06-2017, 14:20 door Anoniem
Basisvereiste lijkt me dat zo'n API fatsoenlijk beveiligt is, en als ik bank was zou ik er ook voor zorgen dat dat dus enkel met een geauthenticeerde app kan, en niet zomaar iedere call naar een openstaande service.
14-06-2017, 14:54 door [Account Verwijderd]
[Verwijderd]
14-06-2017, 15:10 door johanw
Door Anoniem: Basisvereiste lijkt me dat zo'n API fatsoenlijk beveiligt is, en als ik bank was zou ik er ook voor zorgen dat dat dus enkel met een geauthenticeerde app kan, en niet zomaar iedere call naar een openstaande service.
Basisvereiste lijkt mij dat de beveiliging server-side plaatsvind. Ik weet dat ABN AMRO dat ook doet: toen ik een backup van mijn bankieren app terugzette op een andere telefoon kon ik er niet mee rmee in,oggen, ik moest eerst dat toestel authenticeren via de bankpas lezer. Ze lezen dus in elk geval een of ander uniek nummer van het toestel uit. Maar als je je eigen app schrijft zou je dat dus kunnen provberen te faken, dit proberen dicht te zetten is hetzelfde probleem als DRM: de key is al aanwezig bij de aanvaller.
14-06-2017, 15:13 door Anoniem
een moderne bank als bunq heeft gewoon een API die gedocumenteerd is.
Zo'n API staat per definitie open (anders zouden alle apps er niet bijkunnen), dus hij moet al beveiligd zijn om geen dingen toe te laten die niet mogen. Een beetje modern bedrijf laat dat dus gewoon toe. (maar zo medern zijn veel banken niet)
14-06-2017, 15:14 door Anoniem
Door ackna10: Ik zou er als bank niet blij van worden als mensen zelf met APIs gaan zitten spelen,
En waarom dan niet? Omdat de klant een consument moet zijn, en niet geacht wordt iets anders te willen dan precies dat wat de bank hem voorschotelt? Of wat?

Dit is precies waarom dat hele "digitale transformatie"-gedoe al voor het begon een gigantische flop ging worden. Dat idee dat heel die interwebbertubewereld bestaat uit "cookie cutters" die nooit en te nimmer voor iets anders en door iets anders dan precies zoals bedoeld door de bedenkers gebruikt zal mogen worden.

Als consument ben ik overigens ook niet kapot van andere partijen bij mijn bankgegevens laten, maar dat begint (zeker in het buitenland) al heel normaal te worden. Share all the things!
Dat is de andere kant, als consument mag je niets anders dan wat je voorgeschreven wordt en ondertussen ben jij het product dus verkoopt "jouw" bank al jouw data lekker door. Controle over je eigen data? Ha ha, de idee. Domme consument.
14-06-2017, 19:38 door karma4 - Bijgewerkt: 14-06-2017, 19:42
Die openheid om api's door derden te laten gebruiken in opdracht van de gebruiker is eenopgelegde eu verplichting.
Eris nog wel een confomiteitseis van betrouwbaarheid naar gebruiker en geen misbruik van api's bij de banken terwijl banken een verplichte minimale functionaliteit moeten bieden.

https://www.europeanpaymentscouncil.eu/news-insights/insight/eu-payments-legislative-package-strong-concerns-european-banks
14-06-2017, 22:34 door Anoniem
Die mobiele App API heb je zonder handleiding denk ik weinig aan als het kanaal uberhoubt al leesbaar is of je mogelijk zelfs misbruik-detectie systemen laat afgaan zonder dat je dat wilt. Misschien kun je je bank vragen of ze voor je doel een normale API aanbieden en ook de specs dan even krijgen natuurlijk om het goed te gebruiken.

Er zijn ook al banken die het aanbieden zonder de noodzaak het te vragen:
https://www.bunq.com/nl/api
15-06-2017, 08:43 door Anoniem
Door karma4: Die openheid om api's door derden te laten gebruiken in opdracht van de gebruiker is eenopgelegde eu verplichting.
Eris nog wel een confomiteitseis van betrouwbaarheid naar gebruiker en geen misbruik van api's bij de banken terwijl banken een verplichte minimale functionaliteit moeten bieden.

https://www.europeanpaymentscouncil.eu/news-insights/insight/eu-payments-legislative-package-strong-concerns-european-banks
Dat is een opiniestuk, in de kantlijn staat:
The views expressed in this article are solely those of the authors and should not be attributed to the European Payments Council.
Los van dat het niet de EU-verplichting die je noemt onderbouwt laat je het aan de lezer over om in een flinke lap tekst het relevante fragmentje te vinden. Ik neem aan dat je dit bedoelt [verduidelijkingen toegevoegd door mij]:
But it [proposal for a Network and Information Security (NIS) Directive] does not seem consistent with the draft PSD2 [revised Payment Services Directive] which, as proposed by the Commission, would allow payment users to share their personal banking credentials with TPPs [third party providers] for which cyber security concerns should also have been taken into account.
Een van de vele hyperlinks onder dat artikel (de enige die duidelijk over PSD2 en TPPs gaat) verwijst naar een van de nieuwsbrieven van het EPC:
https://www.europeanpaymentscouncil.eu/news-insights/insight/psd2-epc-key-considerations-address-aspects-related-third-party-payment?articles_uuid=715B964B-5056-B741-DB6CB0030BB504E9
Daar wordt een hoop gezegd over de valkuilen van die toegang door TPPs, maar ik zie volgens mij niet expliciet gemaakt dat het geven van die toegang verplicht is voor een bank. Ik heb startpage dus maar de zoekopdracht "PSD2 TPPs" gegeven en vond deze PDF van Deutsche Bank:
http://cib.db.com/docs_new/White_Paper_Payments_Services_Directive_2.pdf
Daarin staat op pagina 36:
Access
Every ASPSP offering access to online payment accounts - having an online agreementwith a customer, and having provided the customer with tools for online authentication - will have to be accessible to TPPs and to provide them with an online interface. There need not be any contractual relationship between a TPP and an ASPSP.
Hèhè, eindelijk zie ik ergens staan dat de EU inderdaad toegang door derden verplicht via een online interface. Beste karma4, ik vind het lovenswaardig dat je een link opneemt ter onderbouwing van een bewering, maar zou je alsjeblieft zo zorgvuldig willen zijn dat je een link opneemt die die onderbouwing ook daadwerkelijk levert? En bij alles behalve heel korte teksten even aangeven waar in de gelinkte tekst die onderbouwing te vinden is? Het is veel efficiënter als één persoon (de schrijver van een reactie) het uitzoekwerk voor zijn rekening neemt dan dat iedereen die het leest zo'n zoektocht moet uitvoeren.

Goed, nou weet ik genoeg om inhoudelijk op je reactie te reageren. De openheid op API's door derden te laten gebruiken is specifiek op third party providers gericht, ze hebben het daarbij niet over consumenten zelf. Hier gaat het wel om een consument die zijn eigen API-aanroepen wil regelen. Niet dezelfde situatie, zeker niet als je in de EPC-nieuwsbrief die ik hierboven linkte nadrukkelijk wordt gesteld dat ze sterk afkeuren dat die TPPs met de credentials van de klant van de bank werken. Daarmee heb je het volgens mij al snel over andere API's dan die voor rechtstreekse toegang door de klant worden gebruikt, al zullen de twee sets API's wel overlappen. Ik ben er daarmee niet van overtuigd dat deze verplichting aan banken op de situatie die hier speelt van toepassing is.

Maar ik denk wel dat het vanuit een technisch perspectief geen kwaad moet kunnen. Dergelijke API's moeten sowieso robuust zijn, foutief gebruik ervan mag nooit de server die ze afhandelt in problemen brengen (zolang het geen grote DDOS-aanvallen betreft), en ongeautoriseerde toegang tot data van anderen via die API's mag ook niet mogelijk zijn, alle invoer moet op de server gevalideerd worden. In dit opzicht moet het veilig zijn.

Dan kom ik bij:
Door ackna10: Ik zou er als bank niet blij van worden als mensen zelf met APIs gaan zitten spelen, maar zuiver juridisch denk ik dat ze idd niet veel meer kunnen doen dan je blocken. Hoe zit dat echter met aansprakelijkheid als er iets fout gaat met je saldo of diensten?
Ik denk dat een bank die zijn API's, validaties en logging op orde heeft niet wakker hoeft te liggen van gebruik ervan vanuit software die mensen zelf schrijven, als correct ingelegde opdrachten maar correct worden uitgevoerd en foute invoer wordt geweigerd met een foutmelding of -code.

Maar iemand die dergelijke software schrijft is daarmee wel verantwoordelijk voor zijn eigen blunders. Als je door een stom foutje met euro's en centen honderd keer zoveel overmaakt dan je dacht over te maken is het helemaal je eigen probleem, de bank kan echt niet weten dat je wat anders bedoelde en moet afgaan op wat je aanlevert. En al je tests doe je in een echte live-omgeving, je hebt geen veilige omgeving waar alles voor spek en bonen gebeurt waar je je eigen aanroep van die API's kan debuggen.

Ik kan me levendig voorstellen dat een bank helemaal geen zin in het gezeur heeft dat dat soort ongelukken kan opleveren. Ik weet niet of het voor de vraagsteller geldt, maar er lopen genoeg mensen rond die als het ernstig misgaat zullen proberen te doen alsof (of zichzelf wijsmaken dat) de bank zelf de fout heeft gemaakt.

Ik zou de vraagsteller sterk aanraden om dit soort risico's niet te lopen. Zelfs de beste programmeurs blunderen af en toe stevig. Testen in een live omgeving is daarom iets wat je moet mijden als de pest. En dat is zonder actieve medewerking van de bank de enige mogelijkheid die je hebt.
15-06-2017, 12:36 door Anoniem
Door Anoniem: Maar iemand die dergelijke software schrijft is daarmee wel verantwoordelijk voor zijn eigen blunders. Als je door een stom foutje met euro's en centen honderd keer zoveel overmaakt dan je dacht over te maken is het helemaal je eigen probleem, de bank kan echt niet weten dat je wat anders bedoelde en moet afgaan op wat je aanlevert.
Je kan daar simpel iets aan doen, wat de bank voor hun eigen "app" toch ook nodig zal hebben: Je geeft een order, en je krijgt daarvoor terug een bevestiging die nog eens expliciet maakt dat dit is wat je bedoelde, en daarop geef je het "ok, ja, dit is wat ik bedoelde". Dat verwacht ik van een bankier-website ook, dus ik zie niet in waarom een API dat niet zou doen.

Want wat is een website behalve een front-end op zo'n API? Precies zoals een "webmail" in principe een web-front-end is voor een IMAP-sessie. Alle logica zit in het back-end en het webgedeelte is precies dat: Inpakken van de datastroom in html zodat een browser ook mee kan doen.

En al je tests doe je in een echte live-omgeving, je hebt geen veilige omgeving waar alles voor spek en bonen gebeurt waar je je eigen aanroep van die API's kan debuggen.
Lijkt me dat dit eenvoudig te verhelpen is door de bank. Ze moeten het voor zichzelf toch ook hebben, dus waarom niet voor anderen?

Dit is een heel sterk principe waar bijvoorbeeld amazon groot mee geworden is: Al je APIs netjes gedocumenteerd en dat is tegelijk de enige manier om bij de dienst te komen, dwz we doen niet aan "interne APIs" of achterdeurtjes of wat ook. Iedereen die wil kan bij de documentatie en gegeven voldoende toegangsrechten ook bij de API.

Ik kan me levendig voorstellen dat een bank helemaal geen zin in het gezeur heeft dat dat soort ongelukken kan opleveren. Ik weet niet of het voor de vraagsteller geldt, maar er lopen genoeg mensen rond die als het ernstig misgaat zullen proberen te doen alsof (of zichzelf wijsmaken dat) de bank zelf de fout heeft gemaakt.
Als de bank weet wat ze doet dan kan ze precies vertellen hoe het gegaan is. Niet dat de gemiddelde bank weet wat ze doet, --ze bestaan tegenwoordig vooral voor het ophouden van de schijn-- vandaar hun neiging om zoveel mogelijk risico op de klant af te wentelen.

Ik zou de vraagsteller sterk aanraden om dit soort risico's niet te lopen. Zelfs de beste programmeurs blunderen af en toe stevig. Testen in een live omgeving is daarom iets wat je moet mijden als de pest. En dat is zonder actieve medewerking van de bank de enige mogelijkheid die je hebt.
Dit is nou een mooi ding om een regeltje op te leggen: Maakt niet uit hoe je die APIs doet maar zorg dat ze a) netjes gedocumenteerd zijn (en dat de documentatie dus ook klopt en zo verder) en b) veilig te gebruiken en te testen, voor iedereen.

In tegenstelling tot de rotzooi die de overheid nu trapt met burgers verplichten brakke websites te gebruiken, regelmatig verplicht in te loggen, en meer van dat soort vreselijk kortzichtige bagger, zou met dat ene ding de "digitale transformatie" een enorme steun in de rug kunnen krijgen, gewoon omdat iedereen ineens vrij is om dingen te bouwen, te innoveren, wat-dan-ook te doen.

Het is niet zo moeilijk. Je moet alleen wel even je oogjes open doen.
15-06-2017, 13:22 door karma4 - Bijgewerkt: 15-06-2017, 13:23

Goed, nou weet ik genoeg om inhoudelijk op je reactie te reageren. De openheid op API's door derden te laten gebruiken is specifiek op third party providers gericht, ze hebben het daarbij niet over consumenten zelf. Hier gaat het wel om een consument die zijn eigen API-aanroepen wil regelen. Niet dezelfde situatie, zeker niet als je in de EPC-nieuwsbrief die ik hierboven linkte nadrukkelijk wordt gesteld dat ze sterk afkeuren dat die TPPs met de credentials van de klant van de bank werken.
Sorry dat ik heb niet totaal afgepeld heb. Psd2 is hier eerder op de site aan de orde geweest. De essentie onthoud ik, de links moet. Dat is dan wel eens lastig terugvinden zeker met de beperkingen met een Smartphone in tussendoor tijd.

Je hebt gelijk dat het niet exact dezelfde situatie is. Maar de opening voor api's is er en die moeten helder en betrouwbaar zijn. Het is de basis en een begin van een opening.
Je hebt hem prima opgepakt.
15-06-2017, 17:32 door Anoniem
Door Anoniem:
Door karma4: Die openheid om api's door derden te laten gebruiken in opdracht van de gebruiker is eenopgelegde eu verplichting.
Eris nog wel een confomiteitseis van betrouwbaarheid naar gebruiker en geen misbruik van api's bij de banken terwijl banken een verplichte minimale functionaliteit moeten bieden.

https://www.europeanpaymentscouncil.eu/news-insights/insight/eu-payments-legislative-package-strong-concerns-european-banks
Dat is een opiniestuk, in de kantlijn staat:
The views expressed in this article are solely those of the authors and should not be attributed to the European Payments Council.
Los van dat het niet de EU-verplichting die je noemt onderbouwt laat je het aan de lezer over om in een flinke lap tekst het relevante fragmentje te vinden. Ik neem aan dat je dit bedoelt [verduidelijkingen toegevoegd door mij]:
But it [proposal for a Network and Information Security (NIS) Directive] does not seem consistent with the draft PSD2 [revised Payment Services Directive] which, as proposed by the Commission, would allow payment users to share their personal banking credentials with TPPs [third party providers] for which cyber security concerns should also have been taken into account.
Een van de vele hyperlinks onder dat artikel (de enige die duidelijk over PSD2 en TPPs gaat) verwijst naar een van de nieuwsbrieven van het EPC:
https://www.europeanpaymentscouncil.eu/news-insights/insight/psd2-epc-key-considerations-address-aspects-related-third-party-payment?articles_uuid=715B964B-5056-B741-DB6CB0030BB504E9
Daar wordt een hoop gezegd over de valkuilen van die toegang door TPPs, maar ik zie volgens mij niet expliciet gemaakt dat het geven van die toegang verplicht is voor een bank. Ik heb startpage dus maar de zoekopdracht "PSD2 TPPs" gegeven en vond deze PDF van Deutsche Bank:
http://cib.db.com/docs_new/White_Paper_Payments_Services_Directive_2.pdf
Daarin staat op pagina 36:
Access
Every ASPSP offering access to online payment accounts - having an online agreementwith a customer, and having provided the customer with tools for online authentication - will have to be accessible to TPPs and to provide them with an online interface. There need not be any contractual relationship between a TPP and an ASPSP.
Hèhè, eindelijk zie ik ergens staan dat de EU inderdaad toegang door derden verplicht via een online interface. Beste karma4, ik vind het lovenswaardig dat je een link opneemt ter onderbouwing van een bewering, maar zou je alsjeblieft zo zorgvuldig willen zijn dat je een link opneemt die die onderbouwing ook daadwerkelijk levert? En bij alles behalve heel korte teksten even aangeven waar in de gelinkte tekst die onderbouwing te vinden is? Het is veel efficiënter als één persoon (de schrijver van een reactie) het uitzoekwerk voor zijn rekening neemt dan dat iedereen die het leest zo'n zoektocht moet uitvoeren.

Goed, nou weet ik genoeg om inhoudelijk op je reactie te reageren. De openheid op API's door derden te laten gebruiken is specifiek op third party providers gericht, ze hebben het daarbij niet over consumenten zelf. Hier gaat het wel om een consument die zijn eigen API-aanroepen wil regelen. Niet dezelfde situatie, zeker niet als je in de EPC-nieuwsbrief die ik hierboven linkte nadrukkelijk wordt gesteld dat ze sterk afkeuren dat die TPPs met de credentials van de klant van de bank werken. Daarmee heb je het volgens mij al snel over andere API's dan die voor rechtstreekse toegang door de klant worden gebruikt, al zullen de twee sets API's wel overlappen. Ik ben er daarmee niet van overtuigd dat deze verplichting aan banken op de situatie die hier speelt van toepassing is.

Maar ik denk wel dat het vanuit een technisch perspectief geen kwaad moet kunnen. Dergelijke API's moeten sowieso robuust zijn, foutief gebruik ervan mag nooit de server die ze afhandelt in problemen brengen (zolang het geen grote DDOS-aanvallen betreft), en ongeautoriseerde toegang tot data van anderen via die API's mag ook niet mogelijk zijn, alle invoer moet op de server gevalideerd worden. In dit opzicht moet het veilig zijn.

Dan kom ik bij:
Door ackna10: Ik zou er als bank niet blij van worden als mensen zelf met APIs gaan zitten spelen, maar zuiver juridisch denk ik dat ze idd niet veel meer kunnen doen dan je blocken. Hoe zit dat echter met aansprakelijkheid als er iets fout gaat met je saldo of diensten?
Ik denk dat een bank die zijn API's, validaties en logging op orde heeft niet wakker hoeft te liggen van gebruik ervan vanuit software die mensen zelf schrijven, als correct ingelegde opdrachten maar correct worden uitgevoerd en foute invoer wordt geweigerd met een foutmelding of -code.

Maar iemand die dergelijke software schrijft is daarmee wel verantwoordelijk voor zijn eigen blunders. Als je door een stom foutje met euro's en centen honderd keer zoveel overmaakt dan je dacht over te maken is het helemaal je eigen probleem, de bank kan echt niet weten dat je wat anders bedoelde en moet afgaan op wat je aanlevert. En al je tests doe je in een echte live-omgeving, je hebt geen veilige omgeving waar alles voor spek en bonen gebeurt waar je je eigen aanroep van die API's kan debuggen.

Ik kan me levendig voorstellen dat een bank helemaal geen zin in het gezeur heeft dat dat soort ongelukken kan opleveren. Ik weet niet of het voor de vraagsteller geldt, maar er lopen genoeg mensen rond die als het ernstig misgaat zullen proberen te doen alsof (of zichzelf wijsmaken dat) de bank zelf de fout heeft gemaakt.

Ik zou de vraagsteller sterk aanraden om dit soort risico's niet te lopen. Zelfs de beste programmeurs blunderen af en toe stevig. Testen in een live omgeving is daarom iets wat je moet mijden als de pest. En dat is zonder actieve medewerking van de bank de enige mogelijkheid die je hebt.

Je haalt me de woorden uit de mond.
15-06-2017, 18:18 door karma4
[Verwijderd]
15-06-2017, 18:18 door karma4
Kijk dan eens verder voor de vraagsteller. Is het doel enkel privé of ziet hij er voor de toekomst een bedrijfsmogelijkheid in.
Wanneer is het ontwikkelwerk voor een startup en wanneer echt hobby. Zodra het bedrijfsmatig wordt kom je in de third party optie.
15-06-2017, 20:22 door Anoniem
Door karma4: Sorry dat ik heb niet totaal afgepeld heb. Psd2 is hier eerder op de site aan de orde geweest.
Dat betekent niet dat iedereen dat gelezen heeft of nog paraat heeft.
Dat is dan wel eens lastig terugvinden zeker met de beperkingen met een Smartphone in tussendoor tijd.
Wacht dan nog even met reageren tot je de gelegenheid hebt het vanaf een desktop-pc te doen. Een goede reactie die een halve dag later komt is meer waard dan een rammelende reactie die mogelijk niet of verkeerd begrepen wordt.
16-06-2017, 06:42 door karma4
Door Anoniem: .....
Wacht dan nog even met reageren tot je de gelegenheid hebt het vanaf een desktop-pc te doen. ... .
Aannames aannames. Hoelang denk je dat het duurt voordat dat zover is? Tussendoor reis even markeren en dan later oppakken (paar uur) en als dat nu weken is, dan heb je niets.

Te vaak gezien dat een vermelding die je niet op tijd doet kwalijke gevolgen heeft. Eerst ja we weten het niet gaan wel wat proberen dan nu hebben we zoveel tijd gespendeerd gaan we echt niet anders doen. Kun je het eerst zien af te breken omdat het niet lukt om dan nog eens op te bouwen.

Nu heb je een richting Psd2 waar je mee verder kan. In een forum zij vele mensen met kennis die van elkaar kunnen leren. Iedereen wat bijdragen en je komt veel verder.
De klaasikale wijze van een leraar die alles dicteert is niet zo handig.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.