Usandsynlig hændelse giver ny procedure: KMD dropper tidskoder i Skat-login

Fejlen, hvor to borgere kunne se hinandens forskudsopgørelse, skyldes brugen af tidskode ved login, fortæller KMD. Nu får alle brugere et unikt ID-nummer.

Onsdag blev der slået alarm hos Skat og leverandøren KMD. To borgere kunne se i hinandens skattemappe, og Skat lukkede straks for adgangen til forskudsopgørelserne, da det blev opdaget.

Men problemet blev hurtigt løst og rettet, så det ikke kan ske igen, fortæller KMD. En delmængde af softwaren, der kører Skats forskudsopgørelse, er købt og ikke egen-udviklet, og her blev tidskoden fra mainframen brugt til at skelne brugerne fra hinanden.

»På grund af den store interesse der var, skete der det meget usandsynlige, at to logger nøjagtigt samtidigt. Tidskoden tæller med milliontedele af et sekund, og så er det sket, fordi mange tusinde loggede ind på kort tid. Det var ligesom når Billetnet åbner for billetsalget til en U2-koncert. Interessen var bare større her,« fortæller Michael Dupont Fischer, vicedirektør i KMD.

I løbet af to timer blev proceduren ændret, så alle brugere, der logger ind, også får et unikt ID-nummer. Det er samme løsning, som KMD bruger i alle de egenudviklede løsninger, fortæller vicedirektøren.

»Det, jeg er glad for i denne situation, er, at vi lykkes med at ændre fejlen på meget kort tid. Men vi er også i højeste 'defcon 5'-beredskab,« siger Michael Dupont Fischer.

Han mener ikke, at en tilsvarende fejl vil kunne ske igen med KMD-software, fordi der i alle KMD's egne systemer bliver brugt unikt ID-nummer som standard.

»Det var en enlig svale. Og det var svært at forudsige, for vi har aldrig haft sådan en hændelse før,« siger han.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (28)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Mikkel Mortensen

"Det, jeg er glad for i denne situation, er (...)" - Ja, måske er du glad. Men det her MÅ bare ikke ske. Hvordan har man kunnet leve med at den indkøbte software havde denne - omend meget lille - risiko for fejl? Eller man har måske ikke checket softwaren ordentligt inden man satte den til at håndtere så personfølsomme ting?

  • 2
  • 0
#2 Peter Mogensen

Tjae... alene den ide at tage et bruger-ID fra uret på maskinen burde få en alarmklokke til at ringe hos udvikleren.

Jeg har også en applikation, hvor der genereres UUID'er (som kan afhænge af uret), men den checker sgu da efter at det er genereret om det valgte ID allerede eksisterer - uanset hvor usandsynligt det måske er!

  • 1
  • 0
#4 Poul-Henning Kamp Blogger

»På grund af den store interesse der var, skete der det meget usandsynlige, at to logger nøjagtigt samtidigt. Tidskoden tæller med milliontedele af et sekund, og så er det sket,

Tid er et meget misforstået fænomen i IT og denne sag er et klart eksempel.

Der er tre forskellige koncepter man skal holde ude fra hinanden med hensyn til tid:

Præcision: Er klokken faktisk det tidskoden siger og hvordan ved man det ? Dette er relevant for hvis tidskoden justeres ved at springe bagud, kan den samme tidskode opstå uafhængigt to eller flere gange.

Opløsning: Groft sagt, hvor mange ciffre er der i tidskoden (msec, µsec, nsec osv)

Granularitet: Hvor ofte opdateres tidskoden.

Selvom tidskoden har opløsning af mikrosekunder, er der ingen garanti for at den har en tilsvarende granularitet.

Rigtig mange operativsystemer har granularitet på kun 100-1000 opdateringer i sekundet.

For alle disse årsager og fordi folk generelt ikke tænker sig godt nok om, bør vi slå fast en gang for alle:

Et timestamp er ikke unikt.

Der er altså ikke tale om en "unik hændelse" eller en "usandsynlig hændelse", men om "helt almindelig inkompetance".

Poul-Henning

  • 4
  • 0
#6 Allan Ebdrup Blogger

Jeg grinte meget da jeg i et tidligere job fandt ud af at en tidligere ansat arkitekt havde brugt et tidsstempel som nøgle. Det gav kæmpe problemer da databaseserveren blev opgraderet til ny og hurtigere hardware, pludseligt blev der genereret mange tupler med samme id. Jeg troede ikke det var så udbredt at selv skat brugte metoden. Morskaben fortsætter.

  • 1
  • 0
