Datatilsynet afviser anmeldelse af manglende HTTPS på læge-hjemmeside - er det et problem?

27. april 2017 kl. 05:1149
Datatilsynet afviser anmeldelse af manglende HTTPS på læge-hjemmeside - er det et problem?
Illustration: REDPIXEL.PL, BigStock.
Ifølge Datatilsynet er det ikke et problem, at der ingen synlig hængelås er på en side, hvor der eksempelvis skal indtastes et cpr-nummer.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Skal der være en HTTPS-forbindelse på hjemmesider, hvor der skal indtastes følsomme data, eller er det nok, at selve formularen, hvor data bliver indtastet i, sender via en krypteret forbindelse?

Annonce:

Infosecurity Denmark 2017

Oplev Danmarks største IT-sikkerhedsevent den 3.-4. maj 2017 i Øksnehallen, København

Bliv opdateret, når vi præsenterer 22 danske og internationale keynotes fra blandt andet Tokyo Institute of Technology, Interpol og Dropbox.

Netværk med fagpersoner fra hele branchen – og vælg frit blandt 80 seminarer og cases inden for IT-sikkerhedsemner som compliance, cybercrime, IoT, enterprise mobility og cloud security.

Læs mere på Infosecurity.dk

Ifølge et svar fra Datatilsynet, så er det tilstrækkeligt med beskyttelse, hvis formularen blot sender data krypteret. Der behøver altså ikke være en grøn hængelås eller stå HTTPS i det synlige adressefelt i browseren.

Version2-læser Dan Storm er stødte tidligere på året på en hjemmeside for en læge, hvor der blandt andet skal indtastes CPR-nummer.

Artiklen fortsætter efter annoncen

Selve siden er ikke beskyttet med HTTPS, og det fik Dan Storm, der arbejder som Senior Backend Developer, til at rette henvendelse til Datatilsynet.

»Jeg mener dog, at siden ikke overholder Datatilsynets udtrykkelige krav om kryptering ved overførsel af personnumre via hjemmesider,« skrev Dan Storm blandt andet i sin henvendelse til Datatilsynet.

Ikke nok beskyttelse

Dan Storm påpeger desuden i henvendelsen, at oplysningerne, der bliver indtastet i den indlejrede formular på den pågældende side godt nok bliver sendt via HTTPS. Men det er ikke godt nok, mener han.

»Dette er dog ikke nok til at beskytte mod man-in-the-middle angreb, siden med formularen ikke er leveret via en krypteret forbindelse,« skriver Dan Storm i sin henvendelse til Datatilsynet og fortsætter:

Artiklen fortsætter efter annoncen

»Ved at siden med formularen mangler kryptering kan man, via et man-in-the-middle angreb, modificere sidens indhold uden den besøgendes umiddelbare viden og derefter opsnappe både CPR nummer, kommentaren til lægen og og e-mailadressen - en ret triviel opgave i virkeligheden.«

Ingen anledning til bemærkninger

Datatilsynet har set på Dan Storms henvendelse, og essensen i det relativt kortfattede svar fra tilsynet lyder:

»Datatilsynet kan oplyse, at tilsynet i forbindelse med en tidligere sag har undersøgt sikkerheden på den pågældende hjemmeside. Undersøgelsen gav ikke tilsynet anledning til bemærkninger, da transmission af oplysninger på hjemmesiden ifølge en IT-sikkerhedskonsulent i tilsynet sker via HTTPS.«

Dan Storm har sidenhen sendt korrespondancen til Version2. I et efterfølgende interview uddyber backend-udvikleren, hvorfor han mener, det er et problem med den manglende HTTPS-beskyttelse - ofte vist via en hængelås - på den pågældende hjemmeside.

Artiklen fortsætter efter annoncen

»Når certifikatet er valideret, og man dermed får den 'grønne hængelås', så sikrer HTTPS-laget, at indholdet fra serveren er uændret, når det når klienten. Det er grundstenen i HTTPS,« siger Dan Storm og fortsætter:

»Når hængelåsen ikke er der, så har brugeren ikke nogen garanti for, at indholdet ikke er ændret mellem serveren og brugeren, der sidder og kigger på siden. Og det er her, problematikken omkring man-in-the-middle kan opstå.«

