---

Hej,

Er der nogen sikkerhed baseret på en fil på computeren og et koderord, der
sjældent skiftes?

Hvis man kan fjernbetjene maskinen og aflure kodeord er der vel ingen
sikkerhed. Og dvs sikkerheden ligger uden for.

/X

---

"TDC" <x.spam@get2net.dk> writes:

>Er der nogen sikkerhed baseret på en fil på computeren og et koderord, der
>sjældent skiftes?

Ja, men man kan ikke sige, at den er "47% sikkert". Man må sætte
sig ned og lave en konkret analyse og ud fra den definere, om
sikkerheden er tilfredsstillende i forhold til de opstillede
risici og konsekvensen af, at de indtræffer.

For almindelig brug af netbank vil man nok komme frem til, at
det er (mere end) sikkert nok.

Mvh.
   Klaus.

---

Hej,

Nå sikkeheden er baseret på et kodeord og noget der er på PCen, ser jeg
overhoved ingen sikkerhed ud over hvad SSL giver

Hver gang andre får adgang til en computer kan de dermed også få adgang til
deres netbank og/eller udgive sig for en anden.

Adgangen for man hver gang man er ude og besøge en klassekammerat, via mail
eller via bagdøre.

Jyske Bank har altid har en tilsyneladende sikker løsning: selv om der
ligger en sniffer på computeren som så kan få adgang til banken, kan den
ikke udføre transaktioner, fordi hver transaktion behøver ny
information/nøgle fra nøglekortet.

Så det afgørende er ikke om man har sådan en her (som Kristian Thy henviser
til):
http://www.danskebank.dk/Link/PrivatHembankenInstruktionNyKodbox

men der også skal bruges nøgler når man er kommet ind.

/Jørgen

"Klaus Ellegaard" <klausellegaard@msn.com> wrote in message
news:cafq5c$9t8$1@news.klen.dk...
> "TDC" <x.spam@get2net.dk> writes:
>
> >Er der nogen sikkerhed baseret på en fil på computeren og et koderord,
der
> >sjældent skiftes?
>
> Ja, men man kan ikke sige, at den er "47% sikkert". Man må sætte
> sig ned og lave en konkret analyse og ud fra den definere, om
> sikkerheden er tilfredsstillende i forhold til de opstillede
> risici og konsekvensen af, at de indtræffer.
>
> For almindelig brug af netbank vil man nok komme frem til, at
> det er (mere end) sikkert nok.
>
> Mvh.
> Klaus.

---

TDC wrote:

> Jyske Bank har altid har en tilsyneladende sikker løsning: selv om der
> ligger en sniffer på computeren som så kan få adgang til banken, kan
> den ikke udføre transaktioner, fordi hver transaktion behøver ny
> information/nøgle fra nøglekortet.

Det er korrekt, at JyskeBank's løsning med engangsnøgler er god, men det
betyder ikke at der ikke er huller i systemet. Hvis du kan opsnappe
engangskodeordet inden det modtages af banken, så kan du bruge det til en
transaktion - uanset at det er et engangskodeord. Teknikken er tidligere
beskrevet her i gruppen.

Som Troels dog påpeger, så er sikkerheden i webbanker i høj grad baseret
på, at det er svært at "stjæle" penge fra en webbank, da du jo skal
fortælle banken, hvor pengene skal overføres til.

--
Jesper Stocholm http://stocholm.dk

Programmer's code comment:
//It probably makes more sense when you're stoned.

---

Jesper Stocholm skrev:

>Det er korrekt, at JyskeBank's løsning med engangsnøgler er god, men det
>betyder ikke at der ikke er huller i systemet. Hvis du kan opsnappe
>engangskodeordet inden det modtages af banken, så kan du bruge det til en
>transaktion - uanset at det er et engangskodeord. Teknikken er tidligere
>beskrevet her i gruppen.

Det er ikke helt rigtigt. For at lave fusk med Jyske Banks system
er det langt fra nok at opsnappe en kode. Én kode giver i teorien
adgang én gang - men det kikser fordi man ikke ved hvilken kode
banken vil bede om, og der skal endnu en kode til at bekræfte en
evt. transaktion.

Den teknik, der er beskrevet - og som vil virke uanset hvilke
systemer man sætter op - består i en mellemmandssituation: Man
klipper ledningen mellem kunden og banken over og opsnapper al
kommunikation fra begge sider. Derefter simulerer man normale
transaktioner til begge sider så ingen kan opdage noget.
Derudover skaffer man sig de koder man selv skal bruge ved at
skrive til kunden at der var en fejl og at han skal sende en kode
mere (nemlig den som banken beder om når man laver sine egne
transaktioner).

>Som Troels dog påpeger, så er sikkerheden i webbanker i høj grad baseret
>på, at det er svært at "stjæle" penge fra en webbank, da du jo skal
>fortælle banken, hvor pengene skal overføres til.

