Teda, tolik pravopisných chyb v jednom článku, to se jen tak nevidí. Autor by si měl zopakovat shodu přísudku s podmětem. Ale ať jen nerejpu... I u nás se dají najít platební terminály, které nerespektují PCI a na účtence pro obchodníka je uvedené celé PAN (ačkoliv je v PCI jasně specifikováno, že alespoň šest číslic má být vymaskováno). Zlomyslnému obchodníkovi pak stačí jen letmý pohled na zadní stranu karty a má veškeré údaje potřebné k provedení platby.
Priznavam, ze jsem pravopisne cune a zkusim se polepsit :)
Ano, PCI DSS standard se nedodrzuje. Nevim kde ty auditory berou, ale i kdybyste do puntiku splnoval PCI, tak stejne vas system neni dostatecne bezpecny. Obcas si ten standard i protireci a nektere terminy vubec nedefinuje, ale je to stale lepsi nez nic. Problemem pak je jak si to dany auditor vylozil, takze vzdy radeji pocitejte s tou horsi variantou.
Mluvite o tomhle? https://www.usenix.org/sites/default/files/conference/protected-files/roland_sec13_slides.pdf
Vlastne tim EMV uplne vypnou a provedou fallback na magneticky prouzek.
To je ta prace, ale funguje to jinak, i kdyz ten nazev "magstripe over NFC" muze byt matouci. Utok je stale na EMV cip, kde udelame downgrade na Kernel 2 (pripad Mastercard). Nejprve se karte budeme tvarit jako platebni terminal a nechame si vygenerovat kryptogramy pro vsechny mozne UN, kterych je bud 100 nebo 1000.
Pak se s tim jde k realnemu platebnimu terminalu a tomu se rekne, ze umime jenom Kernel 2. At si vybere libovolne UN, tak umime z tech 1000 predgenerovanych odpovedi najit tu spravnou.
Kryptogram navic vubec nepokryva treba castku, takze nemusime si nechavat pregenerovavat kryptogram na konkretni castku. Kernel 2 je uplne WTF protokol.
Tohle vsechno ale obstarava EMV cip, je to naprogramovane v nem - s magnetickym prouzkem to krome nazvu nema nic spolecneho.
Ten magnetický proužek mě štval, tak jsem vzal silný magnet a několikrát proužek přejel. To, že jsem to udělal úspěšně a na všech kartách bylo vzápětí prokázáno nemožností použít karty v bankomatech.. Když se karta strká do bankomatu, tak je tam nějaké ověření, že jde o bankovní kartu - test na správný magnetický proužek. Takže pokud vás snad napadne udělat to co já, tak bacha..
Kontrola podpisu na účtence proti podpisu na kartě je, s prominutím, blbost. Podpis na kartě je souhlas s podmínkami, který však nemá (!) odpovídat podpisovému vzoru pro autorizaci plateb. (Že vám v české bance řeknou podepsat podle vzoru je chyba v informování na jejich straně).
Běžná praxe v US je tři křížky na kartě místo podpisu.
Kontrola proti podpisovému vzoru se provádí pak v bance jen při rozporu účtováné platby mezi kopií účtenky a podpisovým vzorem. A také nemá být podpis na kartě podle podpisového vzoru, aby při ztrátě karty nešlo podpis na katě zneužít.
Co všechno bych mohl a nemohl dělat s kartou, pokud bych magnetem zrušil proužek a fyzicky odstranil CVV a třeba i další údaje? Jsou moje předpoklady správné?
mohl bych:
* zaplatit v obchodech, protože se používá chip
* zaplatit na internetu
nemohl bych:
* dostat se přes zabezpečené dveře k bankomatu
* vybrat z bankomatu (nebo existují bankomaty na chip?)
Může obchodník odmítnout kartu, když uvidí, že je fyzicky upravená?
No tak samozřejmě, že údaje mám poznačené, to jsem myslel, že nemusím psát.
Přijde mi totiž naprosto nepochopitelné, že na kartě jsou všechny údaje potřebné k zaplacení. To tam rovnou mohou tisknout i PIN a nedělat z lidí, kteří si ho někam ke kartě napíší, málem nesvéprávné dementy, když banka dělá úplně to samé a její chybu nejde napravit, protože když kartu upravím, nemusí mí jí pak vzít obchodník.
Bankomat by mel spravne fungovat nasledovne. Snad se to medzitim moc nezmenilo.
- nacist prvni stopu karty a overit ze je "platna", zaroven zisti ze karta ma chip
- zacne komunikovat s chipem na karte (ruzna potvrzeni platnosti, nacteni konfigurace atd.)
- vyzada si pin a castku
- posle pin na overeni do chipu na karte
- posle finalni transakci do banky
- pokud nastane problem pri komunikaci s chipem je moznost ze bankomat zacne transakci po staru a nacte i druhou stopu z mag. prouzku a autorizuje po "staru"
Samozrejmne, ze je tam kopec sifrovani a dalsi komunikace s chipem.
Takže jestli to chápu dobře, bankomat neumí bez mag. proužku vůbec fungovat. Ale taky to vypadá, že kdybych zrušil 2. stopu, tak by mu 1. stačila (+chip) a zároveň bych ochránil kartu před skimmingem, protože zkopírovaná 1. stopa by k provedení transakce (bez druhé nebo chipu) nestačila. Je to tak?
Tak p7zip v OpenBSD by asi "spadnul", pac pledge sandboxing zakazuje programu delat exec().
cvs/openbsd-ports/archivers/p7zip/patches/patch-CPP_7zip_Bundles_SFXCon_SfxCon_cpp:+ if (pledge("stdio rpath wpath cpath fattr tty", NULL) == -1) { cvs/openbsd-ports/archivers/p7zip/patches/patch-CPP_7zip_Bundles_SFXCon_SfxCon_cpp:+ if (pledge("stdio rpath wpath cpath fattr tty", NULL) == -1) { cvs/openbsd-ports/archivers/p7zip/patches/patch-CPP_7zip_UI_Console_Main_cpp:+ if (pledge("stdio rpath wpath cpath fattr tty ps", NULL) == -1) { cvs/openbsd-ports/archivers/p7zip/patches/patch-CPP_7zip_UI_Console_Main_cpp:+ if (pledge("stdio rpath wpath cpath fattr tty ps", NULL) == -1) { cvs/openbsd-ports/archivers/p7zip/patches/patch-CPP_7zip_UI_Console_Main_cpp:+ if (pledge("stdio", NULL) == -1) { cvs/openbsd-ports/archivers/p7zip/patches/patch-CPP_7zip_UI_Console_Main_cpp:+ if (pledge("stdio ps", NULL) == -1) { cvs/openbsd-ports/archivers/p7zip/patches/patch-CPP_7zip_UI_Console_Main_cpp:+ if (pledge("stdio rpath tty", NULL) == -1) { cvs/openbsd-ports/archivers/p7zip/patches/patch-CPP_7zip_UI_Console_Main_cpp:+ if (pledge("stdio rpath tty", NULL) == -1) { cvs/openbsd-ports/archivers/p7zip/patches/patch-CPP_7zip_UI_Console_Main_cpp:+ if (pledge("stdio rpath", NULL) == -1) {