Wie is er aansprakelijk voor een door de browser onthouden internetbankierenwachtwoord?

| AE 10709 | Security | 24 reacties

ING onderzoekt of het mogelijk is zijn Chrome-inlogpagina weer ondersteuning te laten bieden voor het invullen van wachtwoorden met een wachtwoordmanager. Dat meldde Tweakers onlangs. De bank had dit geblokkeerd uit angst dat mensen hun browser dit laten onthouden, zodat een derde zonder veel moeite vanaf die laptop kan internetbankieren met alle gevolgen van dien. Wachtwoordmanagers zijn veiliger, maar werken met dezelfde herkentechniek voor inlogpagina’s. De maatregel gaf dan ook de nodige ophef, waaronder “maar het is toch jouw keuze of je zo onveilig bent”? Ja, maar bij bankieren zijn de regels net even anders.

Hoofdregel uit het recht is dat je aansprakelijk bent voor je eigen keuzes. Dus als jij de sleutels van je pand slordig opbergt, dan kun je dat moeilijk anderen verwijten. En specifiek bij internetdiensten is het dan ook jouw keuze en jouw risico hoe je wachtwoorden kiest, beheert en toegankelijk maakt.

Natuurlijk, wachtwoorden kunnen worden gestolen of afgekeken. Maar hoe moet een internetdienst weten dat iemands login door een ander gebeurde? Behoudens heel concrete aanwijzingen zou ik dat niet weten. En pas bij een hele grote of belangrijke dienst zou ik vinden dat die actief moeten monitoren op ongebruikelijk inloggedrag.

Specifiek bij banken ligt het iets complexer. De wet zegt namelijk dat een bank altijd aansprakelijk is voor beveiligingsincidenten, behalve bij fraude, opzet en grove nalatigheid van de klant (art. 7:529 BW). Bij gewone slordigheid of onoplettendheid van de internetbankierende consument draait de bank dus op voor ongeautoriseerde transacties, met hooguit een eigen risico van 150 euro voor die consument. Per ongeluk of uit gemakzucht kiezen voor het onthouden van je inlogwachtwoord voor bankieren lijkt mij een gevalletje slordigheid en géén grove nalatigheid.

Dit risico komt ook weer terug in de Uniforme Veiligheidsregels van de banksector, die expliciet over beveiligingscodes vermelden:

Schrijf of sla de codes niet op. Of, als het echt niet anders kan, alleen in een voor anderen onherkenbare vorm die alleen door uzelf is te ontcijferen. Bewaar in dit geval de versleutelde informatie niet bij uw bankpas of bij apparatuur waarmee u uw bankzaken regelt;

Ik kan dit niet anders lezen dan dat je je browser geen wachtwoorden mag laten opslaan, maar dat je ook geen wachtwoordmanager mag gebruiken. Die “apparatuur” is immers je laptop of telefoon, en de wachtwoordmanager slaat daar het wachtwoord bij op. Dus wat dat betreft is ING wel consistent.

Tegelijk: een wachtwoordmanager en dan een stevig master password is gewoon de beste manier om jezelf te beveiligen bij online diensten. Dus dit voelt als een best wel fundamenteel dilemma.

Arnoud

Google gaat telefoonmakers verplichten beveiligingsupdates aan te bieden

| AE 10581 | Security | 20 reacties

Google gaat telefoonmakers contractueel verplichten om smartphones van software-updates te voorzien. Dat meldde Nu.nl vorige week. Een onderwerp waar al veel over te doen is, onder meer vanuit onze Consumentenbond met haar actie die onder meer leidde tot een rechtszaak tegen Samsung met de eis tot langer updaten van smartphones. Fabrikanten zijn volgens mij gewoon wettelijk verplicht dit te doen, maar werken daar bepaald niet enthousiast aan mee. Ergens is het dan wel erg frappant dat Google met zo’n aankondiging (waarschijnlijk) wél iedereen gewoon meekrijgt.

