Esettanulmányok elektronikus kereskedelmi rendszerekről

Esettanulmányok elektronikus kereskedelmi rendszerekről Avagy kire és mire bízzuk a pénzünket? Csoma Péter, Nagy Gábor, Pozsonyi Tamás, Szamos Attila, Szili Dávid A biztonságos elektronikus kereskedelem alapjai tárgy Kiselőadása 2 Miről lesz szó? Bevezetés, ismétlés Régitől az új felé, elmélettől a gyakorlat felé Szili Dávid - Egy bizonyíthatóan biztonságos követhetetlen fizetési rendszer feltörése Nagy Gábor Még egy bizonyíthatóan biztonságos rendszer feltörése Csoma Péter Együttműködésen alapuló támadás egy fizetési protokoll ellen Pozsonyi Tamás - Támadások a SET protokollon Szamos Attila - Person-to-Person fizetési rendszerek biztonsága: PayPal Összefoglalás, konklúzió

3 Bevezetés, ismétlés: Elektronikus fizetési rendszerek alapvető osztályozása on-line vagy off-line on-line: egy bank (harmadik fél) valós időben is részt vesz a tranzakcióban off-line: a bank nem vesz részt valós időben a tranzakcióban pre-paid, pay-now, pay-later pre-paid: a vásárló a tranzakció előtt fizet pay-now: a vásárló számláját ellenőrzik, és a terhelést a tranzakcióval együtt hajtják végre pay-later (credit-based): a vásárló a tranzakció után fizet 4 Bevezetés, ismétlés: Általános biztonsági követelmények Felhatalmazás A fizetés mindig a vásárló felhatalmazásával történjen A vásárló hitelesítését igényli A fizetést a banknak is jóvá kell hagyni Adatok bizalmassága, hitelessége A tranzakció adatai sértetlenek és hitelesek Bizonyos adatok rejtettek némely résztvevő előtt A kereskedőnek nem kell tudni a vevő számlaadatairól A banknak nem kell tudni, mit vásárolt a vevő

5 Bevezetés, ismétlés: További követelmények Tranzakciók atomicitása Vagy a teljes tranzakció végrehajtódik, vagy a rendszer állapota nem változik Gyakorlatban a tranzakciók megszakadhatnak Lehetséges kell legyen a megszakadások detektálása és helyreállítása Privátszféra (anonimitás és követhetetlenség) A vásárlóknak képesnek kell lenni kontrollálni, hogy a többi fél hogyan használhatja fel személyes adatait Néha a legegyszerűbb megvalósítása ennek, ha elrejtjük a személyes adatokat Anonimitás: a vevő elrejti kilétét a kereskedő elől Követhetetlenség: a bank sem képes nyomon követni, hogy a vásárló mely tranzakcióknak résztvevője 6 Bevezetés, ismétlés: Bankkártya alapú rendszer Koncepció: A bankkártyák manapság nagyon népszerűek Amennyire lehet, a hagyományos bankkártya infrastruktúrát használja Bankkártya számok biztonságos átvitele az Interneten Példák: SSL (általános) SET (szabvány)

7 Bevezetés, ismétlés: Elektronikus pénz Koncepció: Az emberek kedvelik a kézpénzt Az elektronikus pénz sok, a kézpénzhez hasonló tulajdonsággal rendelkezik Biztosítható a tranzakció követhetetlensége Példák: DigiCash (on-line) CAFE (off-line) 8 Egy bizonyíthatóan biztonságos követhetetlen fizetési rendszer feltörése Szili Dávid

9 A feltört rendszerről Damgård Crypto 88 konferencián publikált rendszere Pfitzmann és Wainder törte fel A rendszer jellemzői: On-line, Fix accountok, Feltétel nélküli követhetetlenség (kereskedőnek nem), Feltétel nélküli összeköthetetlenség, Csalásokkal szembeni védelem (bank felől nem) 10 Alapötlet Alapötlet: RSA helyett bizonyíthatóan biztonságos aláírás Többszereplős számításon alapul (aláírás a kliens és a bank együttműködésében) Nem létezik olyan transzformáció, mely egy érvényes aláírást egy másikba vinne át Többszereplős számítás (Multiparty Computation): Több szereplő, privát inputokkal Minden szereplő szeretne közösen kiszámítani egy függvényt Két szereplőre így: P 1 -nek és P 2 -nek inputjai x és y P 1 és P 2 szeretné megkapni f(x,y)-t