Det er klart, men hvor stort et problem er det at oprette en
konto i en fjern by under falsk navn og cpr-nummer og så hæve
pengene i en ruf når de er overført? Tjekker banken med
folkeregistret?

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

---

Bertel Lund Hansen wrote:

>>Som Troels dog påpeger, så er sikkerheden i webbanker i høj grad
>>baseret på, at det er svært at "stjæle" penge fra en webbank, da
>>du jo skal fortælle banken, hvor pengene skal overføres til.
>
> Det er klart, men hvor stort et problem er det at oprette en
> konto i en fjern by under falsk navn og cpr-nummer og så hæve
> pengene i en ruf når de er overført? Tjekker banken med
> folkeregistret?

Det tror jeg bestemt de gør.

--
Niels Callesøe - dk pfy
pfy[at]nntp.dk - http://www.pcpower.dk/disclaimer.php

På det digitale natbord: Applied Cryptography, Menezes et al. 1996-2001

---

"Niels Callesøe" <pfy@nntp.dk> skrev i en meddelelse
news:Xns950776D396F51k5j6h4jk3@62.243.74.163...
> Bertel Lund Hansen wrote:

> > Det er klart, men hvor stort et problem er det at oprette en
> > konto i en fjern by under falsk navn og cpr-nummer og så hæve
> > pengene i en ruf når de er overført? Tjekker banken med
> > folkeregistret?
>
> Det tror jeg bestemt de gør.

Nope, min sidstfødte søn har fået en børneopsparing med et forkert navn
(Stave/slåfejl)

/Brian

---

Bertel Lund Hansen wrote:

> Jesper Stocholm skrev:
>
>>Det er korrekt, at JyskeBank's løsning med engangsnøgler er god, men
>>det betyder ikke at der ikke er huller i systemet. Hvis du kan
>>opsnappe engangskodeordet inden det modtages af banken, så kan du
>>bruge det til en transaktion - uanset at det er et engangskodeord.
>>Teknikken er tidligere beskrevet her i gruppen.
>
> Det er ikke helt rigtigt. For at lave fusk med Jyske Banks system
> er det langt fra nok at opsnappe en kode. Én kode giver i teorien
> adgang én gang - men det kikser fordi man ikke ved hvilken kode
> banken vil bede om, og der skal endnu en kode til at bekræfte en
> evt. transaktion.

Ja, det benægter jeg heller ikke. Min pointe er "blot", at løsningen med
engangsnøgler ikke nødvendigvis giver en _sikker_ løsning. Den giver en
/sikrere/ løsning, hvilket er noget andet end indholdet i indlægget jeg
svarede på - som jeg læser det, i hvert fald :)

> Den teknik, der er beskrevet - og som vil virke uanset hvilke
> systemer man sætter op - består i en mellemmandssituation: Man
> klipper ledningen mellem kunden og banken over og opsnapper al
> kommunikation fra begge sider. Derefter simulerer man normale
> transaktioner til begge sider så ingen kan opdage noget.
> Derudover skaffer man sig de koder man selv skal bruge ved at
> skrive til kunden at der var en fejl og at han skal sende en kode
> mere (nemlig den som banken beder om når man laver sine egne
> transaktioner).

Jeps

>>Som Troels dog påpeger, så er sikkerheden i webbanker i høj grad
>>baseret på, at det er svært at "stjæle" penge fra en webbank, da du jo
>>skal fortælle banken, hvor pengene skal overføres til.
>
> Det er klart, men hvor stort et problem er det at oprette en
> konto i en fjern by under falsk navn og cpr-nummer og så hæve
> pengene i en ruf når de er overført?
> Tjekker banken med folkeregistret?

Det ved jeg faktisk ikke. Da jeg oprettede en konto i en ren webbank
skulle jeg udfylde en formular med CPR-nummer og adresse, men det navn
min bank "tror" jeg har er ikke _præcist_ det navn, der er registreret i
folkeregistret (der er en "stavefejl" i det navn de skriver på de
papirer, de sender til mig).

Det kan godt være, at det reelt er en ubetydelig opgave at oprette en
konto i en andens navn, hvis man kan opsnappe den fysiske post, der
sendes til vedkommende.

--
Jesper Stocholm http://stocholm.dk

Programmer's code comment:
//It probably makes more sense when you're stoned.

---

Jesper Stocholm skrev:

>Ja, det benægter jeg heller ikke. Min pointe er "blot", at løsningen med
>engangsnøgler ikke nødvendigvis giver en _sikker_ løsning.

Korrekt. Imidlertid står problemet med at bryde den sikkerhed
slet ikke mål med det forventede udbytte. Derfor er sikkerheden
god (hvilket du heller ikke har benægtet).

