Kan du fortælle mig mit kodeord?

Jeg har på det seneste et par gange på Twitter (og dermed også Facebook) brokket mig lidt over login systemer på det seneste. Noget tyder i hvert fald på, at det der burde være en rimelig og ansvarlig politik og “best practice” politik, overhovedet ikke følges – selv når der er tale om nye (og prestigefyldte) websites.

Note: Det følgende er skrevet i håbet om at være nogenlunde forståeligt af alle, og der er derfor bevidst lavet nogle simplifikationer og udeladt detaljer – f.eks. omkring “salt” af hash algoritmer. Jeg håber trods dette, at den har værdi og giver mening.

Der er 2 åbenlyse faresignaler, man bør være opmærksom på, hvis man har med online login-systemer at gøre:

  1. Man bør aldrig nogensinde blive tvunget til at have en maksimal længde på passwords (i hvert fald ikke på under 40-50 tegn).
  2. Et website bør aldrig nogensinde kunne gensende dig dit password via en “glemt kodeord” funktion.

Ad 1) I “gamle dage” da man lavede de første websites med logins, der skulle det sikkert bare gå stærkt, og sikkerhed var typisk noget, der blev kigget på “når man fik tid”. Derfor var der mange sites, som startede med en tabel i en database, der ret beset bestod af et felt til brugernavn og et til passwordet – matchede de to med det, som brugeren tastede ind, blev han godkendt.

Udover det åbenlyst uheldige i at enhver udvikler, webmaster og andre med adgang til denne database, uden videre vil kunne udgive sig for at være brugeren, så er der også det problem, at hvis man har “indbrud” på serveren (populært sagt, at den bliver “hacket”), så vil de ubudne gæster også kunne skaffe sig en kopi af samtlige brugernavne og tilhørende passwords. Det skete f.eks. for Yahoo! i sommers, hvor over 450.000 brugernavne og kodeord (i klar tekst) blev kopieret af folk, der havde fundet en sikkerhedsbrist i et af deres sites.

Når man har brug for kunne genkende en bruger, så er det ikke brugerens password, man har brug for at gemme – det er en sikkerhed for at brugeren har tastet det rigtige password, og her kan matematikken hjælpe.

Der findes nemlig såkaldte “hash funktioner“, som er en slags en-vejs kryptering. Man giver et kodeord til en hash funktion, og den returnerer altid det samme samme. Svaret har altid samme længde, og der bør ikke findes nogen mulig måde, at komme fra svaret, der er kommet ud af Hash funktionen tilbage til det oprinelige kodeord.

Laver man login systemer i dag, så er det resultatet af hash funktionen man gemmer, ikke brugerens kodeord. Med hash funktionen(*) kan ingen ud fra den gemte tekst som udgangspunkt se brugerens kodeord (og dermed misbruge det), men vi kan stadigt være helt sikre på, at brugeren kender kodeordet, der hører til brugerens konto.

Ad 2) Hvis websitet er i stand til at sende eller på anden måde udlevere dit kodeord, så forudsætter denne handling, at det er gemt i klar-tekst (eller i det mindste på en sådan måde, at det kan bruges tilbage til klar-tekst).

Givet mange har for vane, at genbruge samme brugernavn og kodeord igen og igen på tværs af mange sites – twitter, facebook og mange, mange andre steder, så er det, at ens brugernavn og kodeord ligger i klar-tekst på et tilfældigt site, ikke kun et problem for det ene site, hvis de som Yahoo! har digitalt indbrud og fremmede får en kopi af brugerkonti.

Websites, der har lavet sikkerheden rigtigt, har typisk også en “glemt kodeord” procedure. Den fungerer typisk ved at man enten får udstedt et nyt midlertidigt kodeord og får dette via mail, telefon eller lignende (og ofte tvinges til at skifte dette ved første brug, så ingen efterfølgende har mulighed for at kende dit personlige kodeord) – eller også sender de et link med en lang kode i, som giver adgang til at lave et nyt kodeord.

Lidt om hash funktioner

Der findes mange forkellige hash funktioner. Nogle af de mest kendte er CRC32, MD5 og SHA1. Funktionerne bruges ikke kun i forbindelse med passwords, men også i forbindelse med “checksummer”, så man f.eks. kan lave en “hash” af to tekster, og hvis den bliver ens, så er teksterne antageligvis ens.

En hash kvalitet måles ud fra flere forskellige parametre, blandt andet hvor tung den er at lave for serveren, hvor tilfældigt resultatet er i forhold til hvad man giver den af input (om det er muligt at se mønstre i det, der kommer ud) og hvor lang den hash (resultat), der resulterer i.

Spam på fisketur

Ens digitale mailboks syntes at være under et konstant og vedvarende angreb af folk. I “gamle dage” (hvilket normalt betyder for få år siden), var målet primært at sende reklamer for viagra og alt muligt andet skummelt snavs.

Det næste skridt på bølgen af digitalt affald var mails, som forsøgte at få alt muilgt malware, virus og andet snavs ind på maskinen, og hvor anti-virus, anti-malware og lignende programmer i den grad har fået deres sag for.