11 Néhány alapfogalom Claw-free függvénypár, Blum-egész, Trapdoor Röviden: Egy (f 0,f 1 ) claw-free trapdoor párral A elkötelezheti magát egy b {0,1} bit mellett Választ egy x Im(f b ) és kiszámítja az f b (x)-et, ehhez jön hozzá a bank titkos kulcsa, és így lesz aláírva a pénz Később felnyithatja x felfedésével, így bizonyíthatja, hogy mely bithez kötelezte el magát Eredmény: Külső támadó nem képes felfedni b értékét Csak egyféleképpen lehet felfedni az elkötelezettségét 12 A protokoll működése Pénzkivétel A kliens (A) választ egy R véletlen számot (sorszám) A aláírást kér a B-től az R értékre (Kétszereplős számítás: A privát inputja R, B privát inputja az SK titkos kulcsa) A számítás eredménye a B aláírása (Sig) R-en (amit B nem ismer, így az aláírást csak A tudja felnyitni) B levonja az összeget A számlájáról Fizetés (pénz beváltása) Amikor A el akarja költeni a pénzt a boltban (S), akkor odaadja R-t, és Sig-et. S elküldi ezeket B-nek B ellenőrzi, hogy R-t kiállította-e korábban (listából) Ha igen, akkor S számlájára írja az összeget, és értesíti S-t a fizetés elfogadásáról

13 Problémák és javításuk 1. Rosszul definiált kritériumok: Követhetetlenség itt: pénzkivételnél shanoni értelemben nem szivárog ki információ a bank által aláírt R számról az R szám mellett, a Sig aláírást is felmutatja a vevő a beváltáskor Bizonyíthatóan biztonságos aláíró sémákban az aláíró bemenete általában nem csak a kulcs (a séma nem memóriamentes) A memóriával rendelkező aláírás sémák alkalmatlanok vak aláírásra Javítás1: Követhetetlenség definíciójának bővítése: a bank semmilyen információt nem tudhat az aláírásról! Pénzbeváltás során az aláírást nem mutatják meg: a vásárló zeroknowledge módon bizonyítja, hogy rendelkezik vele Javítás2: Memóriamentes feltétel nélkül biztonságos aláírás séma 14 Problémák és javításuk 2. Csalás a pénzbeváltásnál: A bank által elkövetett csalások ellen semmi védelem nincs A bank bármikor azt állíthatja, hogy egy adott pénzt már korábban beváltottak Javítás: Pénzkivétel előtt A választ egy (PK, SK) párt magának, ahol PK lesz a pénz sorszáma Vásárláskor A az üzenet SK-val írja alá S az értesítésben a számlaszámát is megkapja Vita esetén egy bíró előtt ellenőrizhető: A megismétli a zero-knowledge bizonyítást, hogy a bank aláírása megvan a pénzen A bíró ellenőrzi, hogy B is megvan erről győződve S újra megkapja a pénzbeváltást elismerő üzenetet (ha már elköltötték A és S próbál csalni akkor ez nem növel a számlán)

15 Problémák és javításuk 3. Csalás a pénzkivételnél : A bank által elkövetett csalások ellen semmi védelem nincs A bank állíthatja azt is pénzkivétel során, hogy a kliensnek nincs több pénz a számláján Javítás: Itt a kivétel egy többszereplős számítás eredménye Minden kivételnél mind a kliens, mind a bank aláír Vita esetén minden pénzkivétel rekonstruálható (pl. egy bíró előtt) 16 Tanulságok: Hiányos definíciók Megkövetelt tulajdonságok nem teljesülnek Rossz követelményrendszer Elvárható tulajdonságok hiánya

17 Még egy bizonyíthatóan biztonságos rendszer feltörése Nagy Gábor 18 Definíciók Unforgeability (hamisíthatatlanság): k kivétele után k + 1 kiszámolása ne lehessen lehetséges Untraceability (követhetetlenség): anonim felhasználás No double-spending (többszörösköltés mentes): egy felhasználó csak egyszer költhesse el az érmét No framing (megvádolhatatlanság): felhasználót ne lehessen megvádolni rosszindulatú felhasználással Transferability (átadhatóság): az ügyfelek egymás között is használhassák Divisibility (feloszhatóság): kisebb egységekre lehessen osztani