>Det kan godt være, at det reelt er en ubetydelig opgave at oprette en
>konto i en andens navn, hvis man kan opsnappe den fysiske post, der
>sendes til vedkommende.

Man skal have is i maven, men det er reelt ikke svært. Det var
det i hvert fald ikke for ham der belemrede en uskyldig fyr med
en gæld på 2 mio.

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

---

Bertel Lund Hansen <nospamius@lundhansen.dk> wrote:

>> Det kan godt være, at det reelt er en ubetydelig opgave at oprette
>> en konto i en andens navn, hvis man kan opsnappe den fysiske post,
>> der sendes til vedkommende.
>
> Man skal have is i maven, men det er reelt ikke svært. Det var
> det i hvert fald ikke for ham der belemrede en uskyldig fyr med
> en gæld på 2 mio.

Er du sikker på det? Hos Skandiabanken (en netbank) skal man indsende en
kopi af gyldig billedlegitimation for at oprette en konto. Jeg vil tro,
at det er et generelt krav hos alle banker i dag. Efter de nuværende
regler har bankerne pligt til at checke identiteten på de personer, som
opretter en konto (bl.a. af hensyn til hvidvaskning af penge,
organiseret kriminalitet og terrorbekæmpelse).

Det er muligt, at det er nemmere at låne penge i et finansieringsselskab
i en anden persons navn, men det er ikke det samme som en bankkonto.

--
Jesper Lund

---

Jesper Lund skrev:

>> Man skal have is i maven, men det er reelt ikke svært. Det var
>> det i hvert fald ikke for ham der belemrede en uskyldig fyr med
>> en gæld på 2 mio.

>Er du sikker på det?

Det kommer an på hvad man kalder nemt. Han skaffede sig pas,
kørekort, sygesikringsbevis og dankort. Alle billeder var af ham
selv. Navn, adresse og cpr-nummer var på den udnyttede gut.
Posten blev omadresseret - formodentlig til en postboks, men det
husker jeg ikke.

Og så gik han ellers i gang med at låne, hæve og indkøbe stort på
kridt.

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

---

Bertel Lund Hansen <nospamius@lundhansen.dk> wrote:

> Det kommer an på hvad man kalder nemt. Han skaffede sig pas,
> kørekort, sygesikringsbevis og dankort. Alle billeder var af ham
> selv. Navn, adresse og cpr-nummer var på den udnyttede gut.

Ok; den slags tror jeg ikke at bankerne m.v. garderer sig mod (hvordan
skulle de næsten det?). Men det må betragtes som et gevaldigt
sikkerhedshul i de offentlige systemer.

--
Jesper Lund

---

Jesper Lund skrev:

>skulle de næsten det?). Men det må betragtes som et gevaldigt
>sikkerhedshul i de offentlige systemer.

.... blandt det offentlige personale. Jeg tror det var tv der
bagefter prøvede at lave ham kunsten efter, og de kunne lokke
alle mulige oplysninger ud af folk der burde vide bedre.

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

---

"Jesper Stocholm" <j@stocholm.invalid> wrote in message
news:Xns950777B5718F2stocholmdk@130.225.247.90...
> Bertel Lund Hansen wrote:
>
> > Jesper Stocholm skrev:

> Ja, det benægter jeg heller ikke. Min pointe er "blot", at løsningen med
> engangsnøgler ikke nødvendigvis giver en _sikker_ løsning. Den giver en
> /sikrere/ løsning, hvilket er noget andet end indholdet i indlægget jeg
> svarede på - som jeg læser det, i hvert fald :)


/Sikrere/ i forhold til /ingen/ sikkerhed kan ikke sammenlignes.

Men jeg menere ikke det er nok at opsnappe kommunikationen som andre
skriver. Beder den om en ekstra nøgle så stopper man, så ved man jo der er
noget galt.

Løsningen benytter et javaprogram, der dels uploades hver gang, dels skal
kunne identificere sig selv over for banken. Der må nødvendigvis være tale
om at bryde en kryptering og uden at kende bankens løsning på dette punkt så
findes idag krypteringer, der ikke kan brydes på den tid jeg er forbundet
til banken. Sikkerheden ligger så er i om man kan få fat i algoritmen og
bankens nøgler og det er jo noget andet.



Men hele emnet startede med, at _adgang_ til en maskine _alene_ er nok,
hvor man baserer sig på de løsninger der benytter filer og et kodeord.

---

TDC wrote:

> "Jesper Stocholm" <j@stocholm.invalid> wrote in message
>
>> Ja, det benægter jeg heller ikke. Min pointe er "blot", at løsningen
>> med engangsnøgler ikke nødvendigvis giver en _sikker_ løsning. Den
>> giver en /sikrere/ løsning, hvilket er noget andet end indholdet i
>> indlægget jeg svarede på - som jeg læser det, i hvert fald :)
>
> /Sikrere/ i forhold til /ingen/ sikkerhed kan ikke sammenlignes.
>
> Men jeg menere ikke det er nok at opsnappe kommunikationen som andre
> skriver. Beder den om en ekstra nøgle så stopper man, så ved man jo
> der er noget galt.

