CBB Mobil: Send de første tre tegn af dit kodeord

Illustration: Screendump / CBB Mobil
Hos teleselskabet CBB Mobil bliver kunderne bedt om at oplyse de første tre tegn af deres kodeord i forbindelse med kundeservice. Det kan svække it-sikkerheden, men er ikke unormalt i branchen.

Når du kontakter mobilselskabet CBB Mobil for at diskutere følsomme oplysninger, som eksempelvis forbrug eller betaling, bliver du bedt om at udlevere de tre første tegn i dit kundekodeord. Det bruger kundeservice til at sikre sig, at du er den bruger, du udgiver dig for.

Selskabet understreger, at kodeordene ikke ligger i klartekst, men ifølge ensikkerhedsekspert er en praksis med at udlevere de tre tegn ikke sikker.

Praksis forringer it-sikkerheden

Det forringer et kodeords sikkerhed betragteligt, at dele af det er kendt. I særligt grelle eksempler, som 'Pas', 'qwe' eller '123' for et ottecifret kodeord, vil det være muligt at gætte kodeordet uden hjælpemidler. Selv for mere sofistikerede kodeord sænkes kodeordets styrke betydeligt, for hvert tegn man ikke behøver at knække.

Sikkerhedsrådgiver Jakob Heidelberg, der har stiftet sikkerhedsfirmaet Improsec og bl.a. har specialiseret sig i at bryde adgangskoder, er skeptisk ved, at man udveksler dele af kodeordet med kundeservice og opdeler koden i de bagvedliggende systemer.

»Jeg kan ikke udtale mig om den konkrete systemarkitektur, som muligvis er udmærket skruet sammen, men generelt er det dårlig praksis at udlevere og teste på dele af kodeord, også selvom man ikke opbevarer dem i klartekst,« siger han.

Læs også: Telia skrotter kodeord i klartekst efter syv år: »Det kan lyde vanvittigt i dag«

Selvom kodeordene ikke ligger i klartekst, så mener Jakob Heildelberg, det er dårlig it-sikkerhed, at dele af et kodeord bliver udvekslet på mail eller chat. Dermed kan delen komme i hænderne på andre ved et evt. læk fra mobilselskabet.

Desuden sidder en medarbejder ved teleselskabet med starten på et kodeord, som måske bruges i andre tjenester.

Besked fra CBB Mobils kundeservice i forbindelse med en supportsag. Supportsager kan køre over mail, chat og telefonopkald. Illustration: Screendump / CBB Mobil

Udbredt praksis

Samme praksis har været fulgt af Telmore, hvilket Version2 rapporterede sidste år. Det er stadig tilfældet - man skal bruge dele af kodeordet til at identificere sig overfor kundeservice, oplyser Nis Peder Kolby, pressetalsmand for TDC, der ejer Telmore.

»Kunderne får at vide, at de bør lave stærke kodeord indeholdende både tegn og tal, og at kodeordet skal være på minimum otte karakterer. Dette kræver vores system også ved oprettelse,« siger pressetalsmanden.

Læs også: Telmore om kodeord: »De tre første tegn ligger ikke længere i klartekst«

Både TDC og CBB Mobil mener, at sikkerhedsniveauet i deres praksis er tilstrækkelig. De hæfter sig ved, at det er en gennemprøvet procedure, som ikke giver medarbejdere indblik i hele kundens kodeord.

»Når vi beder om de tre første tegn, er det ikke, fordi medarbejderen kan se kundens kodeord og blot validerer. De tre tegn tastes ind i vores kundeservicesystem, hvor systemet validerer, om de tre tegn matcher med de tre første tegn i kundens kode. Medarbejderen får en tilbagemelding om, hvorvidt det er korrekt eller ikke korrekt, men kan altså ikke se koden,« skriver Stine Olsen, som er teamchef ved CBB Mobil.

CBB kan også oplyse, at kundernes kodeord ikke ligger i klartekst, og at medarbejderne ikke får hele kodeordet oplyst. Version2 kunne i 2017 rapportere, at dette havde været praksis for Telia Bredbånd i en længere årrække.