19 A követhetetlenség definíciójának gyengesége Nyomon követhető az elfogadó, mivel feltételezzük, hogy csak a kivételek és befizetések megfigyelhetőek Általában a fizetések is megfigyelhetőek A többszörös elköltés ellen szükséges, hogy minden kedvezményezett azonosíthassa a megfelelő fizetőt Az alacsonyabb szintű anonimitás elfogadhatatlan több okból: 1. a szokásos értelemben kell a követhetetlenség, különben szövetkezhetnének a bankok és az ez elfogadók 2.gyakorlatban ugyanannyira fontos, hogy se a bank se a kedvezményezett ne tudja követni az érme mozgását 3.a megvalósított anonimitás elérhető sokkal könnyebben, mint itt megvalósították 20 Eurocrypt 94-en bemutatott rendszer I. A digitálispénz módszertana alapvető kriptográfiai alapokon Inicializálás: rendszer paraméterek, publikus kulcsok, aláírási séma, NIZKP minden felhasználónak van egy nyilvános kulcsa minden felhasználó végrehatja az NIZKP előfázisát a bankkal, ahol ő a bizonyító, és a bank az ellenőrző a bank ennek az eredményét, β-t publikálja ezt a kedvezményezett az ellenőrzéshez használja fel V 2 bemeneteként Kivétel: a felhasználó választ egy véletlen c azonosítót, erre kiszámolja a megjegyzést (com), és ezeket küldi a banknak a bank aláírja com-ot, és visszaküldi a felhasználónak com, β, és az aláírás segítségével generálja cp-t, és ezzel győzi meg az kedvezményezettet, hogy valódi az érme, mivel ismeri com-ot c-n és van érvényes aláírása a banktól

21 Eurocrypt 94-en bemutatott rendszer II. Fizetés: elküldi c-t és cp-t a elfogadónak, aki ezt β segítségével tudja ellenőrizni majd aláírja a (ID payee ; c) párt, és ezt is elküldi a kedvezményezettnek ez kell a többszöri felhasználás ellen (megkérdezhetik kié volt korábban az érme) az érme újra is felhasználható, és akár ki is vehető a bankból 22 Eurocrypt 94-en bemutatott rendszer III. Többszöri felhasználás detektálása: a bank kérheti A és B felhasználót, hogy adja meg c összes korábbi tulajdonosát az aláírás továbbítás segítségével ezt a kérést az összes résztvevő megkapja végül, valamelyik 1. X tulajdonos nem működik együtt, pl. nem adja meg a forrást, vagy 2. X felismerhetően kétszer használta c-t, vagy 3. ugyanannak a c-nek két kivétele történt első két esetben X a feltételezett támadó első esetben lehet elérhetetlenségi probléma is, vagy információ vesztés is második egy technikai probléma, amire később visszatérünk harmadik eset nem tekintett problémának

23 A rendszer gyenge pontjai I. Alapvető hiba a követhetetlenségben: A protokoll teljesen nem biztosítja az anonimitást Az érme lefoglalása esetén (c, cp)-t ellenőrzi a bank Ehhez szükséges az X felhasználó, aki felvette az érmét, mivel β kell V 2 - höz Mivel ez az elő feldolgozásnál jött létre, hozzáköthető a felhasználóhoz, tehát részben visszakövethető Alapvető baj az NIZKP-vel van, mivel az elő feldolgozásnál kétszemélyes protokoll Szükséges benne egy bizonyítás, ami azonosítja a két felet Így valós lenyomozhatatlanság nem érhető el, ha nyílt ez a primitív Ha a számla megnyitása előtt, anonim módon történik meg, akkor minden egy fizetőhöz köthető, tehát azonosíthatósághoz vezet Egyetlen ellenszer, ha minden érmére külön-külön történik meg, de az életképtelen a felhasználói szempontból 24 A rendszer gyenge pontjai II. Egy követhetetlenségi hiba a többször elköltésnél: ha többszörköltés merül fel, és a bank nem tudja bizonyítani, hogy egy érme kétszer lett elköltve, akkor a felhasználóknak ezt el kell hinniük így egy megbízhatatlan bank mindig kérheti, hogy a kedvezményezett azonosítsa a fizetőket, mivel c már másodjára lesz kivéve kell egy protokoll arra, hogy bebizonyítsuk nem hibás a vád, mielőtt érzékeny információkat adnak ki a felek