Hvordan ved man det? Du skal jo bruge to nøgler for at 1) logge ind og 2)
gennemføre transaktionen. Pointen er at det for dig ser ud, som om intet er
galt - men banken modtager aldrig noget fra dig, før nøglerne er blevet
opsnappet og bruges til en "ond" transaktion.

> Løsningen benytter et javaprogram, der dels uploades hver gang, dels
> skal kunne identificere sig selv over for banken.

Igen - banken ser ikke nødvendigvis noget før nøglerne er opsnappet.

> Der må nødvendigvis
> være tale om at bryde en kryptering

Nej

> og uden at kende bankens løsning
> på dette punkt så findes idag krypteringer, der ikke kan brydes på den
> tid jeg er forbundet til banken. Sikkerheden ligger så er i om man kan
> få fat i algoritmen og bankens nøgler og det er jo noget andet.

Ja, det er noget helt andet - og det kan slet ikke bruges som
sammeligningsgrundlag.

--
Jesper Stocholm http://stocholm.dk

Programmer's code comment:
//It probably makes more sense when you're stoned.

---

"Jesper Stocholm" <j@stocholm.invalid> wrote in message
news:Xns9507886D568FCstocholmdk@130.225.247.90...
> TDC wrote:
[klip]
>
> Igen - banken ser ikke nødvendigvis noget før nøglerne er opsnappet.
>
Kodeord sendes aldrig over nettet og kan derfor ikke opsnappes, med mindre
man kender bankens egen kryptering (det er ikke SSL)

Banken er den eneste, der kan bede om den rigtige nøgle. Andre kan bede om
en nøgle, men den kan ikke bruges til en _anden_ transaktion.
Så tilbage er måske om man kan forfalske den aktuelle transaktion, jeg selv
laver ved at sende et andet beløb og kontonummer end dem jeg angiver - uden
at man opdater det, f.eks. ved at kigge på kontoudtoget.


> > Der må nødvendigvis
> > være tale om at bryde en kryptering
>
> Nej
>

---

TDC wrote:

>> Igen - banken ser ikke nødvendigvis noget før nøglerne er
>> opsnappet.
>>
> Kodeord sendes aldrig over nettet og kan derfor ikke opsnappes,
> med mindre man kender bankens egen kryptering (det er ikke SSL)

Det er ikke så vandtæt som du tror. Har en angriber fuld kontrol over
klienten, er der flere muligheder for at skyde noget ind i laget mellem
brugeren og banken. Det er ikke nødvendigvis let, men det er heller
ikke umuligt, af den simple grund at der allerede findes en klient
(et stykke software) på klienten (brugerens PC) der kan kommunikere med
banken.

Læs evt. tilbage i gruppen. Vi har haft diskussionen oppe i gruppen for
relativt nylig.

--
Niels Callesøe - dk pfy
pfy[at]nntp.dk - http://www.pcpower.dk/disclaimer.php

På det digitale natbord: Applied Cryptography, Menezes et al. 1996-2001

---

TDC wrote:
>
> "Jesper Stocholm" <j@stocholm.invalid> wrote in message
> news:Xns950777B5718F2stocholmdk@130.225.247.90...
> > Bertel Lund Hansen wrote:
> >
> > > Jesper Stocholm skrev:
>
> > Ja, det benægter jeg heller ikke. Min pointe er "blot", at løsningen med
> > engangsnøgler ikke nødvendigvis giver en _sikker_ løsning. Den giver en
> > /sikrere/ løsning, hvilket er noget andet end indholdet i indlægget jeg
> > svarede på - som jeg læser det, i hvert fald :)
>
> /Sikrere/ i forhold til /ingen/ sikkerhed kan ikke sammenlignes.
>
> Men jeg menere ikke det er nok at opsnappe kommunikationen som andre
> skriver. Beder den om en ekstra nøgle så stopper man, så ved man jo der er
> noget galt.

Man kan da bare få det til at se ud som om brugeren har
tastet forkert, og derfor er nødt til at prøve igen.

>
> Løsningen benytter et javaprogram, der dels uploades hver gang, dels skal
> kunne identificere sig selv over for banken.

Er det ikke Jyske Banks system vi taler om? I så fald
kan jeg oplyse, at det kan bruges i en browser uden java.

> Der må nødvendigvis være tale om at bryde en kryptering

Det er ikke nødvendigt, hvis man kan komme til at fuske
lidt med browseren på brugerens computer. Og det er i
princippet lige så nemt som at installere en keylogger.

