Ville Google bede om de første tre tegn i dit kodeord?
Det er svært at forestille sig, at Google, Facebook og lignende ville håndtere brugernes sikkerhed på samme måde som et teleselskab i Danmark.
I hvert fald har Version2 alene i indeværende uge kunnet fortælle historier om, hvordan flere danske teleselskaber griber it-sikkerhed an.
Ugen blev skudt i gang med historien om teleselskabet 3, der åbenbart har mistet data for ca. 3.600 kunder. Hvordan det er foregået, vides ikke. Det er ikke mere end tre måneder siden, at 3 i England kunne meddelelse, at kriminelle havde fået fat i 133.827 kunders data. Ingen af delene siger nødvendigvis noget om det generelle sikkerhedsniveau hos 3. Alt og alle kan som bekendt hackes med tilstrækkelige ressourcer.
Alligevel er der noget, der springer i øjnene i forhold til historien om 3. For samtidigt med, at teleselskabets kundedirektør i forhold til lækket bedyrede, at »vi har sikkerhed som en meget meget høj prioritet,« så kunne kunder se en sikkerhedsrelateret fejl ved et besøg på login-siden til 3's selvbetjeningsløsning.
En fejl der fik Googles Chrome-browser til at advare om, at forbindelsen ikke var helt sikker.
3 var blevet opmærksom på fejlen via en kundehenvendelse henover weekenden og problemet var løst tirsdag. Ifølge 3 har fejlen ikke noget med datalækket at gøre.
Men det kan i den forbindelse undre, at 3 ikke tidligere af egen drift har gjort noget ved det umiddelbart simple problem, der har bevirket, at der på den pågældende side er blevet vist en advarsel om, at angribere kan narre brugerne ved at manipulere billeder, i stedet for en grøn hængelås. Og her taler vi vel at mærke login-siden, der giver adgang til kundernes data.
En anden telehistorie fra denne uge er fortællingen om det TDC-ejede Telmore, hvor det åbenbart er almindelig praksis at bede brugerne udlevere de første tre tegn af deres kodeord via mail i support-øjemed. På den måde bliver de første tre tegn af brugernes kodeord kendte af Telmores support-medarbejdere, når og hvis brugerne sender en mail med tegnene.
Mens Telmore gav udtryk for, at virksomhedens omgang med kodeord var forsvarlig, så gav Version2-blogger og it-sikkerhedsmand Poul-Henning Kamp udtryk for, at det var det ikke. Det samme gjorde flere Version2-læsere i den efterfølgende debat. Debatten indeholdt desuden flere eksempler på teleselskaber, der efter sigende har håndteret brugernes kodeord på en måde, som ligger langt fra det, de fleste nok forstår ved 'best practice'.
Det er i den forbindelse værd at holde sig for øje, at de danske teleselskaber ligger inde med potentielt særdeles følsomme oplysninger, blandt andet om vores færden i det fysiske rum.
Google, Facebook og co.
Google og Facebook ligger også inde med følsomme oplysninger om os. Mens disse virksomheder nok ikke ligefrem kan beskyldes for at stirre sig blinde på den danske persondatalovgivning, når det kommer til at indsamle og sammenkøre personoplysninger, så er der anderledes grund til at tro, at de bemeldte virksomheder tager grundlæggende it-sikkerhedsprincipper seriøst.
Det er således svært at forestille sig, at Google opbevarer kodeord på en måde, så support-medarbejdere kan autentificere brugere via de første tre tegn i kodeordet. Facebook ville nok næppe heller lade en https-advarsel i Chrome om, at forbindelsen til facebook.com ikke var 'helt sikker' gå upåagtet hen i dagevis - derudover ville HTML-koden hos Facebook nok ikke være skruet sådan sammen, at advarslen opstod i første omgang.
Facebook og Googles sikkerhedsfokus er i høj grad drevet af frygten for et katastrofalt brud på datasikkerheden. Det kan i sidste ende betyde, at de datadrevne forretninger går nedenom og hjem.
En ting er, hvis en enkelt bruger med et dårligt kodeord og manglende to-faktor-autentifikation får kompromitteret en mailkonto, anderledes vanskeligt vil det være at genopbygge aktionærernes tillid til virksomheden, hvis millioner af brugeres Gmails eller Facebook-beskeder pludseligt flød rundt på nettet som følge af en kompromittering af de bagvedliggende systemer.
At Google tager deres sikkerhed alvorligt vidner virksomhedens Project Zero om. Det er kort fortalt en flok dygtige sikkerhedsfolk, der hacker løs på Googles egne og andre virksomheders systemer. Når de så finder it-sikkerhedshuller, rapporterer Project Zero-folkene det til den pågældende virksomhed, der så har 90 dage til at lukke hullet, før det bliver offentliggjort. Det kan gå hurtigere, hvis hullet bliver aktivt udnyttet
Siden Project Zero blev startet i 2014, så har holdets skiftende medlemmer fået lukningen af en del spektakulære sikkerhedshuller på samvittigheden. Projektets blog er således saftig, og til tider særdeles teknisk, læsning for sikkerheds-interesserede. Eksempelvis var det i Project Zero-regi, at den avancerede, RAM-manipulerende RowHammer-sårbarhed blev opdaget.
Det er nok (desværre) usandsynligt, men hvis nu Google-folkene af en eller anden grund skulle begynde at udvise interesse for store danske virksomheder, der ligger inde med følsomme data om os alle sammen, så kunne noget tyde på, at der ville blive nok at se til.
En anekdote
Jeg mødte engang en it-sikkerhedsmand, hans navn og tilhørsforhold fortaber sig i glemslen, men han sagde noget i retning af:
»I know people who work with the security at Google. Those guys run a pretty tight ship.«
Jeg tror, han har ret. I hvert fald relativt set.
Hvad det relative angår, så er det underligt at sidde tilbage med en oplevelse af, at mine oplysninger - alt andet lige - ligger bedre sikrede hos en amerikansk, data-kapitaliserende mastodont, end hos et teleselskab i Danmark.

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