25 A rendszer gyengepontjai III. A többszörköltő hibás azonosítása A 1, A 2 támadó, H i megbízható H 1 lesz megvádolva, mivel A 1 nem árulja el A 2 -őt megoldásként finomítanunk kell a három szabályból a másodikat úgy, hogy ha X kétszer költi el, de nem fogadteel kétszer az érmét viszont további probléma, hogy aláírás csak az érmém van és a kedvezményezett személyazonosságán 26 A rendszer gyengepontjai IV. A továbbíthatóság a feloszthatatlansággal az érméket kisebb egységekre oszthatjuk, hogy kényelmesebb legyen elkölteni, ekkor a felosztást egy fában tároljuk. a részfát amit elköltünk azonosítani kell túl nagy a komplexitása, hogy ezt megvalósítsuk A gyenge követhetetlenség egyszerűbb módja mivel a kedvezményezett mindig ismeri a fizetőt, így nem kell NIZKP, hogy bizonyítsák c eredetiségét ehelyett továbbítsa a vásárló az összes kivétel során megkapott információt (c, com, r, aláírás com-on) ezt a kedvezményezett könnyen ellenőrizni tudja a számláról való leemeléskor, a kedvezményezet bizonyít egy aláírás ismertet a com-on, és egy közelítőleg zero-knowledge bizonyítást használ így a fenti privacy hibát is ki lehet küszöbölni

27 Tanulságok A definíciók három fő problémája nem korrekt definíciók nem teljes definíciók átfedés a nevek között 28 Együttműködésen alapuló támadás egy fizetési protokoll ellen Csoma Péter

29 Vizsgált protokoll tulajdonságai I. W. Wang publikálta az Asiacrypt 03-ban Csak szoftverek vásárlásánál alkalmazható, mert szükséges feltétel a termék plusz költség nélküli sokszorosíthatósága. Kombinálja az untracable offline e-coin technológiát RCSS-sel (Restrictive Confirmation Signature Scheme) 30 Vizsgált protokoll tulajdonságai II. Unforgeability: Csak U tudja előállítani a saját pszeudo e-coinját. Indistinguishability: U vagy a TTP segítsége nélkül senki nem tud különbséget tenni egy érvényes pszeudo e-coin és egy szimulált között Convertibility: Ha M elfogadja a pszeudo e-coint, akkor a TTP garantáltan képes azt valódi e-coinná konvertálni Fairness: Ha az előző három feltétel teljesül, akkor tranzakció végén a vásárlónak garantáltan birtokában lesz a szoftver, az eladónak pedig a pénz Untraceability: Csak M és TTP tudják ellenőrizni az aláírás hitelességét, így csak ők tudják, hogy az OA valódi Unlinkability: A bank vagy mások nem tudják az eredeti tulajdonoshoz kötni az érmét.

31 RCSS Restrictive Confirmation Signature Scheme Egy S által készített aláírás hitelességét C (Confirmer) tudja igazolni, és a hitelességről meg tudja győzni V-k (verifyer-ek) egy G halmazát. Jelölés: Sign RCSS (S;C;G;m) 32 Interactive Bi-Proof of Equality Két fél futtatja le Egyik résztvevő bizonyítja vele a másik számára, hogy adott (α; Y; β; Z) négyesre log α Y = log β Z teljesül-e vagy sem anélkül, hogy a logaritmusok értékét felfedné.