> og uden at kende bankens løsning på dette punkt så
> findes idag krypteringer, der ikke kan brydes på den tid jeg er forbundet
> til banken. Sikkerheden ligger så er i om man kan få fat i algoritmen og
> bankens nøgler og det er jo noget andet.

Så vidt jeg kan se er dete hele baseret på SSL, så der
er ikke noget hemmeligt i det. Men det er jo ikke huller
i SSL vi diskuterer. Hvis du har kontrol over klienten
giver SSL ingen sikkerhed.

>
> Men hele emnet startede med, at _adgang_ til en maskine _alene_ er nok,
> hvor man baserer sig på de løsninger der benytter filer og et kodeord.

Ja men adgang til maskinen giver mange flere
muligheder end du ser ud til at have fantasi til at
forestille dig. Selv Jyske Banks system kan man
misbruge hvis man har kontrol over klienten og er
målrettet nok.

--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use kasperd@kd.lir.dk and abuse@kd.lir.dk
I'd rather be a hammer than a nail.

---

In article <40cc3440$0$296$edfadb0f@dread12.news.tele.dk>, TDC wrote:
> Men jeg menere ikke det er nok at opsnappe kommunikationen som andre
> skriver. Beder den om en ekstra nøgle så stopper man, så ved man jo der er
> noget galt.

Du kan evt. også angribe det på et højere lag, fx på præsentationslaget.

Lav en grænseflade der ligner bankens, så kan du lokke alt ud af brugeren.

> Men hele emnet startede med, at _adgang_ til en maskine _alene_ er nok,
> hvor man baserer sig på de løsninger der benytter filer og et kodeord.

Dette er selvfølgelig muligt hvis du har magten over brugeren maskine.

--
Mvh.
Christian E. Lysel
http://www.spindelnet.dk/

---

"TDC" <x.spam@get2net.dk> writes:

>Jyske Bank har altid har en tilsyneladende sikker løsning: selv om der
>ligger en sniffer på computeren som så kan få adgang til banken, kan den
>ikke udføre transaktioner, fordi hver transaktion behøver ny
>information/nøgle fra nøglekortet.

Den løsning har et andet hul: kan du få en garanti fra Post
Danmark på, at ingen medarbejder nogensinde vil se sit snit
til at lure koderne i en brev?

Teoretisk set kunne en løsning baseret på (temmeligt mange)
fysiske personer vise sig at være MEGET mere risikabel end
en ren maskinær løsning.

Mvh.
   Klaus.

---

Klaus Ellegaard uttered:
> Den løsning har et andet hul: kan du få en garanti fra Post
> Danmark på, at ingen medarbejder nogensinde vil se sit snit
> til at lure koderne i en brev?

OT: Det dummeste jeg har set som postbud var en nu hedengangen bank, der
til en kunde på min rute sendte to breve, der ankom samme dag. Det ene
indeholdt et plastikkort, det andet var "se-igennem-sikret", hvilket vil
sige at det med al sandsynlighed var det brev med pinkode, der skulle
have været sendt en uge forinden for at sikre at begge dele ikke falder
i postbudets hænder...

Kort tid efter dette indførte min egen bank i øvrigt aktivering af nye
dankort, så det ikke bare var nok at få fat i et nyt kort og pinkoden.

\\kristian
--
http://lpf.ai.mit.edu/Patents/knuth-to-pto.txt

---

Klaus Ellegaard skrev:

>Den løsning har et andet hul: kan du få en garanti fra Post
>Danmark på, at ingen medarbejder nogensinde vil se sit snit
>til at lure koderne i en brev?

Derudover skal han lure kundens personnummer og kundens
personlige kodeord hvis han skal misbruge systemet.

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

---

In article <40cb6a22$0$198$edfadb0f@dread12.news.tele.dk>, TDC wrote:
> Hej,
>
> Er der nogen sikkerhed baseret på en fil på computeren og et koderord, der
> sjældent skiftes?

Du er ikke tvunget til at placere den på en maskines harddisk, du
er ej tvunget til at beskytte den med et password...de fleste
implementationer har dog valgt dette.

> Hvis man kan fjernbetjene maskinen og aflure kodeord er der vel ingen
> sikkerhed. Og dvs sikkerheden ligger uden for.

Der er flere hvis'er:

http://www.schneier.com/paper-pki-ft.txt

--
Mvh.
Christian E. Lysel
http://www.spindelnet.dk/

---

On Sat, 12 Jun 2004 22:40:39 +0200, TDC wrote:

> Hvis man kan fjernbetjene maskinen og aflure kodeord er der vel ingen
> sikkerhed. Og dvs sikkerheden ligger uden for.

Enig. Med den slags løsninger, består den største sikkerhedsfaktor
måske i virkeligheden i, at det er forbandet svært at gennemføre et
tyveri via netbanker: Penge-bevægelserne logges jo, så hvordan skal
tyven få udbyttet omsat til brugbare midler uden at afsløre sig selv?