Det vil eksempelvis sige, at hvis en bruger lokkes til at koble på et ondsindet wifi-hotspot, som en angriber kontrollerer, så kan angriberen manipulere indholdet på siden fra lægen, og opsnappe de oplysninger, brugeren indtaster.

»Jeg synes, det er rimeligt banalt, men nu arbejder jeg selvfølgeligt også med det. Men som borger havde jeg nok en eller anden forventning om, at de ville kunne forstå inde ved Datatilsynet, at det her er et problem.«

Forskelligartet opfattelse

Dan Storm peger på, at problemstillingen nok også udspringer af en forskelligartet opfattelse hos ham selv, og så Datatilsynet i forhold til, hvad det vil sige, at oplysninger bliver sendt krypterede.

Og han mener i den forbindelse ikke, det giver mening at tale om, at oplysninger på en ikke HTTPS-beskyttet side bliver sendt krypterede, uanset om der så måtte være en indlejret HTTPS-formular på sitet.

Problemet er blandt andet, påpeger Dan Storm, at oplysningerne, som bliver indtastet i formularen, kan blive opsamlet via et Javascript, skudt ind på den ubeskyttede side.

»Vi kan ikke forvente, at alle forstår forskellen (på hængelås og ingen hængelås). Man kan sige, at hvis der var krav om, at siden, hvor oplysningerne bliver indtastet, er krypteret, så har man jo gjort hvad man kunne for at beskytte data fra fra Datatilsynets side - og selvfølgeligt også fra udbyderen af sitets side. Sådan er det ikke nu,« siger han.

Version2 har bedt Datatilsynet forholde sig til Dan Storms kritikpunkter.

Datatilsynet: Hængelås er ikke nogen garanti

Kontorchef i tilsynet Lena Andersen oplyser via mail, at »vi ikke ønsker at sagsbehandle med medierne som mellemmand - hvis den pågældende borger har yderligere han vil vende med os, må han rette direkte henvendelse hertil – ikke via medierne.«

I forhold til den generelle pointe om, at Datatilsynet ikke mener, det er nødvendigt med en HTTPS-forbindelse/hængelås på et site, hvor der indtastes eksempelvis et cpr-nummer, oplyser Lena Andersen, at tilsynet ikke stiller krav om hængelås, »da en synlig hængelås eller farven på hængelåsen ikke er nogen garanti.«

Datatilsynets ikke udelte begejstring for synlige HTTPS-forbindelser/hængelåse er ikke ny.

Version2 omtalte i oktober sidste år en såkaldt sikkerhedstekst fra Datatilsynet. Det skete i en artikel med overskriften 'Datatilsynet advarer mod at stole på hængelåsen i browseren'.

I sikkerhedsteksten fra Datatilsynet lyder det blandt andet:

»Visning af hængelås eller HTTPS i browserens adressefelt garanterer ikke imod, at uvedkommende kan kikke med eller endda ændre i dataudvekslingen.«

I teksten bemærker tilsynet desuden, at en hængelås eller HTTPS i browserens adressefelt indikerer, at »der er anvendt kryptering, men ikke hvilken slags, eller i hvilken grad krypteringen beskytter imod, at uvedkommende omdanner de kryptere data til læsbart format.«

Hvad tænker Version2's læsere? Har Datatilsynet en pointe i, at det ikke i sig selv giver mening at kræve en umiddelbart synlig HTTPS-forbindelse på en hjemmeside, hvor der indtastes eksempelvis et cpr-nummer - altså forudsat at data ellers sendes krypteret fra siden?

Eller er det Dan Storm der har ret i, at der bør være HTTPS på den slags sider for at forhindre manipulation af indhold og diverse man-in-the-middle-angreb?

49 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
49
1. maj 2017 kl. 07:54

Man indtaster adressen på den side man vil se historik på, og trykker på knappen "browse history"

48
28. april 2017 kl. 12:17

Nej, Morten. Hvordan gør jeg det?

Men jeg tænker også, at da der er tale om en lille "dialogboks", som fremkommer ovenpå selve forsiden, så er det vel ikke en, som gemmes i gamle versioner af hjemmesiden?