Natuurlijk is het heel logisch dat als Google het zegt, iedereen zich eraan gaat houden. Google heeft het merk Android en stelt stevige eisen aan het gebruik van deze software. Dat mogen ze, en je bent uiteindelijk niet formeel verplicht om Android op je telefoon te zetten. Maar praktisch gezien heeft Google een forse marktmacht (een dikke 85% van de mobielebesturingssystemenmarkt) dus vanuit dat standpunt kun je wel zeggen dat Google echt afdwingt dat je dit moet doen.

Het kan misbruik van je machtspositie zijn om zo’n verplichting op te leggen. Maar hier lijkt het me zó in het voordeel van de markt en de consument dat ik me niet kan voorstellen dat iemand er werkelijk met succes bezwaar tegen kan maken.

Het raakte me vooral omdat het er nu op lijkt dat een marktpartij (Google) méér voor elkaar kan krijgen dan de wetgever en uitvoerende macht bij elkaar. Dat is ergens raar, want regels in het voordeel van de markt of maatschappij lijken me regels die je vanuit de overheid zou verwachten, inclusief handhaving daarvan. Maar het is wel iets dat je typisch vaker ziet bij internetbedrijven, dat zij veel effectiever normen stellen en handhaven dan de formele overheid. Ik zou echt eens een studie rechtsfilosofie moeten gaan doen, wat zit hier achter, hoe past dit in de grondslagen van het recht?

Arnoud

Kan een werknemer verplicht worden mee te werken aan een vingerafdrukslot?

| AE 9700 | Informatiemaatschappij | 19 reacties

Een intrigerende vraag op Reddit (de /r/Nederland):

I have a 6 months contract. My employer is adding a fingerprint lock to the door, I don’t want my fingerprint or the hash calculated from it to be taken, can he force me?

(Ik baseer het antwoord maar even op de AVG/GDPR want die is het relevantst voor de lange termijn.)

Een vingerafdruk wordt gezien als een biometrisch persoonsgegeven: fysieke, fysiologische of gedragsgerelateerde kenmerken van een natuurlijke persoon waarmee identificatie mogelijk is. Wel moet het dan gaan om verwerkingen met het oog op de unieke identificatie van een persoon, maar daarvan lijkt me hier wel sprake.

Het verwerken van biometrische persoonsgegevens valt onder de zeer strenge regels voor bijzondere persoonsgegevens. Dat mag kort gezegd niet, tenzij in de AVG staat van wel. Wie dan doorleest, zal in de AVG zelf niets vinden waarin staat dat dit mag. Echter, hoewel het hier gaat om een Europese wet is het specifiek op dit punt toegestaan dat landen eigen regels maken over biometrische persoonsgegevens.

Nederland heeft dat gedaan, althans in concept: de concepttekst van de Uitvoeringswet AVG bepaalt (artikel 26) dat deze gegevens mogen worden verwerkt ter identificatie. Voorwaarde hiervoor is wel dat de verwerking noodzakelijk en proportioneel is ter behartiging van gerechtvaardigde belangen van de verwerkingsverantwoordelijke of een derde. Het is onder omstandigheden eveneens toegestaan om biometrische gegevens te verwerken indien de betrokkene hiervoor in vrijheid toestemming heeft gegeven.

Dat van die toestemming kun je vergeten als werkgever. Even kort door de bocht, omdat iedereen graag salarisverhoging/vast contract/promotie wil, zullen ze op iedere toestemmingsvraag ja zeggen uit angst dat mis te lopen. Dat is dus niet vrijwillig.

Je moet als werkgever dus op zoek naar een rechtvaardigingsgrond. Waarom moet dat nou met biometrie, die deur. Is er werkelijk geen andere, net zo effectieve oplossing? Natuurlijk, sleutels kan men kwijtraken en pincodes kunnen worden vergeten, uitgelekt of afgekeken. Een portier is ook ietwat begrotelijk. En de kans dat een derde vingers gaat afsnijden om binnen te komen is bij het gemiddelde Nederlandse bedrijf niet zo groot.