33 Résztvevők és eljárások Résztvevők: U Vásárló M Eladó B Bank TTP Megbízható harmadik fél Eljárások: Számla nyitása (account opening) Pénzt felvétele (withdrawal) Fizetés (payment) Kérdéses esetek megvitatása (dispute) Pénz elhelyezése a számlán (deposit) 34 Számlanyitás és pénzfelvétel Számla nyitása: U (vásárló) jelzi B (bank) felé, hogy számlát szeretne nyitni, az eljárás során megállapodnak a számlaszámban és egy közös titokban Pénz felvétele: A vásárló jelzi, hogy pénzt szeretne felvenni, a protokoll lefutása után rendelkezésére áll egy <A,B,(z, e 1, e 2, r, a c, b c )> pszeudo e-coin, melyet a bank aláírt és elfogad, de nem köthető a vásárló személyéhez a c, b c, re teljesül, hogy a c = g t c és bc = y ttp t c, ahol g és y ttp mindenki számára ismert értékek, (y ttp a megbízható harmadik fél nyilvános kulcsa), t c pedig egy U által véletlenszerűen választott szám

35 Fizetés U kiválasztja a terméket és aláírja a megrendelést: Θ = Sign RCSS (U,M,TTP,OA), ahol OA = {ID U,ID M, vásárlási információk, termék leírása, (A,B)} Elküldi Θ-t és <A,B,(z, e 1,e 2,r,a c,b c )>-t M-nek M ellenőrzi az e-coint és az aláírást. Ha mindegyik érvényes, akkor visszaküldi a d = H(A,B,ID M,dátum/idő) értéket U válasza a k 1 (= du 1 s+x 1 mod q) és k 2 (= ds + x 2 mod q) értékek. Lefuttatják az interaktív BP(g,a c,y TTP,b c ) protokollt, így M meggyőződik arról, hogy log g a c = log yttp b c Ha az alábbi egyenlőségek teljesülnek, M elküldi a terméket U-nak: g r = y b H(A,B,z,e1,e2,bc)+ ac e1 A r = z H(A,B,z,e1,e2,bc)+ac e 2 g 1 k1 g2 k2 = Ad B U ellenőrzi a terméket, és ha minden megfelelő, akkor elküldi M-nek t c -t 36 Vitás helyzet Ha a vásárló megkapja a terméket, de nem küldi el t c -t, akkor az eladó a megbízható harmadik félhez fordul, hogy hozzájusson a pénzéhez. Elküldi TTP-nek az e-coinból rendelkezésére álló részt (azaz mindent, kivéve t c -t), a megrendelési egyezséget (OA), annak aláírását (Θ), valamint magát az eladott szoftvert is. A TTP ellenőrzi, hogy minden adat helyénvaló-e (azaz a termék megfelel az OA-ban leírtaknak, és az érme és az aláírás érvényes) Ha igen, akkor elküldi M-nek TCer = (E c, T c )-t TTP elküldi a szoftvert U-nak

37 Deposit Ha a tranzackió sikeresen lezajlott, akkor M elküldi <A,B,(z, e 1, e 2, r, a c, b c, t c ), (d, k 1, k 2 )> e-coint a banknak, aki jóváírja az összeget M egyenlegén. Ha a tranzakciót U megszakította fizetés nélkül, akkor M az <A,B,(z, e 1, e 2, r, a c, b c ), (d, k 1, k 2 ), (E c, T c )> értékkel jelentkezik a banknál, ami szintén teljes értékű e-coinnak számít. 38 Támadás Egy rosszindulatú kereskedő vissza tud élni a protokollal, és szert tehet a pénzre úgy, hogy a terméket nem juttatja el a vásárlónak Ehhez egy partnerre (C) van szüksége, aki segít a terv végrehajtásában. Miután M megkapta a pszeudo e-coint a vásárlótól, azt elküldi a TTP-nek, de azt állítja, hogy C-től kapta. Ekkor a TTP átalakítja a pszeudo e-coint valódi e-coinná, és elküldi a terméket C-nek, U pedig hoppon marad.