Bortset fra det, så har jeg på nuværende tidspunkt fået tiltro til, at AAK bedre kan finde fejlen end mig - og de benægter heller ikke, at den har været der, så behovet for at dokumentere er lige nu ikke så stort.

47
28. april 2017 kl. 12:11

Anne-Marie: Har du kigget om du kan se den gamle version af deres site?

46
28. april 2017 kl. 11:50

Jeg må for en god ordens skyld fortælle, at den videre (stadigt igangværende) kommunikation med AAK viser, at de nu tager sagen alvorligt, og gør et seriøst stykke arbejde med at finde fejlen - selv om den ikke mere er aktuel. Det skal de roses for.

45
28. april 2017 kl. 07:57

Morten Toudal: Tak for tip - linket er gemt til, hvis behovet skulle opstå en anden gang :-)

44
28. april 2017 kl. 07:56

Kenn Nielsen: Ja - svaret er imødekommende, og lyder for mig også umiddelbart som om, man faktisk gør en del for at sikre systemerne. Jeg kan så undre mig over, om det virkeligt kan lade sig gøre, at en sådan fejl - pludselig spontan overgang til http i stedet for https, og spontant tilbage igen, uden menneskelig indgriben, kan opstå? Det har jeg ikke teknisk indsigt til at vurdere - det lyder bare lidt mærkeligt, synes jeg. Hvis det ikke kan lade sig gøre, så er der jo et eller andet galt i deres sikkerhedsprocedurer, som ikke fanger alle typer fiflen/fejl.

Og har det overhovedet noget med browsertype at gøre, om forbindelsen er http eller https?

Nå, jeg håber, at de faktisk undersøger sagen nærmere, sikkerhedsprocedurer eller ej.

42
27. april 2017 kl. 16:18

Tak for nedslående svar, Kenn.

Kan Datatilsynet ikke kræve logfilerne udleveret? Eller kan der fifles med disse?

Men datatilsynet vil måske selv være glade for at få en undskyldning for ikke at undersøge sagen - det kræver jo arbejde, som de måske ikke har ressourcer til.

41
27. april 2017 kl. 16:11

Og derudover: Jeg håber jo, at Datatilsynet vil tjekke sagen

Jeg er bange for det er derfor du får beskeden: "Vi aner ikke hvad du taler om" - efter fejlen er væk.

Dette giver muligheden for at afvise Datatilsynet 'i døren' med en bemærkning om at "anmelder tog fejl"..

K Edit: Var lige 'borte' en times tid og trykkede >gem< inden jeg opfattede at livet også her går videre uden mig :-)

Høfligt svar, og ikke noget med at skyde budbringeren, - så jeg tog nok (glædeligt) fejl.

40
27. april 2017 kl. 15:19

Tak for tip, Peter Stricker. Jeg forsøgte mig med den metode, men kunne ikke rigtigt få det til at virke - men klippeværktøjet virker. Havde bare glemt det.

I øvrigt opfølgning på AAK - jeg har fået denne mail:"Kære Anne-Marie Krogsbøll Tak for din besked. Jeg påstår ikke, at du ikke har haft den oplevelse med vores side, som du beskriver, hvorfor jeg naturligvis fortsat vil undersøge, hvad årsagen kan have været. Når det er sagt, så har vi ikke rettet på måden hvorpå man logger på vores selvbetjeningsside, siden vi lancerede den torsdag den 3. november 2016. Ved tilføjelse af funktioner eller ændringer i forbindelse med fejl i øvrigt så har vi et hold testere, der gennemløber en lang række testscenarier i de top-8 mest anvendte browsere fordelt på PC, Mac, Android- og Apple-devices. Der er ingen, der er inde og fifle med vores systemer. Det kan vi nemlig se ud fra nær-realtidsanalyse af de fleste af vores logfiler, heriblandt også loggen fra vores webservere. Jeg takker dog for din årvågenhed og at du har gjort os opmærksom på din oplevelse."

Underskrevet digitaliseringschefen, som sådan set jo har svaret venligt, så ingen grund til at sætte hans navn her.

39
27. april 2017 kl. 15:13

PrtSc-tasten virker ikke