#9 Poul-Henning Kamp Blogger

Hvis Opløsningen er flere størrelsesordner bedre end Granulariteten, hvilken fordel har man så af den høje opløsning?

At man ikke har (alt for) mange formater af timestamps og at formattet ikke afhænger af hvilken computer man kører på.

Her kunne jeg sige en masse om idiotien i at bruge decimale formater (timespec, timeval) på binære computere, men det springer vi over denne gang.

Poul-Henning

  • 1
  • 0
#10 Peter Mogensen

Tjae... For 10 år siden kom jeg i kort tid ind over et CMS, som havde fået den geniale ide at basere sikkerheden på om man kunne gætte bruger-id. D.v.s. authentikering afhang af om man havde en cookie med det rigtige ID. Bruger-id var så genereret udfra brugerens oprettelsestidspunkt. Og som om det ikke var slemt nok, så var der jo netop éen bruger som ikke var svær at gætte oprettelsestidspunktet på: ADMIN ... som blev oprettet på installationstidspunktet.

  • 1
  • 0
#11 Hans Schou

Et timestamp er ikke unikt.

Jeg syntes ellers der var et eller andet styresystem som garanterede, at hvis man spurgte om tiden to gange lige fter hinanden, så var man garanteret at det var forskellige tider. Tiden er så nok ikke præcis, men dog forskellige. Var det Sun Solaris?

  • 0
  • 0
#12 Poul-Henning Kamp Blogger

Det kaldes "Lamports timestamps" (Ja, Leslie Lamport som i LaTeX :-).

Det er et "neat hack", men ikke praktisk brugbart på multi-cpu systemer hvor selve konceptet af "samtidighed" er utrolig svært at fastlægge og dyrt i performance at implementere.

Poul-Henning

  • 2
  • 0
#15 Anonym

Der er altså ikke tale om en "unik hændelse" eller en "usandsynlig hændelse", men om "helt almindelig inkompetance".

Det er måske lige hårdt nok sagt.

Jeg faldt selv i 'fælden' engang i '98, hvor jeg skulle bruge en unik id, og der brugte jeg GetTickCount.

Jeg kendte godt 'risikoen', men havde aldrig forestillet mig, at to brugere skulle logge på 'på samme tid', der var trods alt kun 8-900 brugere på systemet.

For lige at sikre at vi snakker om det samme, så er der tale om en session id, og ikke en 'bruger id'.

Da session id'en kun bliver genereret ved logon, valgte jeg blot at lægge en lille sleep ind i den (i forvejen serialiserede) procedure.

Med hensyn til at generere en unik id, kan man principielt bare bruge en fortløbende tæller, men det giver jo et sikkerhedsmæssigt problem. Hvis man har mulighed for at gætte id'en, kan man hijacke sessions.

Jeg vil umiddelbar tro, at et 'timestamp' kombineret med process7threadID burde være godt nok til id'er.

Så man kan vel sige, at de blot har 'glemt' den dimension, der hedder process/threadid.

  • 0
  • 1
#17 Anonym

kombineret med et random nummer

Det kommer vel an på random generatoren. Hvis den bliver kaldt inden for samme 'nanosekund', kan man måske risikere at den også returnerer samme værdi.

Hvis timestampet er det samme, så nytter det ikke at seed'e den med timestamp.

Men jeg har ikke brugt random funktioner ret meget, så jeg ved ikke om det er et problem mht. samtidighed.

Jeg ville nok foretrække kombinationen af timestamp og process/task id, da der ike kan eksistere 2 med samme id på samme tid.

  • 0
  • 0
#18 Poul-Henning Kamp Blogger

Det kommer vel an på random generatoren. Hvis den bliver kaldt inden for samme 'nanosekund', kan man måske risikere at den også returnerer samme værdi.

Nej, en random generator returnerer ikke samme output nogensinde, den producerer altid et nyt output til hver kalder.

At der så er en ikke-nul sandsynlighed for, at det output er magen til det forrige, er så en helt anden og meget usandsynlig sag.

Poul-Henning

  • 1
  • 0
#19 Anonym

Nej, en random generator returnerer ikke samme output

