Is het een datalek om ongesalte pincodes op te slaan?

hier-pinnenEen lezer vroeg me:

Een collega van me verloor onlangs zijn tankpas. Hij kreeg keurig een nieuwe, maar in een begeleidende brief werd hem de pincode gemeld: precies dezelfde als van zijn oude pas. Dat vind ik raar, dat is toch hartstikke onveilig? Dan slaan ze dus die pincodes leesbaar op in hun systeem. Is dat strafbaar onder de Wet datalekken?

Update (9:36) voor de duidelijkheid: de nieuwe pincode (die dus gelijk is aan de oude) staat leesbaar in de brief. De brief zat niet bij de pas maar in een aparte envelop die een dag later werd ontvangen.

Helaas komen dit soort basale veiligheidsproblemen nog steeds heel vaak voor. De wetswijziging die per 1 januari van kracht is, zou in theorie hier een prikkel tegen moeten bieden, maar ik heb er een hard hoofd in.

Natuurlijk is het enkel hebben van plaintext pincodes geen datalek. Volgens de wet is daarvan pas sprake als er werkelijk persoonlijke informatie gelekt is. Een dreigend datalek valt niet onder de definitie.

Gelukkig kent de nieuwe wet meer dan alleen datalekken. Al jaren staat er in de wet dat de opslag en andere verwerking van persoonsgegevens onder “adequate beveiliging” moet gebeuren, en per 1 januari staat er ook een boete op het niet adequaat beveiligen. Los dus van of dit daadwerkelijk tot een datalek heeft geleid of niet. In theorie kan de Autoriteit Persoonsgegevens dus een boete opleggen wanneer ze deze ongesalte pincodes aantreft.

Jammer is dan natuurlijk weer dat de kans uitermate klein is dat dit wordt bemerkt. Beveiliging is perfect tot het misgaat, en daarna heeft de stagiair een incident veroorzaakt in een voor het overige prima werkend systeem. Dat gaan boetes niet snel oplossen, tenzij je heel vaak en heel hard handhaaft. Of je de boete laat uitbetalen aan de getroffen personen in plaats van aan de overheid, een idee dat ik al vaker opperde (hoewel het ook nadelen heeft, zoals je eigen gegevens hacken en incasseren).

Eigenlijk wil je dat bedrijven een stevige prikkel voelen om hun beveiliging preventief op orde te hebben. Maar hoe krijgen we dát voor elkaar?

Arnoud