Nu kender jeg ikke dit tastaturlayout, men hvis du har en Fn-tast, er det muligt at den skal holdes nede mens du trykker på PrtSc.

37
27. april 2017 kl. 15:07

Tak, Kenn, for at minde mig om klippeværktøjet. Havde glemt det, fordi jeg i et par år har været rigtigt glad for Linux Mint - men Mint er desværre uvenner med min nyindkøbte computer (arbejder på sagen :-( ).

Så fremover skal der ikke forekomme udokumenterede fejlmeldinger fra mig....

36
27. april 2017 kl. 15:07

Det er lidt svært at argumentere

Ja. Kommunikation er ikke altid nemt. :)

Men så er vi vel enige om at det ville være bedst at undgå issuet ved at BrugerID ikke defaulter til CPR-nummer

Helt enig.

men er et frit tilvalg for borgere, der ikke mener at de har noget at skjule eller har noget imod at få lidt mere spænding i tilværelsen.

Jeg synes godt man kan argumenterer, at det ikke skal være en mulighed at tilvælge dårlig sikkerhed. Jeg kan heller ikke fravælge kryptering på en sikret service f.eks. loginside. Men ellers er jeg enig :)

35
27. april 2017 kl. 14:56

Hvad med om infosecurity.dk snart får https? Eller har folkene bag konferencen det fint med at sende log in oplysninger over http?

33
27. april 2017 kl. 14:45

Svagheden ligger i NemID, det relatere sig ikke til identifikatoren.

NemID løsningen indeholder muligheden for at spærre for brugen af CPR-nummer som id. Det er skal slåes til for alle brugere og herefter er det ikke et issue længere.

Det er lidt svært at argumentere i mod dig, når det er svært at vurdere hvad du selv mener, jf. ovenstående 2 successive svar.

Men så er vi vel enige om at det ville være bedst at undgå issuet ved at BrugerID ikke defaulter til CPR-nummer, men er et frit tilvalg for borgere, der ikke mener at de har noget at skjule eller har noget imod at få lidt mere spænding i tilværelsen.

32
27. april 2017 kl. 14:29

Det er dog direkte i strid med loven om persondata

Jo. Det er vist også her det står at CPR numre er hemmelige. Hvorom alting er, så er det både tidskrævende og dyrt at få rodet sig ud af nogens misbrug af CPR-numret.

"man kan efterfølgende gøre krav gyldig." Du mener vel "gøre krav ugyldige" ?

At få ret, betaler hverken brevpapir, frimærker eller fridage. Så uanset CPR-nummerets indbyggede svagheder, så er det en god ide, at holde det så skjult som muligt.

31
27. april 2017 kl. 14:20

Ja, jeg ved det, Kenn Nielsen. Føler mig også dum og naiv, at jeg ikke regnede med den reaktion fra AAK. Men kan du lige, til brug næste gang, oplyse mig om, hvor det er "Print screen"-funktionen ligger i nutidige windows-udgaver? For PrtSc-tasten virker ikke - ellers havde jeg brugt den for en sikkerheds skyld ( men i så fald ville jeg nok have følt mig urimeligt mistænksom samtidigt....).

Og derudover: Jeg håber jo, at Datatilsynet vil tjekke sagen - i så fald går jeg ud fra, at der må findes en log, hvor man kan se, hvad der er foregået? For det er vel for sent at genskabe fejlen fra en eller anden temp-fil fra min egen computer?

30
27. april 2017 kl. 14:15

Jeg kunne jo kigge i html koden og se at formularen sende krypteret.

Brugere skal vænnes til i det mindste at kigge efter hængelåsen, derfor skal der også https på siden hvor CPR indtastes.

29
27. april 2017 kl. 14:11

Grr.... det gør mig endnu mere betænkelig, at man tilsyneladende forsøger at lade som ingenting - eller kan det lade sig gøre, at det er et midlertidigt problem, som kan være forsvundet af sig selv?

Og dérfor er det - generelt - vigtigt at dokumentere fejlen så godt som muligt, inden man fejlmelder.

Så kan man sende dokumentationen - igen - når fejlen genopstår.