Vanuit dat standpunt denk ik dat het dus wel mag, mits alléén voor toegangscontrole. Zou je die vingerafdrukken ook gaan gebruiken om bijvoorbeeld te kijken hoe goed iemand zijn werk doet (“neemt wel héél vaak pauze”) dan zul je daar een apart verhaal voor moeten bouwen waarom jouw belang als werkgever het alsnog wint van de privacy van de werknemer.

Arnoud

Mag je andermans brakke IoT-apparaten op afstand onschadelijk maken?

| AE 9404 | Innovatie, Security | 25 reacties

De brickerbot is terug, las ik bij Ars Technica. Het gaat om een initiatief van de mysterieuze “Janit0r”, een handige hacker die brakke apparaatjes met internetverbinding kaapt en gebruikt om hun broertjes en zusjes permanent stuk te maken (“bricken”, oftewel de enige resterende functionaliteit is die van een baksteen). Dit omdat dergelijke apparaten zó veel… Lees verder

Ja duh, natuurlijk moet een stemwijzer werken met https

| AE 9273 | Privacy | 6 reacties

De Autoriteit Persoonsgegevens (AP) heeft onderzoek gedaan naar de beveiliging van websites die interactieve stemhulp bieden, las ik bij Nu.nl. De privacytoezichthouder meldt dat 14 van de 24 onderzochte websites geen gebruik bleken te maken van een versleutelde verbinding, en na de vingertik hebben vier meteen de handdoek in de ring gegooid. De rest is… Lees verder

‘Meeste bedrijfssites versturen gevoelige gegevens onveilig’

| AE 9215 | Ondernemingsvrijheid, Privacy | 25 reacties

Honderdduizenden zakelijke websites laten gebruikers gevoelige informatie verzenden zonder dat daarvoor van een beveiligde verbinding gebruik wordt gemaakt, blijkt uit een onderzoek van domeinbeheerder SIDN en MKB Servicedesk dat woensdag wordt gepubliceerd. Dat meldde Nu.nl onlangs. De ‘gevoelige gegevens’ zijn meestal NAWE-gegevens, maar ook inloggegevens en wachtwoorden komen voor. Maar liefst 86% van de onderzochte… Lees verder

Is e-mail nou wel of niet veilig genoeg voor communicatie van basale persoonsgegevens?

| AE 9042 | Privacy, Security | 38 reacties

Een lezer vroeg me: Ik heb een discussie met het waterbedrijf. Zij mailen mij met allerlei informatie, maar nemen elke keer ook naam, adres, klantnummer en dergelijke van mij op. Laatst stuurden ze zelfs mijn bankrekeningnummer in een mail. Op mijn vraag hoe dat zit met bescherming van persoonsgegevens, zei men dat e-mail buiten haar… Lees verder

Hoe snel moet je van de wet een nieuwe securitystandaard implementeren?

| AE 8962 | Security | 13 reacties

Een lezer vroeg me: In de ICT zijn de beveiligingseisen volop in beweging. Het is dus welhaast onmogelijk om deze allemaal stipt na te volgen, zeker bij grote pakketten waar het doorvoeren van wijzigingen vele maanden (zo niet jaren) kan kosten vanwege complexiteit en testen en evaluatie. Is er juridisch gezien een termijn waarbinnen nieuwe… Lees verder

Mag ik mijn klanten verplichten SSL/TLS te gebruiken?

| AE 8734 | Security | 37 reacties

Een lezer vroeg me: Mag ik, als hostingprovider, klanten dwingen om SSL/TLS te gebruiken? Via een aantal scripts is het gehele proces te automatiseren, zodat er tijdens het aanmaken van een account een certificaat wordt aangemaakt (via Let’s Encrypt, dus geen meerkosten) en verbindingen vervolgens over SSL/TLS forceren (mod_rewrite en HSTS header). Ik heb veel… Lees verder