Mag ik de hardcoded sleutel van een app gebruiken voor mijn eigen aanroepen?

Een lezer vroeg me:

Ik wil gebruik maken van een online tool vanuit mijn eigen software. Helaas is een zakelijke licentie op die tool veel te duur. Nu zat ik in de bijbehorende app voor consumentengebruik te kijken, en die blijkt met een hardcoded key te authenticeren. Ik kan daarmee dus perfect een aanroep simuleren, want het http verkeer is ook nog eens onversleuteld. Is dit toegestaan?

Het is in principe de bedoeling dat je aangeboden tools gebruikt zoals ze je aangereikt worden. Dat staat niet letterlijk in de wet maar volgt volgens mij uit wat juristen de redelijkheid en billijkheid noemen. Maar daar staat tegenover dat het dus niet automatisch strafbaar of onrechtmatig is als je iets anders inzet dan de aangeboden tooling.

In het geval van de vraagsteller kun je die app zien als niet meer dan een schil waarmee een server wordt aangeroepen. Ik zie het onrechtmatige niet in het zelf doen van die aanroep. In dit geval wordt er geen account van een ander gebruikt of een achterdeurtje aangeroepen. Alle apps hebben dezelfde sleutel, dus waartegen die sleutel moet beveiligen is me een raadsel.

Ook vraag je op deze manier geen informatie op waar je geen recht op had. Je had exact deze gegevens gekregen als je via de app de informatie op had gevraagd. Van computervredebreuk – ergens binnengaan waar je weet dat je niet mag zijn – kan ik dus niet spreken hier. Wellicht als je de API gaat manipuleren door extra velden te proberen, of counters gaat veranderen buiten de range die de app zelf gebruikt. Dat zou ik dus afraden.

Een complicatie bij deze vraag is dat de aanbieder zakelijke licenties onderscheidt van consumentengebruik met de app. De werkwijze van deze vraagsteller leidt ertoe dat hij onder een consumentenmantel informatie krijgt die hij zakelijk gaat inzetten. Dat zou je kunnen zien als contractbreuk: er staat vast iets in de app-licentie dat de informatie uitsluitend huishoudelijk of privé gebruikt mag worden.

Daar staat voor mij tegenover dat de vraagsteller ook met de app in de hand de informatie had kunnen verkrijgen en dan zakelijk inzetten. Daar doet die app niets tegen. Ik zie de schade niet voor de aanbieder in dat geval, dus waarom zou het dan wél schadelijk zijn als hij dat met een eigen tool doet?

Arnoud