Eller man kan selv kigge på den , hvis man bliver i tvivl om hvad man oplevede, når man som fejlmelder bliver udråbt som "amaot"..

K

28
27. april 2017 kl. 14:03

NemID bør anvendes, jeg ville aldrig oplyse f. eks. mit CPR nummer på denne måde, det er en overflødig handling.

Men der er jo ingen meningsfuld garanti for at en NemID-loginboks er reel, så du ville ikke være sikrere ved at indtaste dit CPR-nummer via NemID.

24
27. april 2017 kl. 13:50

Svagheden ligger i NemID, det relatere sig ikke til identifikatoren

Jo, det relaterer sig også til identifikatoren. Der vil uanset diverse opfordringer til brugere om ikke at genbruge adgangskoder på tværs af logins være en kraftig statistisk kobling mellem brugerid og adgangskode ("noget kun brugeren ved"). Og den sammenhæng kan udnyttes ved såvel phishing som via hackede sider.

Denne (bruger-forskyldte) svaghed er en af årsagerne til at man til kritiske anvendelser ofte må kræve 2-faktor autentifikation for at opnå en passende sikkerhed. Og her er den viden man i praksis særdeles let kan tilrane sig via CPR-nummer en væsentlig hjælp til at skaffe sig adgang til f.eks. "noget kun brugeren har". (Udover den svaghed NemID har ved at engangs-kodekortet ikke sikrer mod realtime phishing).

22
27. april 2017 kl. 13:29

Det ville jeg være slemt ærgerlig over. Men så anvendes CPR nummeret også til andet end identifikation.

Tak for svar, Claus. Jamen, du kan da have ret i, at hvis ingen misbrugte cpr, så var der intet problem - men problemet er jo, at det forekommer, og derfor må man jo være meget på vagt overfor steder, som sløser med ens følsomme oplysninger - og så længe cpr kan misbruges på den måde - og bliver misbrugt på den måde - så bliver man vel nødt til at regne det for stærkt følsomt? Så kan man altid på længere sigt arbejde mod at begrænse skaderne på den måde, du foreslår.

21
27. april 2017 kl. 13:23

Jeg forstår det ikke rigtigt - vil du ikke have noget imod, at nogen ved fremvisning af dit cpr-nummer tager lån i dit navn?</p>
<p>Eller hvis nogen ringer til din hospitalsafdeling, og får følsomme prøvesvar ved at opgive dit cpr-nummer?

Det ville jeg være slemt ærgerlig over. Men så anvendes CPR nummeret også til andet end identifikation.

Ideelt set, så udgives samtlige kongerigets CPR numre i en stor publikation til offentligheden. Så holder anvendelsen af CPR nummeret som autentifikation hurtigt op.

16
27. april 2017 kl. 12:54

Uden at skulle være på tværs, så er CPR nummeret udelukkende til identifikation og ikke til autentifikation. I teorien, er det lige så ligegyldig information, som et kontonummer i en bank.

Principielt korrekt, men så alligevel ikke.

For enhver kan nu lave en tjeneste, der beder om CPR-nummer som brugernavn suppleret af en adgangskode, som gerne må være en 4 cifret pinkode. Og nu er chancen stor for at en del brugere af mnemo-tekniske årsager vil anvende samme adgangs/pin kode som til NemID. Og med CPR-nummeret har du bl.a. brugerens adresse, så du (relativt) let kan skaffe dig kodekortet eller hardwarenøglen.

For at kunne klassificere en autentifikationsløsning som reel 2-faktor, må der ikke være sådanne koblinger mellem faktorerne, som CPR-nummeret altså udgør.

Derudover er CPR-nummeret det ideelle "correlation handle" for virksomheder, der går sammen om at profilere en bruger, der jf. persondatalovgivningen har afleveret forskellige subsæt af sine oplysninger til forskellige parter. Derfor anvender alle moderne systemer såkaldt "directed" eller "pairwise" identifikatorer, som kun kan sammenkobles ved brugerens egen mellemkomst eller evt. via en central autoritet.

15
27. april 2017 kl. 11:55

Jeg kan fortælle, at jeg netop er blevet kontaktet af AAK (som der var tale om - da sagen nu er ordnet, er det vel OK at fortælle). Her spiller man uforstående overfor, at der skulle være et problem. Og da problemet jo altså blev løst i morges mellem 7 og 9, er det jo svært at fremvise nu.

