En kvinde ved navn Tina Andersen fra Aalborg oplevede, hvordan hun fik adgang til en anden brugers konto via reejsekortets selvbetjening. Den anden bruger viste sig også at hedde Tina Andersen, hvilket startede spekulationer om, hvorvidt folk med samme navn kunne logge ind på hinandens konti.
Det beskrev DR Nordjylland tidligere i dag, men nu viser det sig, at fejlen er meget begrænset og skyldes, at rejsekort-systemet i nogle tilfælde ikke er case-sensitivt, altså skelner mellem små og store bogstaver til brugernavnene. Fejlen er nu blevet rettet.
Oplysninger om rejser og optankning på de andre personer har været tilgængelige på den personlige side på rejsekortet.dk, men der har hverken været adgang til CPR-nummer eller oplysninger om betalingskort ifølge selskabet bag rejsekortet.
»Vi beklager fejlen dybt. Det er alene rejsedata, der har været tilgængelige. Personfølsomme oplysninger såsom CPR-numre er registreret, som lovgivningen foreskriver, og betalingskortoplysninger er kun registreret hos Nets,« siger adm. direktør i Rejsekort A/S Bjørn Wahlsten i en pressemeddelelse.
Fejlen kan opstå, fordi selvbetjeningen på rejsekort.dk tillader, at brugerne opretter sig med enslydende brugernavne, hvis blot der er forskel på små og store bogstaver. Når en bruger imidlertid bestiller en ny adgangskode, skelnede systemet ikke mellem små og store bogstaver, og dermed kunne det ske, at brugeren i stedet nulstillede adgangskoden til kontoen med det enslydende brugernavn og efterfølgende kunne få adgang til denne brugers konto.
Problemet er dog ikke så omfattende ifølge rejsekort-selskabet, der kun har fundet syv tilfælde af identiske brugernavne, hvor der kun er forskel på de store og små bogstaver. Brugerne har nu fået tildelt nye brugernavne.
- emailE-mail
- linkKopier link