39 Támadás részletesen I. A kereskedő az ötödik lépésig (a BP eljárás) rendeltetésszerűen lefuttatja a vásárlóval a Payment protokollt Miután meggyőződött arról, hogy a pszeudo e-coin érvényes, megszakítja a tranzakciót M kér C-től egy hamisított OA-t: Θ = Sign RCSS (C,M,TTP,OA ), OA ={ID C,ID M,vásárlás adatai,termék leírása, (A,B)} M elkezdi a Dispute protokollt TTP-vel, és elküldi neki a pszeudo e-coint, valamint az előző lépésben hamisított értékeket 40 Támadás részletesen II. A TTP nem tudja eldönteni, hogy OA és Θ konzisztensek-e a peszudo e-coinnal, hiszen az nem köthető a tulajdonoshoz. A támadás nem működne, ha a pszeudo e-coin részét képező hash érték (d) tartalmazná a vásárló azonosítóját is, ekkor azonban sérülne az untraceability és az unlinkability TTP érvényesíti az érmét, és M megkapja a pénzt, C pedig a szoftvert. U nem kap semmit

41 Tanulság A protokoll nem javítható plusz biztonsági intézkedésekkel, mert C meg tudja személyesíteni U-t azzal, hogy mindenben utánozza őt. Abban a pillanatban, hogy U olyan műveletet hajt végre, amelyre csak ő képes és C nem (pl. privát kulccsal aláír), azonnal sérül az e-coin azon tulajdonsága, hogy nem köthető a tulajdonoshoz. 42 Támadások a SET protokollon Pozsonyi Tamás