Derfor er jeg fan af Jyske Banks system med éngangskoder som supplement
til login+password. Jeg mener at have læst, at visse andre banker så
småt er begyndt at tilbyde lignende løsninger.

Men kunne også forestille sig gode løsninger, hvor éngangskoder sendtes
over SMS, i stedet for - som ved Jyske Banks' system - på papir. Ulempen
ville dog være, at man da skulle have sin mobiltelefon i nærheden (og
opladt, og inden for mobildækning, osv.) for at kunne foretage
transaktioner.

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

On Sat, 12 Jun 2004 22:40:39 +0200, TDC wrote:

> Hvis man kan fjernbetjene maskinen og aflure kodeord er der vel ingen
> sikkerhed. Og dvs sikkerheden ligger uden for.

Enig. Med den slags løsninger, består den største sikkerhedsfaktor
måske i virkeligheden i, at det er forbandet svært at gennemføre et
tyveri via netbanker: Penge-bevægelserne logges jo, så hvordan skal
tyven få udbyttet omsat til brugbare midler uden at afsløre sig selv?

Undertegnede er fan af Jyske Banks system med éngangskoder som supplement
til login+password. Jeg mener at have læst, at visse andre banker så
småt er begyndt at tilbyde lignende løsninger.

Men kunne også forestille sig gode løsninger, hvor éngangskoder sendtes
over SMS, i stedet for - som ved Jyske Banks' system - på papir. Ulempen
ville dog være, at man da skulle have sin mobiltelefon i nærheden (og
opladt, og inden for mobildækning, osv.) for at kunne foretage
transaktioner.

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

Troels Arvin uttered:
> Undertegnede er fan af Jyske Banks system med éngangskoder som supplement
> til login+password. Jeg mener at have læst, at visse andre banker så
> småt er begyndt at tilbyde lignende løsninger.

Danske Bank er negyndt at understøtte Mac, hvor man så skal bestille en
af de her:
http://www.danskebank.dk/Link/PrivatHembankenInstruktionNyKodbox

Jeg overvejer lidt at prøve om det vil køre under Linux, men de vil have
et kvart tusinde kroner for den lille lommeregner...

\\kristian
--
http://lpf.ai.mit.edu/Patents/knuth-to-pto.txt

---

Kristian Thy skrev:

>Danske Bank er negyndt at understøtte Mac, hvor man så skal bestille en
>af de her:
>http://www.danskebank.dk/Link/PrivatHembankenInstruktionNyKodbox

Jeg forstår ikke hvordan banken kan vide at koden er korrekt
medmindre det er som ved f.eks. Microsofts koder at der er en
familie af koder der accepterers, og aktivkortet blot finder én
af dem. I så fald er sikkerheden jo dårligere end de 8 cifre
lader formode. Eller har jeg misforstået noget?

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

---

Bertel Lund Hansen wrote:

>>Danske Bank er negyndt at understøtte Mac, hvor man så skal
>>bestille en af de her:
>>http://www.danskebank.dk/Link/PrivatHembankenInstruktionNyKodbox
>
> Jeg forstår ikke hvordan banken kan vide at koden er korrekt
> medmindre det er som ved f.eks. Microsofts koder at der er en
> familie af koder der accepterers, og aktivkortet blot finder én
> af dem. I så fald er sikkerheden jo dårligere end de 8 cifre
> lader formode. Eller har jeg misforstået noget?

Jeg ved ikke med sikkerhed hvordan det virker. Men her er en mulighed:

Aktivkortet og banken kender en (faktisk to) hemmelige nøgler (bankens
pin der tilsendes, og en hemmelighed der er hardwired i kortet). De
kender også begge en algoritme der genererer nøgler ud fra disse to
hemmeligheder og klokken.

Når brugeren anmoder kortet om en nøgle, genererer det en ny, der er
tidsbegrænset til kun at virke i for eksempel en time. Brugeren
anvender koden, sammen med sin egen PIN, til at logge på banken. Banken
kan verificere den genererede kode, fordi banken kender de to hemmelige
nøgler.

Systemet er, hvis det er implementeret godt, Meget Sikkert. Sikkerheden
er på niveau med de engangskort vi har talt om tidligere, men det
kræver ikke tilsending af nye kort hele tiden.

--
Niels Callesøe - dk pfy
pfy[at]nntp.dk - http://www.pcpower.dk/disclaimer.php

På det digitale natbord: Applied Cryptography, Menezes et al. 1996-2001

---

"Bertel Lund Hansen" <nospamius@lundhansen.dk> skrev i en meddelelse
news:c16oc09phu9d36s7k54l4fkth4rehahubc@news.stofanet.dk...