[b]Een[/b] random generator eller [b]alle[/b]

Jeg kender ikke til samtlige implementeringer af random generatorer, så jeg vil ikke påstå at en hvilkensomhelst random generator til enhver tid genererer random output.

  • 0
  • 0
#20 Poul-Henning Kamp Blogger

Jeg kender ikke til samtlige implementeringer af random generatorer, så jeg vil ikke påstå at en hvilkensomhelst random generator til enhver tid genererer random output.

Hvis en random generator genbruger output, er den per definition ikke en random generator.

Om nogen engang har været dumme nok til at implemenetere en sådan, er en helt anden side af sagen.

Jeg kender ingen implementeringer der har været så tåbelige.

Poul-Henning

  • 0
  • 0
#21 Anonym

Hvis en random generator genbruger output, er den per definition ikke en random generator.

Ja, det er vi da enige om, men

Jeg kender ingen implementeringer der har været så tåbelige

Nr. 2 hit på Google: http://www.theregister.co.uk/2007/11/13/windows_random_number_gen_flawed/

Jeg har ikke selv kigget, men snakker man ikke om at problemstillingen er .NET (og windows)?, uagtet man tilsyneladende får timestamp fra mainframe, som jeg ikke lige kan se sammenhængen i mht. .NET og mainframe.

  • 0
  • 0
#22 Anonym

Kom lige i tanke om vi snakker om det samme når du skriver

Hvis en random generator genbruger output

Vi snakker ikke om at genbruge output, men at Thread A og Thread B kalser generatoren på samme tid.

  • 0
  • 0
#24 Finn Aarup Nielsen

Det er vel fødselsdagsparadokset?

Hvis 1000 folk logger ind på indenfor 10 sekunder og der er et mikrosekunds granualitet så må formlen vel være:

1-prod((9999001:9999999) / 10000000) hvilket er omkring 5% (hvis min computerens floating point kan holde til beregningen)

  • 0
  • 0
#25 Peter Lind

Vi snakker ikke om at genbruge output, men at Thread A og Thread B kalser generatoren på samme tid.

En random number generator der genererer et nummer udelukkende baseret på tidspunkt er ikke en random number generator ... eller, hvis det er, så er det en fantastisk dårlig en af slagsen. Tid er ikke tilfældig (hvilket er ret heldigt) men fortløbende, så hvis tid var eneste seed ville du kunne gætte hvad det "tilfældige" nummer bliver blot du ved hvornår det er genereret.

Det er der så, så vidt jeg husker, visse systemer der er blevet pwned på ... men igen, de har netop ikke gjort brug af random number generators.

  • 0
  • 0
#26 Johnnie Hougaard Nielsen

Selvom tidskoden har opløsning af mikrosekunder, er der ingen garanti for at den har en tilsvarende granularitet.

Når vi taler om mainframe og timestamps, så har maskinerne en STCK (store clock) funktion, som har større opløsning og granularitet end mikrosekunder, og hvor der også i et sysplex med flere maskiner garanteres entydighed. Det aktuelle problem kommer så af at de åbenbart ikke har brugt dette, men i stedet den timestamp funktion som er indbygget i database-systemet DB2. Denne har kun 6 cifre efter kommaet, og er meget eksplicit dokumenteret med risikoen for duplikater.

Så det er ganske rigtigt meget lidt smart at bruge dette uden at checke for kollisioner.

  • 0
  • 0
#28 Henrik Kramselund Jereminsen Blogger

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

og mere specifikt http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010.pdf

"A3 Broken Authentication and Session Management Am I Vulnerable? The primary assets to protect are credentials and session IDs. 1. Are credentials always protected when stored using hashing or encryption? See A7. 2. Can credentials be guessed or overwritten through weak account management functions (e.g., account creation, change password, recover password, weak session IDs)?"

pinligt pinligt i 2012 at blive ved med at lave den slags fejl! Hint: lad være med at udvikle ting selv som du ikke forstår, brug standard biblioteker som er vedligeholdt, testet osv.

Så sent som igår anbefalede jeg igen bogen "24 Deadly Sins of Software Security af Michael Howard, David Leblanc, John Viega 2009"

Denne bog bør være obligatorisk læsning for alle udviklere, og indeholder "sins" beskrevet med eksempler fra mange gængse programmeringssprog

  • 0
  • 0
Log ind eller Opret konto for at kommentere