43 SET protokoll Secure Electronic Transaction MasterCard, Visa, IBM, GTE, RSA, Microsoft, Netscape issuer, cardholder, merchant, payment gateway, acquirer, CA biztonsági protokollok, regisztrációs fázis, vásárlási fázis (al~: cardholder reg., merchant reg., purchase req., ( capture payment auth., payment dual signature 44 SET verifikáció Nehéz verifikálni (komplex, többszintű titkosítás, nonce és kulcsgen., alternatív protokoll ( utak célok bizalmasság integritás cardholder auth. merchant auth. ellenőrizhető tulajdonságok valószínűség regularitás titkosság (érvelés) ( leírás 1998 Meadows, Syverson (NPATRL, csak ( CSP+FDR 1999 Lu, Smolka (egyszerűsített, ( Isabelle 2000 Bella, Massacci, Paulson, Tramontano (reg. fázis, ( felfedés 2001 Herregweghen (letagadhatatlanság, adat ( Isabelle 2002 Bella, Massacci, Paulson, Tramontano (csaló PG, ( támadások 2002 Panti, Spalazzi, Tacconi, Valenti (NuSMV, Lu-Smolka ( támadás 2005 Brlek, Hamadon, Mullins (ASPIC, SET

45 Lu-Smolka támadások egyszerűsített, csak fizetési fázis, tipikusan web alapú tranzakciók 1 2 46 SET támadás tisztességtelen kereskedő és vásárló probléma: session ID egyediség, hiányos ellenőrzés megoldás: M és C identitása PG számára

47 Person-to-Person fizetési rendszerek biztonsága: PayPal Szamos Attila 48 Person-to-Person (P2P) rendszerek Személyek közötti átutalást tesz lehetővé, készpénz és elektronikus pénz nélkül Az account-ok között fizetéskor mindössze át kell vezetni a pénzt PayWorld, NetPay, PayNow, Billpoint (ebay), PayPal,... A PayPal egy készpénzmentes pénzforgalmi szolgáltatásokat nyújtó pénzügyi intézet.

49 PayPal működése A rendszer pénzügyi adatainkat nem adja ki, biztonságosan tárolja azokat a szerverein A PayPal-ban megbízunk Az eladó csak egy e-mail címet lát A vevő kap egy e-mailt, létrehoz egy PayPal account-ot, és megkapja a pénzt send money online to anyone with e-mail Wells Fargo Bank 50 PayPal-ról általában 2000 március: megalakul a Confinity és az X.com egyesüléséből ( Billpoint 2002 október: ebay megveszi a PayPal-t (előtte Regisztráció során: Dombornyomott bankkártya szükséges Személyes (nem adat) jellegű kérdések, későbbi elfeljetett jelszó visszaszerzésére Captcha A PayPal-on lévő pénz nem kamatozik Expanded Use ellenőrzés 400 forint átutalása a PayPal számlánkra 4 jegyű szám a számlakivonatunkon, mellyel meg kell ismét erősítenünk kilétünket PayPal-ról számlánkra utalás költsége 25.000,- alatt 250,- 25.000,- felett ingyenes Ha az átutalás sikertelen, akkor a PayPal számlára visszakerül a pénz, de levonásra kerül 1.500,- az összegből kezelési költség címén Fizetéskor az eladó fizeti a tranzakció költségét

51 PayPal biztonság I. SSL 3.0v Certificate Signature Algorithm PKCS #1 SHA-1 with RSA Encryption Connection Encrypted: High-grade Encryption 3DES- EDE-CBC Érvényesség: 2008.05.02. - 2008.05.03 VeriSign Class 3 Extended Validation SSL SGC CA 52 PayPal biztonság II. Csalás vagy jogosulatlan használat gyanújának esetén: "Limited Access" állapot Login Új jelszó Biztonsági kérdések (melyek nem tényeken alapulnak, pl: Mi a kedvenc színed? NEM PEDIG (? dátum Születési A felhasználó helyzetének megerősítése belföldi vezetékes telefonon vagy levélen keresztül

53 PayPal biztonság III. Security Key Kétlépcsős védelem Voltaképpen egy SecureID ára: $5.00 USD 30 mp-enként One Time Password előállítása Security Key bug: Chris Romero, 2007. november Kereskedő oldaláról átlépve a Paypal információkhoz, bármilyen 6 digites számra végrehajtódik a tranzakció Az ebay eleinte nem tudta reprodukálni a hibát 24 óra kellett nekik 54 PayPal biztonság IV. Tranzakciók monitorozása Tranzakció analizáló algoritmusok Gyanús: limithez közeli összeggel történő fizetés Irányítószám nem egyezik a felhasználó lakhelyével Tranzakciók megerősítése e-mailben. Gyanús e-mail után a 24/7 szolgálat segít Ha támadást sejtenek azonnal felveszik a felhasználóval a kapcsolatot Együttműködnek a hatóságokkal a csaló oldalak felderítésének és bezárásának érdekében Fraud Investigation Team Együttműködnek a rendészeti szervekkel, segítenek a bűnzők felelősségre vonásában 0.5%-os csalási ráta (máshol általában: 1.3% 2.6% között)

55 Biztonsági Hibák Natick, Massachusetts 2006. márc. 25. - AuctionBytes www.paypal.com/affil/pal= Az e-mail címhez tartozó teljes nevet megjelenítette az oldal Még csak nem is kellett bejelentkezni hozzá Hoax, phising támadásra nagy segítség Cross-site scripting bug 2008. május ( Validation A böngésző címsora zöld marad (SSL Extended Az Internet Explorer mindössze egy Is it safe? kérdést tesz fel JSP kódolási hiba 2008. február err_message változón keresztül ellenőrizetlenül átadott hibaüzenet Akár HTML és javascript kód is meghívódhat 56 Fraud Investigation Team Game over Egy sportoló bankkártyáját egy csaló eltulajdonította, majd a nevében beregisztrált a PayPal rendszerbe 3-6 év szabadságvesztés, 7 év próbaidő (arról nem szól a cikk, hogy hogy sikerült a számlakivonatos ( bűnözőnek megerősítésen is átjutnia a Crime Doesn t Pay Egy csalót letartóztattak, mert a vevőinek nem küldte az árut, miután fizettek neki. A bíróságon azzal védekezett, hogy egy illetéktelen személy feltörte a fiókját, és a nevében fogadott el pénzt a vásárlóktól. 21 hónap börtön Fake Emails, Real Jail Time Egy 20 éves férfi fake e-mailkkel próbálta kicsalni a felhasználók AOL és PayPal jelszavaikat. Az FIT segített összegyűjteni a szükséges bizonyítékokat, majd a rendőrség letartóztatta Őt és még két társát. 46 hónap börtön, a PayPal kártérítést fizetett az áldozatoknak

57 Összefoglalás, konklúzió Milyen hibákkal találkoztunk? Követhetetlenség sérült Csalás lehetősége Mi volt ezeknek a hibáknak az oka? Rossz definíciók Hiányos követelmények Ellentmondó tulajdonságok Rossz (figyelmetlen) implementáció Mit tanulhatunk a fenti esetekből? Jól átgondolt követelmények Formális elemzés Közhely, de: Az ördög a részletekben rejlik. 58 Köszönjük a figyelmet! Kérdések?