Grr.... det gør mig endnu mere betænkelig, at man tilsyneladende forsøger at lade som ingenting - eller kan det lade sig gøre, at det er et midlertidigt problem, som kan være forsvundet af sig selv?

14
27. april 2017 kl. 11:48

Uden at skulle være på tværs, så er CPR nummeret udelukkende til identifikation og ikke til autentifikation. I teorien, er det lige så ligegyldig information, som et kontonummer i en bank.

13
27. april 2017 kl. 11:47

NemID bør anvendes

Det er helt irrelevant for den her omtalte sag om det indlagte "sikrede" login er NemID eller almindelig brugernavn og password. For uanset hvilken løsning, det er, har hverken patienten eller lægen nogen sikring mod man in the middle angreb, hvis ikke forbindelsen til alle dele af siden sendes krypteret.

At lave en negering af "hængelås i browseren er ikke nok til at sikre brugeren" til "manglende hængelås i browseren er nok til at sikre brugeren" bringer Datatilsynet i liga med Erasmus Montanus's "En sten kan ikke flyve. Morlille kan ikke flyve. Ergo er morlille en sten!"

På den anden side, når virksomheder som NETS ikke forstår sig på basal browser-sikkerhed, hvordan kan man så forvente at en institution som Datatilsynet skal gøre det?

12
27. april 2017 kl. 11:42

Oplevede fornyligt i forbindelse med selvbetjening på et website fra et kommunalt ejet selvskab, at formularer hvor brugeren blev bedt om at udfylde CPR-nummer m.m. hverken benyttede HTTPS på selve siden hvor formulareren var placeret, eller for den sags skyld submittede formularen via HTTPS.

Kontaktede ejer af websitet via deres Facebook siden nogle dage før påske, de læste beskeden (tak for det Facebook), men har aldrig svaret. Efter påske valgte jeg at kontakte deres webmaster direkte på email. Autoreply med info at webmaster var på ferie i nogle uger....

Endte med at kontakte myndigheden der ejer det pågældende selvskab direkte, da jeg har en kontakt i deres IT-afdeling. Min kontakt har så sørget for at viderebringe problemet og de har nu fået styr på det.

Har siden fundet ud af, at det pågældende website er relanceret inden for det sidste halve år, og det gør mig endnu mere skuffet og irriteret, når man i 2016/2017 ikke tager sikkerheden seriøst.

11
27. april 2017 kl. 11:17

Det er bestemt også ønskeligt. Læger og speciallæger er dog små private virksomheder og de vil ikke betale for den tilslutning til NETS ligesom rigtig mange andre brancher heller ikke vil.

Klinikker der anvender Cure4You, kan man via Cure4You som borger, oprette et såkaldt premium medlemskab, der bl.a. låser op for brugen af NemID. Hagen ved dette er at udgiften flyttes over på borgeren, der selv skal betale. Jeg mener pt. beløbet ligger på 200,-/år.

10
27. april 2017 kl. 11:09

Enig, Jan Juul Mortensen. Men det er vel stadig relevant at tjekke "Egenskaber", selv om man ønsker at vælge NemID?

9
27. april 2017 kl. 11:09

Datatilsynet har helt sikkert juridisk ret i at siden overholder loven.

Men hvilken grad af sikkerhed vil man helst have 20% sikkerhed for at forbindelsen ikke er kompromitteret (min anslåelse af den beskrevet løsning) eller 70% sikkerheds for at forbindelsen ikke er kompromitteret (min anslåelse af en HTTPS løsning)

8
27. april 2017 kl. 10:54

NemID bør anvendes, jeg ville aldrig oplyse f. eks. mit CPR nummer på denne måde, det er en overflødig handling.

7
27. april 2017 kl. 09:24

Alle steder hvor der kan udveksles følsom information skal selvfølgelig være certificeret/krypteret fra start til slut.

Kun derved kan man være sikker på at udbyderen af servicen har gjort sit yderste for at beskytte informationen.