47 reacties

    1. Het “versleuteld opslaan van wachtwoorden” (of, in dit geval, pincodes) heeft geen enkele zin als je naar het “threat model” kijkt. Het is bedoeld om te beschermen tegen situaties waar de server al gecompromitteerd is, en je wilt voorkomen dat hergebruikte wachtwoorden (of pincodes) bekend worden. Als de server ze dus ook kan ontsleutelen, heeft het geen enkele zin.

      De veiligheid van hashes komt uit het feit dat ze onomkeerbaar (en “lossy”) zijn. Als je iemand zijn pincode op kunt sturen, dan voldoe je dus bij voorbaat niet aan die veiligheidseisen, ongeacht hoe ze opgeslagen zijn.

      1. Het “versleuteld opslaan van wachtwoorden” (of, in dit geval, pincodes) heeft geen enkele zin als je naar het “threat model” kijkt.

        Geen zin? Je wilt toch voorkomen dat iemand het wachtwoord weet als ALLEEN toegang tot de database wordt verkregen (via sql injections etc).

        1. Nee. Ten eerste moet SQL-injectie sowieso al niet meer voorkomen (er is toch al zo’n 5-10 jaar geen enkele reden meer voor, aangezien we nu parameterized queries hebben en die eigenlijk overal ondersteund worden), en ten tweede is read-only toegang tot een database zeer zeldzaam. Je hebt een paar scenario’s:

          1. Iemand met toegang tot de database wil gratis tanken. Hiervoor hoef je geen wachtwoorden of pincodes te kraken – je voegt gewoon je eigen onbeperkte kaartje toe, of verandert de pincode van iemand anders zonder te weten wat hun pincode eerst was. Dat is vaak nog makkelijker ook in het geval van SQL-injectie, omdat je geen output hoeft te zien.

          2. Je bent van plan om te proberen de pincodes van mensen elders te gebruiken, bijvoorbeeld bij hun bank, want misschien gebruiken ze daar wel dezelfde. Dit is waar hashes tegen moeten beschermen, en dat doen ze dan ook in alle gevallen wanneer je de juiste hash gebruikt – inclusief gevallen waar er wel toegang is verkregen tot de volledige server, en niet enkel tot de database. Bovendien zijn er vele andere manieren waarop encryptie kan falen – je kunt het verkeerd implementeren, of je database kan toegang geven tot het bestandssysteem, waar dus ook de encryptiesleutel opgeslagen staat.

          Kortom: encryptie gebruiken i.p.v. een hash is moeilijker om juist te implementeren, beschermt tegen (veel) minder aanvalsscenario’s, en biedt geen enkel voordeel. De enige juiste optie is om te hashen.

          1. Ik begrijp ook wel dat hashen beter is, maar als je aangeeft dat encrypten geen zin heeft, dan beschouw ik dat in vergelijking met een plain-tekst opslag. Ik lees het (je eerste opmerking) zo dat je van mening bent dat het geen zin heeft om te gaan encrypten als iemand wil stoppen met het plain-tekst opslaan van de wachtwoorden (als de server ze kan decrypten). Iemand met lees- en schrijfrechten tot de database (maar niet tot de encrypt en decryptcode) kan echter niets met de database met encrypte wachtwoorden (ook niet zichzelf toevoegen). Of bedoelde je dat het geen zin heeft t.o.v. hashen?

            1. Ik bedoel beiden. Bij een fatsoenlijk ontworpen applicatie bestaat het scenario “wel toegang tot de database, maar niet tot de rest van de server” eigenlijk gewoon niet. Bij niet fatsoenlijk ontworpen applications bestaat deze ook vaak niet, vanwege bijv. INFILE. Dus ja, in zo’n scenario zou encryptie in zekere zin extra veiligheid bieden – maar het scenario is dermate zeldzaam dat het eigenlijk nauwelijks het vermelden waard is.

    1. Huh? Nee dat is niet eenvoudig kraakbaar, zelfs niet eenvoudig te bruteforcen als er een goede salt is gebruikt. Als je 1 pincode weet kan je het misschien in theorie bruteforcen, maar op het moment dat ze achter de pin een hash plakken van de naw gegevens en die vervolgens encrypten maak je geen schijn van kans.

      Daarnaast kan ik uit het verhaal niet helemaal opmaken of de pincode nu wel of niet in de brief staat. Als die er wel in staat is het vreemd, als het er niet in staat en er staat alleen: “u kan dezelfde gebruiken”, dan is het geen probleem. De pas bevat waarschijnlijk alleen de gencrypte pincode, als die letterlijk uit de pas uit te lezen zou zijn dan was er (gezien het aantal actieve skim bendes) al heel lang geleden er een heel hoop ellende ontstaan.

        1. Niet als de database die je probeert te brute-forcen na 3 pogingen zegt: “doe het zelf maar, ik werk niet meer mee”. Dan is het uiterst onwaarschijnlijk dat je achter die pincode komt, als je de pincode niet weet.

        2. Dat ligt geheel aan het algoritme dat gebruikt wordt, en of er andere voorzorgsmaatregelen in het spel zijn (zoals bijv. een geheime salt). Je kunt bcrypt en scrypt bijvoorbeeld makkelijk zo instellen dat het 1 seconde duurt om te hashen op een gemiddelde computer. Voor duizend (gesalte) pincodes ben je dan al een-derde jaar bezig.

          Vergeet niet dat het doel van een gesalte hash is niet alleen om een enkele gebruiker te beschermen, maar voornamelijk om het ondoenlijk te maken om alle gebruikers aan te vallen.

          1. Dat snap ik en dat is op zich een goed punt, maar wat hier relevant is dat het, in jouw voorbeeld, ruim een kwartier kost om een willekeurige pincode te kraken. Dat lijkt me snel genoeg voor iemand met toegang tot een tankpas. En als diegene duizend tankpassen heeft, dan loont het de moeite om wat EC2-rekentijd te kopen.

            1. Dat is dan ook niet waar het tegen bedoeld is. Als je toegang hebt tot de database, dan kun je sowieso al gratis tanken – je voegt gewoon je eigen kaartje toe met onbeperkt krediet en een hash voor een pincode die je al weet. Daar hoef je geen pincode voor te kraken of achterhalen.

              De bedoeling van het hashen van wachtwoorden/pincodes is om situaties te voorkomen waar deze wachtwoorden bij andere diensten (die dus niet gecompromitteerd zijn) hergebruikt zijn door de gebruiker. Dan loont het ineens een stuk minder om EC2 te gebruiken.

    2. Hashen+salten heeft hier inderdaad helemaal geen zin. Het blijft wel een minpunt van PIN-systemen: de server-kant moet (effectief of letterlijk) plain-text PIN-codes opgeslagen hebben, dus als iemand die data kan lezen, weet ‘ie alle PIN-codes.

      Volgens mij is de veiligheid van PIN-systemen er vooral op gebaseerd dat je pasje na drie pogingen wordt ingeslikt, zodat je geen 10000 pogingen kunt doen. Dit faalt natuurlijk als je offline het PIN-code-bestand kunt kraken, en dan met de gevonden PIN-code in de hand in 1 poging je slag kunt slaan.

  1. Ik snap de ophef niet. Het enige wat je kan met die pincode van die tankpas, is tanken (indien je ook de tankpas in bezit hebt).

    Stel dat die pincode uitlekt en de tankpas wordt misbruikt. Dan vertel je de tankpasmaatschappij dat ze dermate onzorgvuldig met hun pincode zijn omgegaan, dat je je niet verantwoordelijk voelt voor het misbruik. En daar zijn ze het hoogstwaarschijnlijk mee eens. En dan blokkeren ze de oude tankpas en krijg je een nieuwe (hopelijk nu wel met een andere pincode 😉 )

    Het risico is dus volledig voor de tankpas-maatschappij. En die mogen zelf weten of ze dat risico nemen.

  2. Ik snap niet waarom de lezer denk dat dat als de tankmaatschappij zegt ” uw pincode is nog hetzelfde”, waarom je dan zou denken dat diezelfde tankmaatschappij ook de plaintext pincode in hun systeem heeft staan. Ze kunnen net zo goed de encrypted pin 1-op-1 gekopieerd hebben naar je nieuwe pas. Het wordt pas akelig als ze zouden zeggen: “Uw pincode is ongewijzig en nog steeds “2222”.

  3. (…) in een begeleidende brief werd hem de pincode gemeld (…)
    There’s your problem!

    Dat de pincode zó wordt opgeslagen dat deze weer terug te halen is, is niet heel goed maar vergefelijk. De aanname dat dit plaintext zal zijn is niet onredelijk, maar onbewezen. Mogelijk wordt deze versleuteld opgeslagen, terwijl de sleutel om deze te decoderen alleen op enkele andere productieservers staat.

    Maar de pas zou nooit samen met de pincode verstuurd moeten worden, hoe deze pincode verder ook opgeslagen wordt. Als iemand de pas onderschept, is het waarschijnlijk aan de ontvanger om op dit op te merken. Dit zou op z’n minst een aparte brief moeten zijn, maar liever nog een ander medium: e-mail, sms, persoonlijk af te halen, …

    1. De aanname dat dit plaintext zal zijn is niet onredelijk, maar onbewezen. Mogelijk wordt deze versleuteld opgeslagen, terwijl de sleutel om deze te decoderen alleen op enkele andere productieservers staat.

      Dit zou nog steeds niet acceptabel zijn, tenzij ze een hele goede reden ervoor hebben. Waarom zo’n complex (en makkelijker falend) systeem in elkaar zetten als je nooit een reden hebt om uberhaupt die pincodes nog terug te halen? Hash ze dan gewoon.

        1. “Versleuteling” (encryptie) is, zoals de naam al suggereert, een proces waar een ‘sleutel’ aan te pas komt, en dat dus omkeerbaar is. Bij een hash is dat niet het geval – er is geen sleutel, en het is onomkeerbaar.

          Beiden zijn concepten binnen de cryptografie, en voor complexere gevallen kunnen ze gezamenlijk gebruikt worden, maar verder is er geen enkele relatie tussen de twee en kunnen ze elkaar ook niet vervangen. Sterker nog, het is gevaarlijk om de ene te gebruiken terwijl je eigenlijk de andere nodig hebt. Dit artikel gaat verder in op de verschillen tussen diverse dingen binnen cryptografie.

      1. Ik ben niet overtuigd dat opslaan van pincode altijd een complex en makkelijk falend systeem is:

        1. We weten helemaal niet hoe veilig of onveilig de pincode is opgeslagen. (Misschien staat dit wel in een kaartenbak in een kluis 🙂 )

        2. Iedere keer andere pincodes uitgeven hoeft helemaal niet veiliger te zijn: mensen gaan dan eerder de pincode opschrijven; met een beetje pech zelfs op een briefje bij de pas.

    1. Inderdaad.

      Is hacken van alleen je eigen gegevens trouwens strafbaar? Als je het helemaal “white hat” doet, dus met responsible disclosure, geen misbruik van het lek (behalve incasseren van de boete dan), zou het dan eigenlijk legaal moeten zijn?

  4. naief modus aan: lijkt me duidelijk, het is geen datalek. De tankpasmaatschappij heeft braaf een offline systeem om de passen met pincodes te genereren, en in dat offline systeem zit een hardware encryptie device die de versleutelde pincode terug leest en in de pas opslaat en op de brief afdrukt. naief modus uit

    maar even serieus, ‘ongehashed’ is niet per see een datalek. Dat ze samen in 1 envelop zitten lijkt me wel dan weer een risico.

  5. De tankmaatschappij neemt uitgebreide maatregelen om te voorkomen dat er fraude gepleegd kan worden, zowel door criminelen die de pinpas en pincode proberen te stelen, als door eigen medewerkers. Een losse pincode is natuurlijk nog geen persoonsgegeven. Dat wordt hij pas in combinatie met (bijvoorbeeld) naam en adres van de eigenaar van de t/bankpas. Pincode en eigenaar komen samen in de begeleidende brief. Het afdrukken van de pincode op de brief, het in de envelop stoppen ervan, en het afdrukken van NAW-gegevens op de envelop gebeuren volledig unattended in een afgesloten, zwaar beveiligde computerruimte. Ook de envelop heeft een speciaal patroon gedrukt op de binnenkant zodat de pincode niet door de envelop heen is te lezen. Ook worden de pas en de brief met enkele dagen tussenruimte aan de gebruiker verstuurd.

    1. Mooi geformuleerd, zo zou een slimme PR-voorlichter het doen. Helaas is de praktijk eerder dat er een leeg bierkratje tegen die deur van de computerruimte staat en dat Hans een usb-stick met software van thuis meeneemt omdat dat handiger is dan gegevens overtypen, met alle virussen van dien. Verder blijkt er dan een onbeveiligde netwerkverbinding te zijn tussen de webserver en de authenticatieserver (dat was nodig voor die ene emergency fix van toen er in het Paasweekend niet getankt kon worden maar voor documentatie daarvan, laat staan een werkelijke fix, was geen budget). En oh ja, voor het gemak beheer je je account met de inlogcombinatie kenteken/pincode. Op je account kun je extra auto’s toevoegen, een extra adres én een extra pas aanvragen.

      (Elk van deze fails is afzonderlijk in de praktijk aangetroffen bij diverse bedrijven. De combinatie heb ik nooit gezien.)

  6. Sinds wanneer is “een boef heeft voor 1000 euro getankt” een lek van persoonsgegevens? Ik zie een financieel risico (voor het tankpas bedrijf), pas gejat uit de post -> boef gaat tanken met pas en pincode

    Maar 1256 == Meneer jansen, 6784 == Mevrouw de Wit zie ik hier niet.

      1. Arnoud, je ziet dat een aantal mensen toch opmerken ‘is dit wel een persoonsgegeven’. Ik denk er net zo over.

        Ik weet uit je posts en uit vorige discussies dat jij het beschermen van persoonsgegevens belangrijker vindt dan ik en dat jij ook sneller vindt dat iets een persoonsgegeven is dan ik, en dat jij ook sneller vindt dan ik dat bepaalde handelingen met die gegeven onder de nieuwe wet vallen.

        Overweeg het nog eens: is dit wel een persoonsgegeven? Voor zover ik tankkaarten ken kan je met die pincode niet eens aan de tankhistorie, daar heb je een aparte logingnaam en paswoord voor.

        Dat het uit veiligheidsoogpunt (met puur financiele schade) niet ideaal is, meteen akkoord.

        Maar het is toch wel heel vergezocht om hier een persoonsgegevensverhaal van te maken?

        1. De pincode an sich is niet herleidbaar tot een natuurlijk persoon, dus nee dat is geen persoonsgegeven. Maar hier is de pincode opgenomen in een brief aan een persoon. De brief is daarmee een pincode, en zodra je de pincode aan een pas of een loginnaam hebt gelinkt, is die combinatie dat ook.

          Het is geen datalek want er is (nog) geen misbruik van gemaakt. Maar de persoonsgegevens zijn wel in gevaar, omdat de pincode makkelijk te raden is – de pincode in de brief bewijst dat er niet gehasht is. Daarmee is er eenvoudig in te loggen. Je hebt wel een goed punt dat er mogelijk andere wachtwoorden gebruikt worden bij online inloggen. In dat geval is er geen security-risico.

          1. Maar hier is de pincode opgenomen in een brief aan een persoon. De brief is daarmee een pincode, en zodra je de pincode aan een pas of een loginnaam hebt gelinkt, is die combinatie dat ook.

            Ik begrijp niet wat je wilt zeggen. (vervang in de zin ‘pincode’ door ‘banksaldo’: mag de bank mij dan mijn banksaldo niet opsturen?)

  7. De PIN hoeft niet werkelijk bij de dienstverlener bekend te zijn. Bij enigsinds moderne passen (smartcards) hoeft de pin enkel in de chip van de pas bekend te zijn. Daar geeft de PIN toegang tot een private key die dan vervolgens de transactie beveiligd, de rest van de wereld weet alleen de public key. Als ze dan netjes bij elke pas een nieuwe random pincode uitgeven dan lijkt mij de kans dat iemand in Nederland een keer de zelfde pincode krijg zeker niet uit te sluiten.

    Mja… als ze klanten altijd dezelfde pincode geven (in de zelfde brief nogwel!) dan hebben ze waarschijnlijk een stagair ingehuurd om een excelletje met pincodes bij te houden.

  8. Dit is nog steeds geen datalek.

    Ten eerste kan het bedrijf gewoon een pincode achterhalen door er 10.000 uit te proberen, en jou zo de juiste pincode sturen. Je kunt hieruit dus niet afleiden dat de code ongehashed is opgeslagen.

    Ten tweede: Nou en? Je hebt niks aan een losse pincode. Je hebt ook nog een pasje nodig dat aan die code gekoppeld zit. Een pas+pincode is een two-factor authentication, wat het onaantrekkelijk maakt om een grote lijst met nietszeggende 4-cijferige codes te jatten.

    Een wachtwoord is veel kwetsbaarder, want het is een one-factor authentication. Een pincode is geen wachtwoord maar één factor in een dubbele authenticatie. Kraakbaar? Alles is kraakbaar. Aantrekkelijk om te kraken? Nee.

    1. En zelfs al heb je zowel een pasje als de pincode. Zodra je die gebruikt sta je zowel zelf als je auto op de video van de bewakingscamera’s die bij ieder tankstation hangen. Veel risico voor een relatief lage buit.

  9. Wat uit het verhaal niet duidelijk wordt, is of de pincode door de gebruiker gewijzigd kan worden, of dat de tankmaatschappij de pincodes genereert. In het laatste geval hebben ze namelijk een heel goede reden om die pincodes weer op te kunnen vragen: klantenservice. Klant is zijn pincode kwijt, wat nu? Dan is het makkelijk als je hem die toe kunt sturen, in plaats van een week niet kunnen tanken. Net zoals het makkelijk is dat je hem een nieuw pasje kunt sturen met dezelfde pincode, zodat hij geen nieuwe uit zijn hoofd hoeft te leren (en die dus maar ergens opschrijft omdat hij het allemaal niet meer bij kan houden). En voor het geval hij die pincode vergeten is, stuur je hem die apart toe. Scheelt weer een boel telefonische support voor mensen die dat pasje en dus hun pincode vergeten waren. Geeft dat extra veiligheidsrisico’s? Natuurlijk. Nou en? Security is een kostenpost, en die kosten moeten altijd afgewogen worden tegen de baten. Het grote risico hier betreft onbetaald tanken, want voor de rest kun je niks met die pincode. Voor dat risico kan de tankmaatschappij heel goed een kosten/baten analyse kunnen maken.

  10. Eigenlijk wil je dat bedrijven een stevige prikkel voelen om hun beveiliging preventief op orde te hebben. Maar hoe krijgen we dát voor elkaar?

    Rechters zouden slachtoffers van slechte beveiligingen heel snel gelijk kunnen geven wanneer zij een ander/bedrijf aansprakelijk houden voor geleden schade en tegenpartij niet aanemelijk kan maken dat beveiliging op orde was?

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.