»De 3 første bogstaver og hele kodeordet opbevares hver for sig. Der er intet, som ligger i klartekst, de er begge hashede hver for sig,hvor vi anvender en kryptografisk hashfunktion (BCrypt). Når kundeservicemedarbejderen får de tre første bogstaver oplyst af kunden, tastes disse ind i systemet for verifikation,« uddyber Stine Olsen over en Facebook-chat.

Bruteforce

BCrypt er i følge Jakob Heidelberg en effektiv hash-metode, som anvendes i mange tilfælde, hvor høj sikkerhed er påkrævet. Han påpeger dog, at opdelte eller korte kodeord stadigvæk er en sikkerhedsrisiko.

»Set i forhold til det samlede kodeord forkortes den tid, det tager at bruteforce de to dele individuelt, drastisk. Kodeordet bliver ekstremt meget lettere at knække, det øjeblik man opdeler det i to dele,« siger han.

For at påvise, hvor vanskeligt et BCrypt bruteforce-angreb er, har Jakob Heidelberg opstillet et forsøg på en maskine med tre moderne grafikkort (GeForce GTX 1080) og password cracking-værktøjet 'Hashcat'.

Programmet melder, at bruteforce af otte tegn (alfanumerisk = store/små/specialtegn), vil tage indtil »Next Big Bang (> 10 years)«.

Dermed må det i praksis regnes for upraktisk eller umuligt med nuværende teknologi og metoder. Hvis man kan opdele crackingen i to, tager tre tegn kun ca. 30 sekunder og fem tegn kun ca. 100 timer. Det viser fint, hvor ekstremt meget nemmere det er at bruteforce et kodeord, der er opdelt.

Samme praksis i udlandet

Brugen af de første cifre af et kodeord er tilsyneladende en udbredt praksis i teleselskabers kundeservice. Version2 dækkede for et år siden et lignende eksempel fra Telmore.

Forrige uge kunne også Motherboard dokumentere, at tilsvarende praksis blev brugt af østrigske T-Mobile.

Det fik stor bevågenhed, efter en talsperson for T-Mobile Austria over Twitter forsøgte at forsikre kunderne om, at sikkerheden er i orden.

En bruger påpegede, at praksis med at bruge starten af kodeord i klartekst er udtryk for mangelfuld it-sikkerhed. Det blev ikke mødt med forståelse af T-Mobile, og efterfølgende nåede kommunikationen et informativt lavpunkt.

Andre metoder i samme branche

Praksis med at bruge de tre første tegn er ikke den eneste løsning på autentificering i forbindelse med kundeservice.

Ved teleselskabet 3 skal man aldrig oplyse kodeord overfor kundeservice. Ifølge pressechef Thilde Danielsen udfører 3 deres identifikation med kundenummer eller CPR-nummer.

Læs også: Netsundhedsplejerske.dk: Datalæk afslører e-mailadresser og passwords i klartekst

Ved YouSee verificerer man kundens identitet, ved at kunden oplyser to af de tre følgende informationer: kundenummer, CPR nummer og detaljer fra seneste faktura.

Mulighed for bedre it-sikkerhed

Teleselskaberne hæfter sig alle ved, at der er tiltro til deres medarbejdere, og at man har tiltro til sikkerheden.

Så vidt vides har der ikke været sager, hvor folk har narret sig til oplysninger gennem kundeservice.

»Man kunne ønske sig en form for to-faktor-validering. Det er selvfølgelig vanskeligt, hvis det er et telefonopkald til kundeservice. Men hvis det er en korrespondance over chat eller mail, vil en to-faktor-validering med eksempelvis en sms-besked gøre systemet betydeligt mere vanskeligt at kompromittere,« siger Jakob Heidelberg.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (17)
Jonas Olsson

Programmet melder, at bruteforce af 8 karakterer (alfanumerisk = store/små/specialtegn), vil tage indtil "Next Big Bang (> 10 years)".