Hvis ikke man har en eller anden form for verificérbar dokumentation for at dén service man besøger, vitterlig stammer fra dén udbyder den påstår, så kan man principielt ikke stole på siden overhovedet, heller ikke indlejrede scripts, links mm.

Næste lag er om man stoler på valideringen af certifikatet, men det er en anden snak...

5
27. april 2017 kl. 09:11

Hr. og Fru. hansen udgør trods størstedelen af internetbrugerne og hvis hængelåsen ingen garanti er, vil de måske være mere skeptiske hvis den ikke er der end omvendt.

Trist, men problemet kan løses ved simple omskrivning af Nike's slogan:: Just DON'T do it! :)

4
27. april 2017 kl. 09:01

Søren Mors:

Tak for svar. Jeg skal prøve at forklare: På forsiden (som har hængelås og angives som "sikker forbindelse" i "Egenskaber") er et menu-punkt, som hedder "Log på". Når man klikker på dette, fremkommer en login-boks, hvor man kan vælge imellem at bruge cpr og password (det er det tydelige førstevalg). Der er links til NemID, hvis man hellere vil det.

Ved højreklik på selve denne login-boks får man så som vanligt adgang til "Egenskaber". Af denne fremgår så klart og tydeligt, at forbindelsen er "ukrypteret" - men i en "sikker zone" (sidstnævnte er vel min egen indstilling i browseren?). Jeg tolker dette som at loginboksens oplysninger sendes via ikke-krypteret forbindelse, for det er vel det, der står?

Selve certifikatet ser for mit utrænede øje ud til at tilhøre rette ejer.

Men som krølle på historien kan jeg så oplyse, at da jeg tjekkede for 5 minutter siden (en time efter, at jeg adviserede stedet om, at jeg havde anmeldt til Datatilsynet), var "Egenskaber" pludseligt ændrede, så det nu fremgår, at loginboksen sendes via "TLS 1.2, AES med 256 bit kryptering (høj); ECDH_P256 med 256 bit udveksling".

Mon ikke det er en halv indrømmelse? :-) Men det vigtigste er, at sagen nu er i orden.

Jeg anmeldte, fordi en sådan sag jo kunne betyde, at stedet heller ikke har styr på sin øvrige behandling af meget følsomme personoplysninger (herunder mine), som de ikke kan undgå at ligge inde med. Det håber jeg, at Datatilsynet vil tjekke op på.

3
27. april 2017 kl. 08:05

Hvad mener du helt præcist med at du har konstateret at login formularen ikke er krypteret? Hvis den bor i sin egen iFrame som hentes over en usikker forbindelse er der et problem. Hvis den adresse den sender svar tilbage til er på en usikker forbindelse er der et problem. Men hvis den bare er en del af siden, og siden hentes over en sikker forbindelse, så er alt godt.

2
27. april 2017 kl. 07:51

Jeg har netop konstateret, at en hjemmeside, som har tusindvis af medlemmer (røber ikke hvilken), godt nok har hængelås, men samtidig fra samme side (forsiden) benytter en ikke-krypteret login-formular (konstateret via "Egenskaber"), hvor man beder om cpr og password.

Det er vel om muligt endnu værre - for folk ser hængelåsen, og går ud fra, at formularen så er sikker. Eller er det mig, der tager fejl? Behøver selve formularen ikke være angivet som krypteret/sikker, hvis den ligger på en sikker side?

Jeg har meldt det til den pågældende institution - men undrer mig over, at der aldrig bliver ende på den slags - hvor har de ansvarlige IT-folk i foretagendet haft deres hjerne de sidste mange år? (med mindre det er mig, der tager fejl, og formularen faktisk er sikker, selv om den ikke ser sådan ud. Men i så fald er det noget rod).

1
27. april 2017 kl. 07:35

Det er muligt at datatilsynet har ret i at data er tilstrækkeligt beskyttet, i for hold til lovens krav, hvis de sendes retur over https. Men Dan Storm har da også indlysende ret i at det ikke beskytter imod et man-in-the-middle angreb.

Og helt ærligt, hvordan kan man have tillid til udviklerne af systemet hvis de ikke engang formår at sætte https på hele siden. Det er enten dovenskab eller inkompetence. Svært er det altså ikke mere.