Is het een datalek om ongesalte pincodes op te slaan?

| AE 8337 | Security | 47 reacties

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

Deel dit artikel

    • 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.

        • 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.

          • 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?

            • 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. 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, …

  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.

    • 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.

      • 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?

        • 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.

  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.

  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?

Laat een reactie achter

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

(verplicht)

Volg de reacties per RSS