Den trejde bølge af digitalt affald, som de fleste efterhånden oplever, er såkaldte phising mails. Vi mangler endnu et godt dansk navn for denne type mails, men genren er efterhånden veldefineret kaldes “phising mails” og formålet er – udover fortsat at snige skumle programmer ind på din pc – også at lokke oplysninger ud af dig – typisk logins, bankoplysninger eller lignende.

En af de seneste phising mails, som havnede i min mailboks så således ud:

Spot en phishing mail…

Denne mail indeholder heldigvis flere af de klassiske tegn på en phising mail:

  • Henvendelser fra Skat starter sjældent med teksten “Kære skatteyder,”.
  • Sætningen “Jeg sender denne e-mail for at annoncere:” er – selv for kancellisprog – dårligt dansk – og det dårlige sprog går igen flere steder i mailen.
  • Når beløb angives på dansk, benytter vi sjældent valuta koden “DKK” (selvom den er “teknisk korrekt”), men blot kr. eller kroner.
  • På dansk benytter vi punktum som tusind-seperator, og kommer til øreangivelse – ikke omvendt, som tilfældet er i mailen.
  • Hvis man kører musen henover “Klik her”, så går linket ikke til skat.dk – men et fremmed domæne – i forsøget på at snyde modtageren, så har afsenderen lavet et site med en addresse, der heder – nogetskummelt.com/skat.dk/ i forhåbning om at man bare ser, at der står skat.dk i mailen.

Hvis det er en phising mail…

Når du modtager en phising mail, så smid den ud med det samme. Lad være med at hente billeder, lad være med at klikke på links og lad være med at besvare den.

Ved at hente billederne, er du som oftest med til at bekræfte, at mailen er kommet frem til en modtager – og selvom denne mail måske ikke fik dig i fælden, så kan de jo altid prøve igen.

Det samme gælder, hvis man besvarer mailen. I bedste fald, så er det en falsk afsender, men i værste fald, er du med til at bekræfte, at din mailaddresse findes og det er værd at forsøge at sende spam, malware og phising mails til dig, i håbet om at få dig i fælden på et tidspunkt.

Ved at klikke på links, så risikerer du at komme ind på sider, der forsøger at installere malware, vira eller anden ondskab på din maskine.

Hvis du er i tvivl…

Hvis du er i tvivl om en mail du har modtaget er phising eller ej, så er et par tips, der kan hjælpe med at afklare det i en fart:

  • Hvis mailen indeholder stave- eller grammatikfejl, så den ikke lyder dansk, så er det tegn på phising.
  • Det er ofte phising, hvis budskabet i mailen ikke er logisk for eksempel:
    at du har vundet noget i en konkurrence, du ikke har deltaget i.
    at dit mobiltelefonni-selskab gerne vil give dig en gratis iPhone, men ikke  kender dit navn og addrese.
    at en rejse jorden rundt udbydes til en urealistisk billig pris.
  • Hvis mailen ikke er udsendt af/fra virksomhedens domæne (- mails fra DSB, bør altid komme fra en @dsb.dk adresse), så er det ofte phising.

Hvis du stadigt er i tvivl, så så åben selv en browser, gå ind på virksomhedens website og søg oplysninger via websitet, fremfor at klikke på links i mails.

Hvem er typisk “misbrugs ofre”

Når du modtager phising mails, så er det typisk følgende virksomheder, der forsøges misbrugt:

  • Teleselskaber, herunder specielt mobil-selskaber: Typisk er formålet at kunne skaffe sig adgang til at kunne sende overtakserede SMS’er, lave dyre opkald til numre i udlandet eller lignende.
  • Banker: Formålet er typisk at lave røveri mod netbanker, og overføre dit indestående til konti i udlandet, hvor pengene ret bekvemt kan forsvinde sporløst.
  • Andre finansielle virkesomheder: Paypal og lignende – motivet er det samme som for hvad angår banker, men qua paypal opererer internationalt, så er der også mange flere potentielle ofre.
  • Det offentlige: Alle har en relation til offentlige myndigheder, og det virker derfor mere plausibelt, at der kommer en mail til en fra en offentlig myndighed.

Du kan i øvrigt finde meget mere om phishing problemet – og flere gode råd på Mit TDC’s sikkerhedssite.

Sikkerhed og Java

Vi bruger efterhånden Internet (og IT-systemer generelt) til rigtigt mange kritiske ting, og som følge heraf syntes det også at blive stadigt mere attraktivt at finde sikkerhedshuller og udnytte disse.

Det seneste store hul, der blev fundet, var i Java (7), og det var et gumt sikkerhedshul, der endda virkede på tværs af Windows, Mac og Linux (såfrem man kørte med nyeste version af Java). Det er et såkaldt “Zero day” hul – det vil sige, at det er opdaget ved at nogle udnyttede det. Computerworld beretter dog, at det rygtes, at Oracle (der leverer Java) kendte til hullet månedsvis uden dog at levere en opdatering, der lukkede det.

