Hej Datatilsynet, hvem er egentlig ansvarlig for datalæk som følge af dårlige kodeord?

Illustration: Screenshot/Pwned Passwords
Det er ikke nødvendigvis den dataansvarlige, der får ørerne i maskinen, hvis forklaringen på et datalæk er dårligt valgte bruger-kodeord, oplyser Datatilsynet.

Forleden kom det frem, at Stofa var blevet udsat for et hackerangreb, hvor data fra flere brugerkonti var blevet lækket. Ifølge Stofa tyder noget på, at de pågældende brugere har valgt for svage kodeord.

Læs også: Datalæk: 2.000 Stofa-kunder ramt af hackerangreb

Men generelt set, hvem har så egentlig ansvaret for datalæk som følge af et dårligt valgt kodeord? Brugeren eller den dataansvarlige?

It-sikkerhedsspecialist og cand.jur. ved Datatilsynet Allan Frank forklarer, at den dataansvarlige har ansvaret for behandlingen og sikkerheden i forbindelse med behandlingen. Men brugeren har også selv et ansvar for ikke at vælge eksempelvis et svagt eller allerede kompromitteret password.

»Udgangspunktet er, at det er brugeren af ydelsen, der selv vælger sit password,« siger Allan Frank.

Han fortæller, at det kan være svært at gardere sig mod, at brugere vælger usikre login-oplysninger, selv hvis man håndhæver det, han kalder fornuftige krav til password-længde og -kompleksitet.

»Der er vanskeligt at forpligte nogen overfor brugernes egen mangel på agtpågivenhed. Selvom det er minimum otte tegn og skal være komplekst, kan de jo sagtens vælge det password, de også har brugt på en eller anden social platform, der allerede er blevet hacket,« siger Allan Frank.

Datatilsynet kommer altså ikke per automatik efter en dataansvarlig, hvis årsagen til, at en bruger bliver udsat for et datalæk, er, at brugeren selv har anvendt et svagt eller allerede misbrugt kodeord.

Men ...

Når det er sagt, så kan den dataansvarlige ikke nødvendigvis frasige sig ansvaret for en brugers valg af et dårligt kodeord, påpeger Allan Frank.

Det afhænger i sidste ende af situationen.

Frank forklarer, at den dataansvarlige altid skal foretage en risikovurdering, og her indgår også brugeres adgang til oplysningerne i den samlede vurdering.

»Det vigtigste i første omgang er, at den dataansvarlige har foretaget en risikovurdering.«

Det betyder ifølge Allan Frank, at hvis det eksempelvis drejer sig om sundhedsoplysninger, betalingskortoplysninger og lignende, så kan det tale for, at den dataansvarlige stiller større krav til brugerens valg af kodeord, end hvis der for eksempel er tale om navn og mailadresse.

»Det beror på den risikoafvejning, den dataansvarlige foretager. Efter reglerne i forordningen (persondataforordningen, red.) skal afvejningen føre til passende sikkerhedsforanstaltninger,« siger han.

Passende sikkerhedsforanstaltninger

Og passende sikkerhedsforanstaltninger kan i princippet godt være brugerkrav om en bestemt kodeordslængde og -kompleksitet. Ligesom der for eksempel kan stilles krav om, at kodeordet skal skiftes med bestemte intervaller. Implementering af multifaktor-autentifikation kunne også være et eksempel på en passende sikkerhedsforanstaltning.

»Det vil komme an på en konkret vurdering, om de sikkerhedsforanstaltninger, der er foretaget, kan anses for at være passende efter artikel 32 i forordningen,« siger Allan Frank.

Han fortæller, at Datatilsynet ud fra en sikkerhedsmæssig betragtning anbefaler, at man i forhold til kodeord prøver at lægge sig op ad de retningslinjer, som for eksempel den amerikanske standardiseringsorganisation NIST står bag.

I disse retningslinjer bliver der blandt andet lagt op til at kontrollere kodeord op mod lister med allerede kendte kompromitterede kodeord.

I den forbindelse kan sikkerhedsmanden Troy Hunts site 'haveibeenpwnd.com' måske være et besøg værd. Han har samlet en masse kodeordslæk, som det er muligt at downloade i hash'et format. Herefter er det så muligt teste, hvorvidt et kodeord allerede optræder i et datalæk.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (20)
Per Jørgensen

Har svært ved at se hvorfor brugeren i det hele taget kan lave sig et nemt og usikkert password. Der kan sættes så mange restriktioner på som sysadmin - så det ansvar fratages brugeren - hvis man har sat sine standard for password - ordenligt op fra starten.

Jeg mener det bestemmer sysadmin da bare uden hensyn til brugeren og dermed er man ovre det problem

Jakob Møllerhøj Journalist