Dermed må det i praksis regnes for upraktisk eller umuligt med nuværende teknologi og metoder. Hvis man kan opdele crackingen i to, tager 3 karakterer kun ca. 30 sekunder og 5 karakterer kun ca. 100 timer. Det viser fint, hvor ekstremt meget nemmere det er, at bruteforce et kodeord, der er opdelt.

Ja, så bare lige for at forstå det korrekt. Hvis en hacker fik fat i begge tabeller: hash af de første 3 karakterer og hash af password, så ville det tage ca. 100 timer at cracke et password bestående af 8 karakterer? Med dictionary cracking bliver dette vel et meget mere overkommeligt problem.

Det kunne være meget sjovt at få en kommentar på ovenstående eksempel fra teleselskaberne. Det virker mere til at de forholder sig til, om kundeservice kan læse passwords:

»De 3 første bogstaver og hele kodeordet opbevares hver for sig. Der er intet som ligger i klartekst, de er begge hashede hver for sig hvor vi anvender en kryptografisk hashfunktion (BCrypt). Når kundeservicemedarbejderen får de 3 første bogstaver oplyst af kunden tastes disse ind i systemet for verifikation,« uddyber Stine Olsen over en facebook-chat.

Thomas Larsen

Når nu vi alligevel har NemID burde det vel være muligt at implementere et interface hvor en kundeservice medarbejder på sikker vis kan validere identiteten på en given kunde.

Jeg skulle for nylig overføre et større beløb til en konto og fik i netbank besked på at ringe til banken. Der blev jeg taget igennem en længere quiz - "hvad hedder din bankrådgiver", Hvor meget indbetaler du månedligt på lån X, osv. Der var nok 10 spørgsmål af den karakter.

Men alt dette er jo fordi vi ikke har et standard interface til at autentificere en person via telefon.

Niels Østergård

Vist er den beskrevne praksis hos CBB kritisabel. Men at man hos "3" mener, at et CPR-nummer har noget at gøre med at kunne bevise sin identitet, er jo også galt (selv om det er en udbredt misforståelse). CPR-nummeret er en identifikation (brugernavn), men ikke en validering af denne identifikation (adgangskode).

Måske skulle CBB fastholde sin praksis, men øge password-længden til 3+8 = 11?

Thomas Jensen

Det burde være en smal sag at lade brugeren indtaste en separat "supportkode" under oprettelse af en konto, i stedet for at anvende en del af adgangskoden. Denne kode kunne benyttes til dette formål alene, og dermed undgå at sætte sikkerheden over styr.

Bjarne Nielsen

Måske skulle CBB fastholde sin praksis, men øge password-længden til 3+8 = 11?

Men det giver kun samme sikkerhed for 8 tegn, hvis der er uafhængig imellem de 3 (som vi må antage er gættet), og de efterfølgende 8.

Hvis de første tre findes i et dictionary, så er der rigtigt gode odds for at den del af det dictionary vil kunne bruges som udgangspunkt for at gætte de efterfølgende 8. Hvis de første tre er f.eks. 'Sto', så begynder vi med prefix som 'Storartet', 'Storebror' og 'Stormogul'. Med krav 11 tegn, så er padding til sidst med f.eks. '123!' også værd at prøve.

Og vi prøver selvfølgelig alle dem som starter med de samme tre tegn på en gang, for sådan virker bruteforcing, og derfor vil man starte med dem, hvor der er mange passwords som starter med de samme tre gode tegn.

Tilsvarende kan vi springe dem over som starter med f.eks. '5%x', for der hjælper dictionary ikke.

Michael Cederberg

CBB er åbentbart sikkerhedsamatører.

Hvis man går ud fra at de fleste vælger passwords med 8 tegn og at folk i praksis bruger ca. 100 forskellige tegn til deres passwords så kan man tabellægge deres hashes: Der bliver 10 mia. entries og det er muligt. Hvis de ikke gemte de 3 tegn, så vil tabellen skulle indeholde 10 billiarder entries (= ikke muligt at tabellægge).

Hvis nogen render med CBB's to password filer, så kan de nemt finde alle passwords.

I øvrigt opdagede jeg her til morgen at skolemælk.dk gemmer hele passwordet ... og villigt sender det til mig i en email.