36 reacties

  1. Het zou me verbazen als in de algemene voorwaarden niet ook ergens een bepaling is opgenomen dat de consumentenversie niet geautomatiseerd mag worden aangeroepen. Bij online tools is het niet voor niets dat een API voor dat soort werk alleen onder een zakelijke licentie beschikbaar wordt gemaakt.

    Ik zie de schade niet voor de aanbieder in dat geval, dus waarom zou het dan wél schadelijk zijn als hij dat met een eigen tool doet?
    Deze vind ik redelijk analoog met Ik zie de schade niet voor de filmproducent als ik een film illegaal download die ik toch niet zelf zou kopen.. Die discussie was dacht ik al afgekaard in het voordeel van de filmproducent?

    1. Hangt het inderdaad niet gewoon af wat er in de voorwaarden staat. Als je de app waarin de sleutel te vinden is alleen kunt krijgen als je akkoord gaat, dan gaat de hele redenatie over hoe open die sleutel is niet meer op lijkt me.

      1. Als je de sleutel kunt vinden door mee te luisteren met de wifi van je buurman, ben je dan ook gebonden aan de voorwaarden van de applicatie?

        En daarnaast kent de Nederlandse wet een recht op reverse-engineering ten behoeve van interoperabiliteit.

        1. Ik vind dit interoperabiliteit verhaal als iemand met weinig juridische kennis nogal vaag. Het klinkt mij in de oren als dat er iemand aan de haal gaat met je services. Als het op dit moment zou kunnen dan is de vraag of het bedrijf hier van op de hoogte is. En als men er achter komt het niet alsnog anders inricht. Lijkt mij in ieder geval geen goede route om iets te ontwikkelen. Maar goed interessant wel om te weten wat precies wel en niet mag.

  2. Ik heb toch wat moeite met je argumentatie Arnoud.

    Ten eerste ga je er vanuit dat je precies hetzelfde doet via de app als dat je dit gaat nabouwen. Misschien heeft de consumenten app wel advertenties er in, zit er een limiet op het aantal requests, etc. Hoewel ik altijd moeite heb met de definitie van computervredebreuk, maak je hier gebruik van een valse sleutel of valse signalen (de sleutel heb je immers afgekeken) en je neemt een valse hoedanigheid aan (je laat de server denken dat je hun app bent.

    Ik pleit er niet voor om dit strafbaar te stellen maar ik zie niet in waarom dit volgens de wet gewoon zou mogen.

    Daarnaast zijn er voldoende andere voorbeelden waarbij er onderscheidt gemaakt wordt in gebruik en ik kan me ook niet voorstellen dat dat geen stand kan houden omdat schade niet aangetoond kan worden.

    Ik kan een liedje gratis via Spotify luisteren dus mag ik het liedje ook gewoon downloaden. Een foto met een licentie voor privé gebruik mag ik ook commercieel inzetten want die foto kan ik toch gewoon op internet plaatsen. Alle software licenties (voor development maar volgens mij ook bijv Office) kan ik een privé licentie aanschaffen en zakelijk inzetten.

    Ik ben van mening dat het allemaal zou moeten mogen en je zal als ondernemer moeten zorgen dat je voldoende meerwaarde biedt zodat iemand er extra voor wil betalen. Maar ik kan me niet voorstellen dat het nu juridisch mag.

  3. ??? je wil iets gebruiken van een ander en jij vind dat goed verdedigbaar???

    Even een vergelijk; er loopt een meisje op straat in korte rok en ziet er lekker uit. Daar mag jij ook niet aan komen zonder toestemming, kijken mag toe op zekere hoogte. Maar daar houd het op. Niet aankomen en of gebruiken

    1. Ik beschouw de server als een agent van de aanbieder van de dienst, en deze is door de aanbieder gemachtigd te antwoorden op verzoeken, gedaan in een bepaalde vorm. Een verzoek doen aan die server staat dus gelijk aan een verzoek doen door de aanbieder op te bellen en het te mondeling te vragen, of een brief te sturen met een schriftelijk verzoek. Het is aan de aanbieder om behoorlijk zijn agent te instrueren (programmeren), zodat hij doet wat hij moet doen. Ook als ik de receptionist van een bedrijf bel met een verzoek om informatie, en zij geeft die, dan is dat een “overeenkomst” die lost staat van bijvoorbeeld een abbonnementsdienst waarin staat dat ik geen recht heb op die informatie. Had de aanbieder zijn receptioniste maar beter moeten instrueren.

      Zolang ik een gewone vorm van vragen blijf hanteren zie ik geen probleem. Als het verwordt tot doelbewust hacken van bugs in de server software om dingen te krijgen die niet bedoeld zijn, dan staat gelijk aan opbellen en liegen (“social engineering” ), en ga je een grens over. Hetzelfde geldt voor het gebruik van sleutels die niet voor jou bedoeld zijn. Een sleutel die je van de aanbieder zelf hebt gekregen (en zo zie ik dat hier) is natuurlijk wel toegestaan, zeker als die zo wijd verspreid is.

      1. Je hebt de sleutel gekregen om hem binnen de consumentenapp te gebruiken, met alle technische en contractuele beperkingen die daar aanhangen. Je hebt de sleutel niet gekregen om oneindig en met ruimere technische en/of contractuele vrijheid informatie op te vragen.

        Sowieso, de sleutel lospeuteren uit de consumentenapp, is dat al niet ‘hacken’? Het systeem is over-overduidelijk niet bedoeld om op die manier gebruikt te worden.

        1. Dat hangt van het ‘peuteren’ af, maar decompileren en de inhoud van een app bekijken lijkt me legaal. Idem voor netwerkverkeer sniffen, en als je daar een sleutel in langs ziet komen, dan is dat gewoon een stukje informatie.

          Stel dat je vervolgens exact aanroept wat de app ook doet, wat overtreed je materieel dan?

          1. Dus als ik op een parkeerplaats met een RF-key sniffer de toegangscode van een auto te pakken krijg en die toepast om mij toegang tot de auto te verschaffen dan zou dat volgens jou ook OK zijn want die code was maar een stukje informatie? Los van het inbraak-aspect, iedereen voelt toch op zijn klompen aan dat deze procedure niet in de haak is?

            Kern is denk ik dat de key wel toegang biedt tot de app, maar dat dat alleen mag als die key je met dat doel door de eigenaar is gegeven. Dat ik de mogelijkheid heb om die key op een andere manier (zonder uitdrukkelijke toestemming) te verkrijgen wil niet zeggen dat ik ‘m ook mag gebruiken.

            1. Niet echt. Een netwerksniffer kijkt op je eigen netwerk (tenminste, zo hoort het) die RF-key sniffer niet. Bovendien, als je de auto betreedt dan bevind jij je in iemand anders zijn eigendom. Neem je iets uit de auto (of de auto zelf) mee, dan ontvreemd je persoonlijk eigendom. Arnout stelt dat je een systeem bevraagt en een antwoord krijgt, i.e. een kopie die via de app wordt verstrekt. Dat werkt toch net anders.

            2. Dat is een leuk voorbeeld, tenzij er iets is veranderd en ik dat gemist heb ben je namelijk vrij om alle signalen die je wil uit de ether op te vangen…

              Het verbod op omzeilen van kopieer beveiligingen in het auteursrecht is zo het enige wat DVB-T mogelijk maakt. Als het onversleuteld de lucht in gaat is het voor de ontvanger in principe fair game.

          2. Dus als ik op een locatie iemand een toegangscode voor een deur in zie toetsten mag ik ook door die deur naar binnen?

            Stel dat ik normaal in dat gebouw tussen 9:00 en 17:00 uur welkom ben om x te doen (bijvoorbeeld studeren in de bieb). Mag ik dan buiten die tijden met de afgekeken toegangscode naar binnen en precies doen wat ik tijdens openingstijden ook kan doen. Dan is er ook geen schade maar ik betwijfel of het stand houdt.

            Het gaat hier om een ernstig zwakke beveiliging maar ook bij een open deur mag je niet zomaar naar binnen.

          3. Vergelijk het eens met een muziekvideo downloaden van YouTube. Ik mag deze via de YouTube website gewoon bekijken. Het is echter vrij eenvoudig om de request te sniffen, deze na te spelen, en daarmee de video te downloaden. Is dit nu legaal of niet? En wat auteursrechten betreft, heb ik dit nu uit illegale bron gedownload of is dit een legale bron? Neem voor het gemak even aan, dat het om het officiele YouTube kanaal van de bezitter van het auteursrecht van de video gaat.

            1. In een rechtszaak tegen een van de “YouTube download sites” heb ik de aanklager horen beweren dat je bij het downloaden de beveiliging van de video moet doorbreken. Nu lijkt die beveiliging me niet effectief als YouTube download tools triviaal op Internet te vinden zijn.

          4. Wat overtreedt je materieel dan… ik weet het niet, maar het voelt niet goed. Ik zou het toch gooien op computervredebreuk, omdat je de dataleverancier de kans ontneemt om zijn dataleveringen aan zijn voorwaarden te onderwerpen.

          5. Is het sniffen niet verboden? Artikel 139c? Sniffen is dan toch “met een technisch hulpmiddel gegevens aftappen” die “niet voor hem bestemd zijn”. Of mag dit wel als ik de gegevens aftap van mijn eigen gebruik van de app?

            En ja, als je exact ( een exacte replay ) doet wat de app doet, dat lijkt me geen overtreding inderdaad. Pedantic question: als er in dat verzoek van die app een hash oid wordt gebruikt en daar moet ik technisch wel wat mee doen, bijvoorbeeld vervalsen of misschien gebruik maken van een bug in de API, is dat dan wel computervredebreuk?

        2. Dat hangt sterk van de context af. Als ik de app zonder meer van een publieke site kan downloaden, dan heb ik geen verdere overeenkomst met de maker van de app, en dan gelden dus gewoon de wettelijke beperkingen, als ik een overeenkomst sluit over het gebruik van een api, dan heb ik me daar in principe aan te houden, tenzij de wet anders regelt. Een verbod op reverse-engineren voor interoperabiliteit is bijvoorbeeld niet te verbieden (ruim 10 jaar oude post hier: https://blog.iusmentis.com/2009/04/21/mag-reverse-engineering-bij-eula-verboden-worden/)

  4. Als ik het goed begrijp wil de vraagsteller een businesscase bouwen op ongedocumenteerde veiligheidslekken.

    Of het illegaal is wat de vraagsteller doet weet ik niet. Onverstandig lijkt het me wel. Zodra het veiligheidslek ontdekt wordt, zal het gedicht worden (mag ik hopen). Dan zit je dan als vraagsteller. En ik denk niet dat je dan ineens die licentie krijgt onder de gebruikelijke voorwaarden met de gebruikelijke kosten. En zit je met boze klanten omdat die integratie plots niet werkt.

    Leuk dat je dit als privepersoon een keer probeert te misbruiken (gebruiken?), en kudos voor de getoonde hacker-skills. Maar helaas een onvoldoende voor de online cursus business skills.

  5. Je hebt volgens de auteurswet het recht op observatie hoe een systeem werkt om een compatibel systeem te bouwen. Auteursrechtelijk is wat er gebeurd in orde. Ook eens dat compatibel gebruik maken van de API geen computervredebreuk oplevert.

    Tja, onrechtmatige daad… de argumentatie daarvoor is naar mijn mening te dun. Je moet mij stap voor stap uitleggen hoe het gebruik van de door de leverancier zelf gratis aangeboden API met de app van de leverancier rechtmatig is, maar met een alternatieve tool onrechtmatig. Handjes wapperen en daarbij verdienmodel roepen is heel mager.

  6. Het onttrekken van een licentiekey aan een app is het omzeilen van een doeltreffende technische voorziening, en dat mag dus niet. Databankwet, auteurswet, wet computercriminaliteit. Er zijn zoveel redenen waarom dit niet ok is.

    1. Er zijn al diverse rechtszaken geweest over of een “geheim” checksum algoritme gereproduceerd mag worden interoperabiliteit te bereiken met een systeem. Een van de zaken ging over ROM cartridges voor een spelcomputer en in die zaak werd besloten dat reproductie essentieel was voor interoperabiliteit.

      Ik betwijfel of een vaste “api key” die onversleuteld over Internet verstuurd wordt tot een doeltreffende technische voorziening gerekend kan worden. Het is triviaal om deze beveiliging te omzeilen.

      1. Er zijn al diverse rechtszaken geweest over of een “geheim” checksum algoritme gereproduceerd mag worden interoperabiliteit te bereiken met een systeem. Een van de zaken ging over ROM cartridges voor een spelcomputer en in die zaak werd besloten dat reproductie essentieel was voor interoperabiliteit.

        Dat klopt. En dat is op geen enkele manier vergelijkbaar met deze case.

        Ik betwijfel of een vaste “api key” die onversleuteld over Internet verstuurd wordt tot een doeltreffende technische voorziening gerekend kan worden. Het is triviaal om deze beveiliging te omzeilen.

        Vrijwel alle “apps” werken met een fixed client key. Dat geen HTTPS wordt gebruikt vind ik niet heel sterk maar je moet nog steeds significante moeite doen om netwerkverkeer te intercepten of te sniffen. Voor de gemiddelde gebruiker is dat zeker niet triviaal – en daarmee is de voorziening nog steeds effectief, IMHO.

        1. Sinds wanneer is wireshark aanzetten een “significante moeite”? Ik denk dat een Nederlandse rechter anno 2020 echt wel meegaat in het argument “ik keek gewoon naar het uitgaand netwerkverkeer en zag daarin clientKey:0xdeadbeef”. Zeker omdat je gerechtigd bent “de werking van [een legitiem verkregen] werk waar te nemen, te bestuderen en te testen teneinde de daaraan ten grondslag liggende ideeën en beginselen te achterhalen.” (artikel 45L Auteurswet).

          1. Eens, zeker als je het over een gebruiker heeft die gebruik maakt van ziijn wettelijke recht onder artikel 45L is het gebruik van Wireshark triviaal. En als je het als bijvangst van een legale activiteit krijgt kan je dat met de beste wil van de wereld geen effectieve beveiliging meer noemen.

            Als je een beveiliging maakt, zal je toch op zijn minst rekening moeten houden met mensen die gewoon hun rechten uitoefenen.

          2. Ik verschil daar echt met je in van mening, 99% van de mensen weet niet wat Wireshark is. En dat je “gewoon” je netwerkverkeer bekijkt en die key ziet maar die dan besluit te gaan (ge|mis)bruiken vind ik ook niet langs een giecheltoets komen. Maar dat dan terzijde. Misschien komt daar nog eens een uitspraak over.

            Dan artikel 45L: is het werk legitiem verkregen op het moment dat ik voor mijn werk een consumentenversie uitpluis? (Ervanuitgaande dat er in de licentie iets staat dat de consumentenversie niet zakelijk mag worden gebruikt). Of als ik dat als consument uitpluis, en vervolgens in de rol van werknemer de API key aan mijn werkgever ter beschikking stel?

            1. Hoeveel mensen weten wat Wireshark is is toch volkomen irrelevant.

              Wat relevant is; er zijn mensen die zich met volkomen legale reverse engineering bezighouden omdat ze bijvoorbeeld software willen maken die samenwerkt met een dienst. Daarnaast zijn er mensen die zich met netwerkbeveiliging bezighouden die dezelfde software ook in hun dagelijkse praktijk gebruiken.

              Als je een beveiliging maakt dan moet die daar rekening mee houden, anders is het niet alleen geen werkzame beveiliging, het is uberhaupt geen beveiliging.

              1. Een slot is ook een doeltreffende beveiliging, terwijl er genoeg slotenmakers zijn die een slot zonder enige moeite kunnen openen.

                Met het inzetten van specialisten kan je alles oplossen. Dat maakt iets nog niet triviaal.

                Met Wireshark en mitmproxy kan ik elke API key uit een app halen. Wat is dan wél een doeltreffende beveiliging?

                1. Een van de opties is een Time-based One-time Password zoals die uit rfc6238 of een challenge-response protocol waarbij de app (voor een request) bewijst een geheime sleutel te hebben. Voor TLS zijn er standaard implementaties voor client-side sleutels.

  7. Als dit mag, is dat dan hetzelfde, als dat het rechtmatig is om een privé licentie zakelijk te gebruiken? En bv ook een studentenlicentie zakelijk gebruiken. Als dat zo zou zijn, dan is het voor bepaalde software waarschijnlijk goedkoper om voor een medewerker een studie te betalen + studenten licentie, dan de zakelijke licentie.

  8. Henk Krol mocht ook niet inloggen met de gebruikersnaam en wachtwoord die hij ergens had horen zeggen en dat leverde hem een strafrechtelijke veroordeling op. ‘een lezer’ bevindt zich imho in dezelfde situatie. Hard-coded of niet, het is nooit de bedoeling van de leverancier geweest dat ‘een lezer’ de beschikking over de betreffende sleutel zou krijgen. Daarmee is het gebruik van die sleutel, anders dan als gebruiker van de consumenten-app, het aannemen van een valse hoedanigheid: ‘een lezer’ doet namelijk alsof hij de consumenten-app is, terwijl hij dat niet is.

    1. Ik zie een wezenlijk verschil tussen een per-user key en een hardcoded global key. Die laatste maakt geen onderscheid naar gebruiker, zodat je niet kunt zeggen dat deze persoon de sleutel ten onrechte gebruikt. Het gaat mij te ver om dat een valse hoedanigheid te noemen, nog even los van de bewijsbaarheid als je precies de aanroepen doet die de app ook zou doen.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.