Det er sjovt - eller foruroligende - at multi-faktor authentication ikke er nævnt i artiklen. Hvor blev det af?

Nu har jeg for en god ordens skyld tilføjet multifaktor-autentifikation i artiklen også som endnu et eksempel på en passende sikkerhedsforanstaltning. Multifaktor er desuden nævnt i de NIST-retningslinjer, Datatilsynet henviser til. Jakob - V2

Henrik Hansen

Og det at kodeordet skal skiftes med bestemte intervaller - er det ikke et lidt dårligt råd? Der findes flere eksempler, som sætter spørgsmålstegn ved denne praksis.


Samtlige opdaterede anbefalinger fra f.eks. efterretningstjenester og andre organisationer der ved lidt om området anbefaler at man ikke skifter med faste intervaller.

De anbefaler også at man ikke kræver komplicerede kodeord mv., men det er der heller ingen der hører efter.

De fleste steder sidder i dag fast i forældede og tåbelige regler for kodeord som virker modsat hensigten.

Jan Vennike

Og det at kodeordet skal skiftes med bestemte intervaller - er det ikke et lidt dårligt råd? Der findes flere eksempler, som sætter spørgsmålstegn ved denne praksis.

Kan huske på en tidligere arbejdsplads for mange år siden at der ville ledelsen havde der skulle skiftes kodeord en gang om måneden - hvorefter RIGTIGT mange brugere begyndte at buge januar1, Februar2, Marts 3 osv :-)

Christian Münster

hvorefter RIGTIGT mange brugere begyndte at buge januar1, Februar2, Marts 3 osv :-)


Ja selvfølgelig :) Sådan er de fleste mennesker, i den virkelige verden. Altså den man ikke kan se fra sit udviklingsmiljø. De er alle sammen dovne, gider ikke fejlsøge, prøve igen og skal man trykke på mere end én knap, bliver man trist. Og sådan skal det være!
Jeg er selv ekstremt doven, når jeg har en fjernbetjening til tv i hånden.

Det virkelige problem, efter min mening, er teknikere der forbliver i troen, at brugere forstår og GIDER lave ordentlige passwords, som overholder standarder såsom tal, symboler osv.
Yderligere; kræver vi udviklere også, de skal kunne huske denne række kryptiske bogstaver, som de i øvrigt skal ændre hyppigt?
Glem det; og nej - almindelige brugere har ikke evner til en password manager og det skal de heller ikke.

Som en anden bruger nævnte - 2 faktor er det eneste rigtige, hvis i spørger mig.
SMS, mail, app på smartphone eller en due ind af døren, med en seddel. Take your pick!

Bjarne Nielsen

Kunne du give et par ref."

Hvad med den her:
https://www.ncsc.gov.uk/articles/problems-forcing-regular-password-expiry

The NCSC now recommend organisations do not force regular password expiry. We believe this reduces the vulnerabilities associated with regularly expiring passwords (described above) while doing little to increase the risk of long-term password exploitation. Attackers can often work out the new password, if they have the old one. And users, forced to change another password, will often choose a ‘weaker’ one that they won’t forget.

Jan Heisterberg

at artiklen (Datatilsynet) fastslår, at den nævne administrator har ansvaret for kontrol af opfyldelsen af den fastsatte standard for passwords.

Hvis en bruger kan slippe afsted med at bruge 1234, så burde administratoren gøres anvarlig. Hvis 8 tegn er kravet, så .......
Og hvor svært kan det være at udelukke enhver brug af årstal og månedsnavne ?

Af historiske grunde lver mange i den vildfarelse at et password er et WORD. Mon ikke den pædagogiske ændring til "passphrase" kunne hjælpe ?
Hvad med "Elsker Version2" (ganske vist kun 15 tegn).
eller
"Hader stadig Regeringen"

Kjeld Flarup Christensen

Kan man gøre den data ansvarlige ansvarlig selvom hackeren kender password på forhånd. Hvis der er 2.000 konti der er ramt, så vil jeg sige ja.

For at det skulle kunne lykkes, så må angriberen jo have haft lov til at stå og hamre løs på systemet med det ene login efter det andet. Det vil kunne ses i logs, og det burde også logges, og anvendes, så der for det første kommer et delay, og for det andet, så bør IP adressen blokeres efter for mange fejl.

Desværre er jeg bange for at for lidt software understøtter dette. Hvis der var, så ville en fire cifret pinkode være sikkerhed nok til de fleste ting.

Tobias Tobiasen
Tobias Tobiasen
Lars Christensen