Det burde være en smal sag at lade brugeren indtaste en separat "supportkode" under oprettelse af en konto, i stedet for at anvende en del af adgangskoden. Denne kode kunne benyttes til dette formål alene, og dermed undgå at sætte sikkerheden over styr.

Det kan folk ikke huske.

Jesper Nielsen
Michael Säilä

Jeg har for nyligt haft kontakt med yousee angående noget abonnement ændring på bland selv og hun insisterede på at den eneste måde hun kunne hjælpe mig på var at jeg oplyste hende mot Pwd til mit yousee hvorefter at jeg måtte meddele hende at det kom ikke til at ske! Arbejder selv i en af Danmarks største it sikkerheds organisationer og kan ikke forstå hvor man kan få sig selv til at spørge om dette! Endte med jeg måtte ændre Pwd til noget random og derefter ændre det tilbage.. Jeg er målløs

Lars Bjerregaard

Hvis de kan bruge de første 3 tegn af mit password til noget, kan det kun betyde én af to ting:

1) De har passwords i klartekst
2) De opbevarer passwords "krypteret" med en 2-vejs algoritme, der tillader dem at genskabe mit password, fordi de selv har nøglen.

Ingen af delene er særligt tillidsvækkende.....

Søren Pilgård

De opbevarer formodentligt et hash af hele passwordet og et hash af de 3 første bogstaver. Hvis du læser artiklen står der:

»De 3 første bogstaver og hele kodeordet opbevares hver for sig. Der er intet, som ligger i klartekst, de er begge hashede hver for sig,hvor vi anvender en kryptografisk hashfunktion (BCrypt). Når kundeservicemedarbejderen får de tre første bogstaver oplyst af kunden, tastes disse ind i systemet for verifikation,« uddyber Stine Olsen over en Facebook-chat.

Thomas Gilbert

De 3 første tegn er et kæmpe problem, men hos http://www.skolemaelk.dk gemmer de hele passwordet uden at det er 'hashed'.
Når man logger ind, kan man under sin profil se:
Kundenummer
Pinkode
Brugernavn
Kodeord
Jeg forstår ikke hvorfor f.eks. Version2 ikke skriver om de hjemmesider i stedet.
Det hele er i øvrigt sendt over internettet uden TLS/SSL. Dvs, ukrypteret.
( Jeg har faktisk aldrig set et af mine egne passwords, og fik et shock da det lige pludseligt stod på skærmen foran mig )

Mikkel Hansen

Nej, de kan godt hashe de to dele af kodeordet med en envejsfunktion (antaget eksistensen af envejsfunktioner).

Når du oplyser de tre første tegn af kodeordet bruger de blot samme envejsfunktion, og sammenligner værdien med det oprindelige hash.

Henning Wangerin

Det burde være en smal sag at lade brugeren indtaste en separat "supportkode" under oprettelse af en konto, i stedet for at anvende en del af adgangskoden. Denne kode kunne benyttes til dette formål alene, og dermed undgå at sætte sikkerheden over styr.

Mit tyske mobil-abo generere selv en kode som skal bruges ved kontakt til kundeservice. Ebay.de gør det samme.

Hvor svært kan det være?

Nå ja. Vi sidder jo i DK. Landet hvor mange brancher snakker om sikkerhed. Men ikke fører det ud i praksis.

/Henning

Jarle Knudsen

Hvis en hacker fik fat i begge tabeller: hash af de første 3 karakterer og hash af password, så ville det tage ca. 100 timer at cracke et password bestående af 8 karakterer?

»De 3 første bogstaver og hele kodeordet opbevares hver for sig. Der er intet, som ligger i klartekst, de er begge hashede hver for sig« uddyber Stine Olsen over en Facebook-chat."

Brute-force eller dictionary attack er bare så gammeldags. :O)

Med "rainbow table attack" vil man klare det samme på næsten ingen tid.

En anden ting det er underlig at de ikke tilføjer "salt" til passwords før de blive hashed.

Simpel anvendelse af "saltværdi", vil gøre disse typer af angreb (brute force, dictionary, rainbow table) så godt som umuligt.

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