Pudsig rejsekort-fejl rettet: Forskel på små og store bogstaver gav adgang til andre brugerkonti

25 kommentarer.  Hop til debatten
Selskabet bag rejsekortet har rettet en fejl i systemets back end-del, der i særlige tilfælde kunne misbruges til at komme ind på andre brugeres konto via online-selvbetjeningen.
person
4. december 2014 kl. 14:39
errorÆldre end 30 dage
person

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.

Artiklen fortsætter efter annoncen

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.

25 kommentarer.  Hop til debatten
Fortsæt din læsning
Debatten
Log ind for at deltage i debatten.
settingsDebatindstillinger
23
Jan Borup Coyle
8. december 2014 kl. 13:01

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
22
Nick Cooper
8. december 2014 kl. 12:53

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
25
Nick Cooper
11. december 2014 kl. 18:42

Men det er jo heller ikke det, der er sket.

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.

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
20
Allan Jensen
5. december 2014 kl. 16:31

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
18
Casper Olsen
5. december 2014 kl. 09:54

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
19
Peter Makholm
5. december 2014 kl. 10:21

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.

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

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
15
Kristian Sørensen
5. december 2014 kl. 06:22

At cykle er sundt.

At cykle gør glad.

  • more_vert
    • insert_linkKopier link
14
Morten Rasmussen
4. december 2014 kl. 20:05

....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
12
Lýsa Gabriel
4. december 2014 kl. 17:41

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
8
Deleted User
4. december 2014 kl. 16:36

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
11
Deleted User
4. december 2014 kl. 17:33

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
17
Poul Pedersen
5. december 2014 kl. 09:40

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?

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?

  • more_vert
    • insert_linkKopier link
13
Per Bækgaard
4. december 2014 kl. 17:52

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
5
Christian Nobel
4. december 2014 kl. 16:01

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
4
Peter Makholm
4. december 2014 kl. 15:51

Bruger for og efternavn til at identificere unikke brugere???? Kors i r....

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.

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
6
Jonas Høgh
4. december 2014 kl. 16:01

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
7
Brian Hansen
4. december 2014 kl. 16:19

Bruger for og efternavn til at identificere unikke brugere???? Kors i r....

  • more_vert
    • insert_linkKopier link
9
Kurt Brixen
4. december 2014 kl. 16:40

Nej, man bruger et selvalgt brugernavn.

  • more_vert
    • insert_linkKopier link
2
Joe Sørensen
4. december 2014 kl. 15:19

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
1
Ditlev Petersen
4. december 2014 kl. 13:50

det var da pudsigt.

  • more_vert
    • insert_linkKopier link