Generelt har anbefalingen i de internationale medier været, at man blot burde afinstallere og fjerne Java, hvis man ikke havde brug for det. En af årsagerne til denne anbefaling var blandt andet at de værktøjer, som findes til at (nemt) udnytte sikkerhedshuller, allerede var blevet opdateret, så de også kunnne misbruge dette seneste hul. Der var med andre ord god grund til at tro, at mange ville blive ramt af digitale angreb, som en direkte følge af Java problemet.

Det er måske meget fint, for alle uden for Danmark, men desværre har vores alle sammens NemID, der bruges til NetBanker, e-Boks, den offentlige digitale verden og andre steder, valgt at bygge hele deres løsning på Java, og deres anbefalinger omkring sikkerhedsissues tangerer det tragi-komiske.

Hullet har været kendt en uges tid, og frem til i dag, har der været radiodødt fra Oracle’s side. Det er sjældent et godt tegn, da det typisk betyder, at Oracle holder fast i deres plan om kun at opdatere Java 3 gange om året. Næste planlagte opdatering var først den 16. oktober. Der har heldigvis været tilstrækkelig kritik og mediestorm omkring emnet, at Oracle i dag har frigivet en opdatering, der lukker hullet. Tak.

Misforstået sikkerhed

Man bliver helt træt, når man læser, de fjollerier, som nogle sikkerhedschefer i danske pengeinstitutter finder på at melde ud, og man får næsten trang til at sende dem en t-shirt (Nykredit blå naturligvis), som belønning for dages citat på ComOn.dk.

Udtalelsen, der giver basis for præmien er følgende:

“Dybest set giver det ikke mere sikkerhed at anvende specialtegn. …” siger sikkerhedschef Niels O. Rasmussen hos Nykredit. (comon.dk)

Et kodeord med med bogstaver og tal har en væsenligt ringere entropi end et med specialtegn, og derfor vil det dybest set være væsenligt mere sikkert. Han anfører i øvrigt også, at muligheden for at kunne bruge special tegn er med til at sikre, at folk ikke skriver passwordet ned, og at der spærres for kontoen efter 3 forkerte forsøg.

Givet de IT-brugere jeg ofte færdes omkring, så er jeg ret sikker på, at en adgang, som vil medføre væsentlige gener, hvis den blev spærret efter 3 forsøg, er helt sikkert skrevet ned 3-4 steder – bare for at være sikker på, at man ikke får spærret adgangen. Naturligvis er Nykredits kunder på det punkt sikkert helt anderledes.

Hvis Nykredit (og andre) tillader en vilkårlig længde password, så behøver man i øvrigt ikke specialtegnene for at gøre det sikkert. Man kan også gennem dem i en password høstak. Hvis du ikke har mod på at følge linket (eller se en video om hvad det er), så går det blot ud på at man sætter en stribe tegn foran (og/eller efter sit password), og på den måde kan gøre sit kodeord væsenligt mere sikkert.

Bank, NetBank og it-sikkerhed

Jeg har et problem med “min bank”. Den udviser en adfærd, hvor man nærmest kan have dem mistænkt for bevidst at sjuske i en sådan grad, at det er med til at give brugerne en stribe dårlige vaner, når det gælder forsvarlig adfærd på nettet.

“Banken” har godt haft en lidt omskiftelig tilværelse over de seneste par år, men faktisk syntes jeg ikke – når penge er en forretningsområde – er nogen undskyldning, det gør det kun værere. Jeg startede i Skandiabanken. Den blev siden til Eik bank, der endte i det offentlige “bank skraldespandsselskab” og landede siden hen hos Spar Lolland – omend vidst som en søster bank med navnet FinansNetBanken indtil videre.

Det har i nogen tid været lidt et rod. Selvom de hedder Finansnetbanken, så er deres website på finansbanken.dk (finansnetbanken.dk redirecter i det mindste til deres valgte hoveddomæne). I e-Boks er det Spar Lolland, der er afsender på breve fra Finansbanken. Deres Netbank ligger så ikke på finansbanken.dk, men er i stedet på portalbank.dk domænet (Sikkert sammen med SDC‘s øvrige netbanker – og som i øvrigt giver en fejlside hvis den ikke “deep linkes” –  endnu et minus point i min bog).

For så at forøge forvirringen yderligere, så er det naturligvis hverken SDC, Spar Lolland eller Finansbanken, som har købt certifikatet, der bruges nået man krypterer trafikken til netbanken, det kommer nemlig fra IBM Danmark ApS…

Det er da helt utroligt, at en bank vil have så mange “identiteter” – det er jo nærmest at opfordre til at gøre dens kunder til phishing ofre, for hvordan kan jeg vide, om en mail, der angiveligt linker til bankens nyhedsbrev på banknyhedsbrev.cn rent faktisk har dem som afsender eller ej? – deres nyværende domæne- og kommunikationsstrategi er i hvert fald ingen hjælp.

ps. SSL-certifikatet på sparlolland.dk er i øvrigt også udstedt til IBM Danmark ApS, så måske har IBM Danmark overtaget banken og blot ikke fortalt om det?