> Jeg forstår ikke hvordan banken kan vide at koden er korrekt
> medmindre det er som ved f.eks. Microsofts koder at der er en
> familie af koder der accepterers, og aktivkortet blot finder én
> af dem. I så fald er sikkerheden jo dårligere end de 8 cifre
> lader formode. Eller har jeg misforstået noget?

Det kunne være implementeret på denne måde.

Vi har disse kendte værdier:

N - En "challenge" værdi fra banksystemet
P - Brugerens PIN kode
K - En fælles nøgle der er implementeret i kortet, og i banksystemet

Brugeren indtaster så challenge værdien samt PIN koden i sit kort ({P, N}.
Kortet returnerer derefter en værdi, der består af {P, N} krypteret under
den fælles nøgle K. Denne værdi sendes tilbage serveren, som selvsagt kan
beregne samme værdi og sammenligne dem. Den fælles nøgle kan være en en-vejs
krypteringsfunktion (hash-funktion) så P ikke medsendes i nettrafikken.

Dette eksempel er hentet fra Ross Andersons "Security Engineering".

Lars

---

Hej,

Men hvis der kun skal bruges koder ved login og ikke ved transaktionerne
hægter dæmonen sig på efter login og har frit spil.
Lommeregneren dur ikke alene?


"Lars Hansen" <lh@nospam.com> wrote in message
news:lrVyc.17467283$Of.2901574@news.easynews.com...
>
> "Bertel Lund Hansen" <nospamius@lundhansen.dk> skrev i en meddelelse
> news:c16oc09phu9d36s7k54l4fkth4rehahubc@news.stofanet.dk...
>
> > Jeg forstår ikke hvordan banken kan vide at koden er korrekt
> > medmindre det er som ved f.eks. Microsofts koder at der er en
> > familie af koder der accepterers, og aktivkortet blot finder én
> > af dem. I så fald er sikkerheden jo dårligere end de 8 cifre
> > lader formode. Eller har jeg misforstået noget?
>
> Det kunne være implementeret på denne måde.
>
> Vi har disse kendte værdier:
>
> N - En "challenge" værdi fra banksystemet
> P - Brugerens PIN kode
> K - En fælles nøgle der er implementeret i kortet, og i banksystemet
>
> Brugeren indtaster så challenge værdien samt PIN koden i sit kort ({P, N}.
> Kortet returnerer derefter en værdi, der består af {P, N} krypteret under
> den fælles nøgle K. Denne værdi sendes tilbage serveren, som selvsagt kan
> beregne samme værdi og sammenligne dem. Den fælles nøgle kan være en
en-vejs
> krypteringsfunktion (hash-funktion) så P ikke medsendes i nettrafikken.
>
> Dette eksempel er hentet fra Ross Andersons "Security Engineering".
>
> Lars
>
>

---

"TDC" <x.spam@get2net.dk> skrev i en meddelelse
news:40cc34be$0$227$edfadb0f@dread12.news.tele.dk...
> Hej,
>
> Men hvis der kun skal bruges koder ved login og ikke ved transaktionerne
> hægter dæmonen sig på efter login og har frit spil.
> Lommeregneren dur ikke alene?
>

Det er sådan set korrekt. Når man kigger på Danske Bank siden så lader de
umiddelbart til at man kun anvender lommeregneren ved login. Jeg ved at man
i BG-banks system skal taste sin kode hver gang man laver en transaktion (og
her taler vi godt nok om den statiske kode). Jeg ville faktisk være en smule
forbløffet om ikke der var implementeret en ligenende funktion i DBs system,
også selv om der er tale om dynamiske passwords. Danske Bank og BG Bank er
jo trods alt i samme koncern og kører på samme IT-platform.

Jeg synes at den informationsside hos Danske Bank der bliver linket til er
mig en kende for marketingagtig. Er der nogen der rent faktisk har prøvet
systemet, og som ved om man skal indtaste et password ved hver transaktion?

Lars

---

Lars Hansen wrote:

>> Men hvis der kun skal bruges koder ved login og ikke ved
>> transaktionerne hægter dæmonen sig på efter login og har frit
>> spil. Lommeregneren dur ikke alene?
>>
>
> Det er sådan set korrekt. Når man kigger på Danske Bank siden så
> lader de umiddelbart til at man kun anvender lommeregneren ved
> login.

Hvis man nærlæser, fremgår det faktisk at "lommeregneren" kan lave to
slags koder. Loginkoder og transaktionskoder. Ved transaktionskoder
bruges challenge/response.

--
Niels Callesøe - dk pfy
pfy[at]nntp.dk - http://www.pcpower.dk/disclaimer.php

På det digitale natbord: Applied Cryptography, Menezes et al. 1996-2001

---

"Niels Callesøe" <pfy@nntp.dk> skrev i en meddelelse
news:Xns95078FC8EB806k5j6h4jk3@62.243.74.163...
>>
> Hvis man nærlæser, fremgår det faktisk at "lommeregneren" kan lave to
> slags koder. Loginkoder og transaktionskoder.

Du har faktiskret. Der er dels tale om adgangskode, og dels acceptkode,
hvilket må formodes at være en kode til at acceptere transaktioner.Det er
dog ikke beskrevet når så klart som hos Jyske Bank.

> Ved transaktionskoder bruges challenge/response.

Der mener vel at der bruges challenge/response til både adgangskoder og
acceptkoder, ikke?

Men ud fra vores viden om konceptet, så burde Jyske Banks og Danske Banks
systemer være "lige sikre" [tm]. Rent praktisk er det selvfølgelig et
spørgsmål om implementeringen er foregået lige godt i begge systemer.
Djævlen ligger som bekendt altid i detaljen.

Lars

---

Lars Hansen wrote:

>> Ved transaktionskoder bruges challenge/response.
>
> Der mener vel at der bruges challenge/response til både
> adgangskoder og acceptkoder, ikke?

Nej. Nærlæsning viser at der kun bruges c/r til "acceptkoder". Men det
er heller ikke nødvendigt for at have en god sikkerhed (omend det alt
andet lige er endnu bedre). Se mit svar til Bertel for en måde hvorpå
det kan fungere uden c/r.

> Men ud fra vores viden om konceptet, så burde Jyske Banks og
> Danske Banks systemer være "lige sikre" [tm]. Rent praktisk er det
> selvfølgelig et spørgsmål om implementeringen er foregået lige
> godt i begge systemer. Djævlen ligger som bekendt altid i
> detaljen.

Deri er vi ganske enige. Begge systemer virker meget sikre, såfremt de
er korrekt implementerede.

--
Niels Callesøe - dk pfy
pfy[at]nntp.dk - http://www.pcpower.dk/disclaimer.php

På det digitale natbord: Applied Cryptography, Menezes et al. 1996-2001

---

"Niels Callesøe" <pfy@nntp.dk> skrev i en meddelelse
news:Xns9507A536352D0k5j6h4jk3@62.243.74.163...

> >
> > Der mener vel at der bruges challenge/response til både
> > adgangskoder og acceptkoder, ikke?
>
> Nej. Nærlæsning viser at der kun bruges c/r til "acceptkoder".

Efter at have pudset brillerne og læst det igen er jeg enig med dig.

Lars

---

Lars Hansen uttered:
> Jeg ved at man i BG-banks system skal taste sin kode hver gang man
> laver en transaktion (og her taler vi godt nok om den statiske kode).

Det er det samme hos DDB.

\\kristian
--
http://lpf.ai.mit.edu/Patents/knuth-to-pto.txt

---

On 13 Jun 2004 14:40:25 GMT, Kristian Thy <thy@it.edu> wrote:

>> Jeg ved at man i BG-banks system [...]

> Det er det samme hos DDB.

Det er ikke så overraskende, da det er samme firma, blot to
forskellige 'brands'. (De hedder i øvrigt ikke "Den" mere).

-A
--
http://www.hojmark.org/

---

Asbjorn Hojmark uttered:
>> Det er det samme hos DDB.
>
> Det er ikke så overraskende, da det er samme firma, blot to
> forskellige 'brands'. (De hedder i øvrigt ikke "Den" mere).

Der er dog mange advokater og ejendomsmæglere der stadig bruger DDB (ja,
jeg har lige købt lejlighed :) ). Og så er DB jo Deutsche Bundesbahn...

\\kristian
--
http://lpf.ai.mit.edu/Patents/knuth-to-pto.txt

---

Kristian Thy uttered:
> Og så er DB jo Deutsche Bundesbahn...

(Flot Kristian, det har heddet Deutsche Bahn de sidste knap 15 år...)

---

TDC wrote:

> Er der nogen sikkerhed baseret på en fil på computeren og et koderord, der
> sjældent skiftes?

Ja, det kaldes to-faktor validering og kendes blandt andet fra dankortet
hvor man har nogle data paa kortet og en PIN kode der aldrig skiftes.

> Hvis man kan fjernbetjene maskinen og aflure kodeord er der vel ingen
> sikkerhed. Og dvs sikkerheden ligger uden for.

Jeg ved ikke hvad du mener med den sidste saetning, men den forgaaende
er korrekt.

Hvis man lader sin PC blive inficeret med en orm eller spyware, og blot
bruger et removal tool til at fjerne det (naar der i teorien kan vaere
alt muligt andet software der har listet sig ind ad samme vej),
udsaetter man sin bankadgang og kreditkort (og alt andet paa ens PC) for
det som svarer til, at udlevere dankort og pinkode til en tilfaeldig paa
gaden.

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.mongers.org

OSS/FAQ for dk.edb.sikkerhed: http://sikkerhed-faq.dk