...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.
Fortsæt din læsning
- Sortér efter chevron_right
- Trådet debat
Hvis rejsekortets system nu var skrevet i Visual Basic som ikke er case-sensitiv, så var det nok aldrig sket :-)
- more_vert
- insert_linkKopier link
Det er mig ubegribeligt at man som developer i 2014 kan slippe af sted med at kode et system, som plukker brugere ude af en database baseret på en relation mellem for- og efternavn i stedet for, f.eks., et incrementiælt user-ID, som er statisk gennem brugerens levetid i modsætning til de gængse navnetyper beskrevet i Navneloven. (Et familienavn kan jo ændre sig ved vielser, og fornavne kan ændres på sognekontoret og er i realiteten dynamiske values, som derfor bliver utroværdige som user inputs.)
Det er ligegyldigt om programmøren har glemt at drikke sin kaffe i sin morgenstressede kodningsproces - det er en fejl, der ikke må ske (fordi den kompromitterer brugeres finansielle sikkerhed og øger risikoen for målrettet identitetstyveri), og som nemt ville kunne afhjælpes ved at sløjfe den relationelle sammenligning og i stedet holde sig 100% til ét enkelt, variabelt user input, nemlig 'username' - og selvfølgelig case-insensitive.
Der er i hvert fald en, der skal have repeteret sit introkursus på W3Schools.com. Firstname og Lastname er ligegyldig info databasemæssigt. En etisk korrekt username-validering skal ikke bestå af en kontrol af flere sammenhængende kolonner i samme tabel. Det afgørende er, at der foregår en kobling mellem borgerens unikke CPR-nr., som systemet bruger i forvejen qua NEM-ID, og så det selvvalgte username.
- more_vert
- insert_linkKopier link
Men det er jo heller ikke det, der er sket....baseret på en relation mellem for- og efternavn...
- more_vert
- insert_linkKopier link
Men hvis det kan lade sig gøre at logge på en andens brugerkonto ved hjælp af sine egne credentials, så ændrer det ikke på at der er sket et fuckup i de relationelle sammentræk af tabellerne, og det burde ikke kunne ske, hvis man i databasen bruger identiske IDs til at holde styr på tabelrækkernes individuelle sammenhæng med hinanden. Case-sensitive eller ej. Databasen er ikke designet korrekt.Men det er jo heller ikke det, der er sket.
Hvis Tina Andersen logger ind med TINAandersen med uid X, og databasen udtrækker tinaANDERSEN i stedet for med uid Y pga. ovennævnte fejl, så vil tilsvarende relationelle udtræk via password-tabellens puid give en forkert adgangskode at validere med, hvis koderen havde gjort sit arbejde ordentligt. Brugeren ville altså slet ikke være i stand til at komme ind i første omgang. Loginscriptet, hvis det virkede efter hensigten, ville blokere permanent for login for den ene af dem indtil fejlen ville blive opdaget og rettet.
- more_vert
- insert_linkKopier link
på nordjyske.dk står der at stod et andet CPR nr, men jeg ved ikke om man normalt kan se CPR på rejsekortets hjemmeside URL: http://nordjyske.dk/nyheder/fik-adgang-til-personlige-oplysninger-paa-rejsekortet/6301eddb-07db-4a59-b7da-6d71ff0cc755/4/1513
- more_vert
- insert_linkKopier link
Det giver næsten mening, men kun fordi vi allerede ved at deres passwords ikke kan kende forskel på små or store bogstaver, hvilket tilgengæld ingen mening giver.
- more_vert
- insert_linkKopier link
Så langt så godt, men forklare ikke hvordan "a" har nulstillet "A" password og fået tilsendt dette? Man nulstiller jo ikke password på 1 record for at sende det ud til record 2..
Kan det tænkes man har lavet en brøler, og lavet en "update users where usenamer='a' (som ikke er case Sensitiv) og derved nulstillet begge brugers password?
og at "a" derefter ved en fejl har skrevet "A" under sit login ?
- more_vert
- insert_linkKopier link
Jeg kan godt forestille mig et systemdesign hvor man har et minimalt system til håndtering af autentificering som vedligeholder en relation mellem brugernavne og kodeord (auth) og så et større system der vedligeholder en større samling af metadata om brugeren (admin).Så langt så godt, men forklare ikke hvordan "a" har nulstillet "A" password og fået tilsendt dette? Man nulstiller jo ikke password på 1 record for at sende det ud til record 2.
Det vil sige at processen med at nulstille et kodeord vil se nogenlunde således ud:
Brugeren tilgår admin systemet og beder om en reset
Adminsystemet beder authsystemet om en reset-token for brugernavnet
Adminsystemet sender en url til brugeren der indeholder den reset-token der kommer fra authsystemet
Brugeren trykker på urlen og adminsystemet sender reset-token til authsystemet og får et brugernavn retur
Adminsystemet viser information om det brugernavn den har fået fra authsystemet
Hvis disse to systemer fortolker brugernavne forskelligt, så kan jeg godt forestille mig en fejl som den artiklen beskriver. Det virker måske som et unødigt kompliceret systemdesign, men det giver en bedre isolation af kodeord hvilket kan være ønskeligt.
Jeg forsøger ikke at forsvare udviklerne bag rejsekortet, men forsøger at lære af deres fejl så vi alle sammen kan blive bedre til systemudvikling. Mine ideer er dog baseret på vildt gætteri, så det ville være fedt hvis nogle teknikere der vidste noget kunne give en tekniske forklaring der ikke var blevet forvasket af en kommunikationschef.
- more_vert
- insert_linkKopier link
....hvis de absolut skulle sende brugernavnet rundt mellem alle delsystemerne, så kunne de da i det mindste hashe det forinden.
Det kan muligvis pege på grundlæggende problemer i arkitekturen hos Rejsekort.
Kvalitetskontrol, tjeklister, flere personer på den enkelte opgave, og omfattende tests (undtaget RL test!) er nok heller ikke den værste vej at gå.
- more_vert
- insert_linkKopier link
Jeg er ikke sikker på at jeg ville nøjes med at finde det pudsigt hvis det var min konto, der var adgang til. Jeg er godt nok glad for mit anonyme rejsekort. Hvis man med 'glad' mener 'dybt irriteret, men i det mindste er mine oplysninger hos mig og ikke hos tilfældige trafikselskaber', selvfølgelig.
- more_vert
- insert_linkKopier link
Hov, det har Jonas Høgh jo sådan set allerede svaret på - at man slår brugerens mail korrekt op et sted baseret på brugernavn, men slår brugerens password forkert op et andet sted også baseret på brugernavn.
- more_vert
- insert_linkKopier link
Hvis TINAandersen ved en fejl kommer til at nulstille password for tinaANDERSEN, så bliver nulstillet password vel sendt til den e-mail der er registreret for tinaANDERSEN og ikke til TINAandersen's mail?
Eller hvordan virker nulstilning af password hos rejsekortet?
- more_vert
- insert_linkKopier link
Det afhænger da helt af hvilke og hvordan systemerne er lavet case-insensitive, og nok også en del af hvilken entry der kommer først i databasen når den slår navnet op? Det kan jo nemt være at den kombinerer mail-adresse og link til den resatte konto op på to forskellige måder, selvom de bliver sendt ud i en mail?Hvis TINAandersen ved en fejl kommer til at nulstille password for tinaANDERSEN, så bliver nulstillet password vel sendt til den e-mail der er registreret for tinaANDERSEN og ikke til TINAandersen's mail?
- more_vert
- insert_linkKopier link
Præcis. Der er et eller andet, som ikke hænger sammen i forklaringen.Hvis TINAandersen ved en fejl kommer til at nulstille password for tinaANDERSEN, så bliver nulstillet password vel sendt til den e-mail der er registreret for tinaANDERSEN og ikke til TINAandersen's mail?
- more_vert
- insert_linkKopier link
Eller hvordan virker nulstilning af password hos rejsekortet?
Man skal vel foretage en nul-rejse fra en stander til en anden på ens hjemme-perron for at bekræfte en ændring af password'et -- eller noget? :-)
- more_vert
- insert_linkKopier link
Peters indlæg er tidsstemplet til 15.51, og dermed skudt ind før det indlæg han kommenterer.
Det lader til at V2 har visse problemer med tid, muligvis at (now) afhængig af situation opfattes som universal tid, andre gange som lokal tid.
Edit - og det har de, dette indlæg er tidsstemplet en time før det er skrevet.
- more_vert
- insert_linkKopier link
Som jeg læser artikeln så bruger rejsekortet selvvalgte brugernavne til at identificere brugerne. Det er der mange systemer der gør. Mange brugere vil forsøge at vælge et brugernavn der består af deres navn eller initialer.Bruger for og efternavn til at identificere unikke brugere???? Kors i r....
Rejsekortet har tilsyneladende så forskellige delsystemer der hver især implementere egne regler for sammenligning og opslag af brugernavne. Det er desvære også noget jeg har set alt for ofte, dog aldrig i denne variation. Men jeg er tit stødt på systemer hvor de enkelte dele havde forskellige opfattelse af hvad et validt brugernavn var med det resultat at man kun kunne logge ind igennem nogle af delsystemerne.
Men det kunne være interessant at dykke ned i hvordan fejlen kan være opstået. Er det fordi det slet ikke er speccet om brugernavne er følsomme overfor store/små bogstaver og hver udvikler bare har gjort hvad vedkommende fandt mest naturligt eller har speccen ændret sig?
Jeg kan i hvert fald levende forestille mig en specification der antød at store og små bogstaver havde betydning og at der på et eller andet tidspunkt er nogen der er kommet til fornuft uden at det er blevet konskvensændret gennem hele systemet.
Så jeg betragter det absolut som en fejl der er tegn på dårlig kvalitetskontrol og testning, men jeg kan også godt forklare hvordan fejlen kan været opstået uden idioti.
- more_vert
- insert_linkKopier link
Hvis man anvender en case-insensitiv RDBMS, fx MS SQL Server i standard konfiguration, er det vel lige til højrebenet for en ikke helt vågen udvikler at implementere login som
"select top 1 * from users where username = @username and password = @password"
og glemt password som
"select email from users where username = @username"
Det giver den beskrevne opførsel, og er vel ikke specielt pudsigt.
- more_vert
- insert_linkKopier link
Bruger for og efternavn til at identificere unikke brugere???? Kors i r....
- more_vert
- insert_linkKopier link
Jeg tror ikke helt det du forstår hvad Brian siger.Nej, man bruger et selvalgt brugernavn.
- more_vert
- insert_linkKopier link
Så la da vær. Findes der fejl der ikke er lavet endnu i det projekt, eller kan man efterhånden bruge dem som en checklist?
- more_vert
- insert_linkKopier link
Jeg synes desværre længe at de har været der, hvor de kan bruges som checkliste.
http://ekstrabladet.dk/nyheder/samfund/vaersgo-hr-minister-saa-gak-gak-er-rejsekortet/5315043
- more_vert
- insert_linkKopier link