GDPR foreskriver tydeligt, at den Datansvarlige, er den der bestemmer hvilke værktøjer der skal benyttes i forbindelse med databehandling - så langt kan vi formodentlig godt blive enige?
GDPR foreskriver tydeligt, at der skal være en sammenhæng mellem værktøjers brug og dets design - er der nogen der er uenige i dette?
At benytte/starte/notere et password foregår normalt via en digital formular, hvor designet "normalt" er forsynet med en tjekfunktion, der lige sikrer at password overholder nogle minimumsregler.
Såfremt Stofa og andre giganter fravælger dette minimums sikkerheds niveau, så hænger de altså på den - det kan der forhåbentlig heller ikke være tvivl om?

Anders Hybertz

Hvis man kræver at brugere af et system skal logge på med username/password, ville det så ikke være god stil, at man faktisk krypterede den/de tabeller på databasen hvor denne information lagres.

De fleste databaser kommer idag med mulighed for integreret kryptering på tabel/kolonne niveau. Derudover burde der også være seperation of duties implementeret, således at DBA'er kunne administrere databasen, men ikke læse forretningsdata på databasen.

Ville dette alt andet lige ikke gøre det ganske mere besværligt at komme i besiddelse af brugernes simple passwords.

Jeg ser det lidt som et delt ansvar, men hvor databehandleren er den IT kyndige - eller forventer jeg lidt meget :)

Kjeld Flarup Christensen

Det er ikke helt så simpelt. Hvis angriberen har adgang til et botnet så vil angrebet være distribueret og så hjælper det ikke at blokke en enkelt IP adresse. Og hvis man blokerer brugeren efter 10 forkerte forsøg så er man sårbar over for dos angreb.

Med hvad så når fx studernede på eduroam (universiteternes netværk) logger på en tjeneste? Hvis de alle sammen har samme IP (eller subnet)? Skal alle så opleve delay? Hvad hvis ens internetudbyder bruger et CGN?


Nu er det faktisk ret sjældent et login fejler.
Den værste situation er faktisk, hvis du befinder dig bag et CGN, og der også er en bot på dette CGN.

Et værktøj som fail2ban bruges allerede i dag, og skaber potentielt netop den slags situationer. Jeg har dog ikke hørt at det skulle være et stort problem.

Hos Viptel installerede jeg nogle heftige automatiske SIP blokeringer. Det gik godt fordi de IP adresser der blev angrebet fra ikke var danske. Naturligvis vil situationen være en anden for f.eks. Gmail, Ebay eller nogen af de andre store sites. De har så også ressourcerne til at tage hånd om sagen på anden vis. Er man et forholdvis begrænset site, så kan man bedre tillade sig IP blokere for mindre.

Jeg har mærkeligt nok heller aldrig set SIP angreb fra botnets. Sandsynligvis fordi der er forskel på at bruge en bot til et DOS angreb og på at lave et rigtigt indbrudsangreb. Det er en hel del mere software som skal loades ud på bot'en. Foruden at det skal kunne virke på ukendte platforme.

Derfor vil en sikring mod hammering, være en opskalering af kampen, hvor hackerne bliver nødt til at investere mere i deres angreb.
Det umuliggør ikke angreb. Nye låse på en dør umuliggør heller ikke indbrud.

Kjeld Flarup Christensen

Har svært ved at se hvorfor brugeren i det hele taget kan lave sig et nemt og usikkert password. Der kan sættes så mange restriktioner på som sysadmin - så det ansvar fratages brugeren - hvis man har sat sine standard for password - ordenligt op fra starten.


Hvad er sikkert og usikkert. Og hvornår er det så usikkert, at der skal udstedes en bøde?

"Du krævede ikke to specialtegn i passwords, derfor idømmes du en bøde!"

Vi ender i en juridisk vilkårlighed her.

Kristoffer Balling

"Kunne du give et par ref."

Troy Hunt har en god gennemgang af de opdaterede passwordanbefalinger fra NIST, Microsoft og NCSC som gør op med de gængse krav om sammensætning (specialtegn, tal, store/små bogstaver) og tvungen regelmæssig skift af password. Det anbefales også at forbyde brug af passwords som allerede er lækket (det kan tjekkes uden at lække det password som undersøges).

Log ind eller Opret konto for at kommentere
Pressemeddelelser

Welcome to the Cloud Integration Enablement Day (Bring your own laptop)

On this track, we will give you the chance to become a "Cloud First" data integration specialist.
15. nov 2017

Silicom i Søborg har fået stærk vind i sejlene…

Silicom Denmark arbejder med cutting-edge teknologier og er helt fremme hvad angår FPGA teknologien, som har eksisteret i over 20 år.
22. sep 2017

Conference: How AI and Machine Learning can accelerate your business growth

Can Artificial Intelligence (AI) and Machine Learning bring actual value to your business? Will it supercharge growth? How do other businesses leverage AI and Machine Learning?
13. sep 2017
Jobfinder Logo
Job fra Jobfinder