Názory k článku Bezpečnost mobilního eKonta Raiffeisenbank podrobně
-
Tak jsem si rekl, ze by takova silna tvrzeni clovek mohl vzit jako vyzvu. Tvrdit, ze HTTPS komunikace je nejak zabezpecena, je dost silna kava. Jedine co je, ze je pouzivana, ale urcite ne nejak solidne zabezpecena. Tak jsem se kouknul, co tam probiha za komunikace, zdali nas "ciste nahodou" nevodi za nos. Z nejakeho prvniho okouknuti komunikace je pravdou, ze je prenaseno pouze "id" a "salt" (tedy otisk a nikoliv samotny PIN nebo nejake heslo). Takze to je pozitivni, ze v tomhle nekecaji :-)
-
Prosím o informaci kde se v článku hovoří o HTTPS - jediné co já tam vidím je SSL/TLS. Ale dobře, řekněme že jste myslel to SSL. V tom případě prosím o informaci v čem je podle vás HTTPS/SSL "nezabezpečené." Pokud narážíte na nedávno vyhřezlé problémy s HTTPS, tak tam se AFAIK jednalo o problémy se správou certifikátů - za předpokladu důvěryhodnosti certifikátů (a to si IMHO v případě vlastní aplikace zajistit lze) je to spolehlivé zabezpečení kanálu.
-
fermi (neregistrovaný)
Ale no tak!! ;-)
Nechcete nam tady snad tvrdit, ze "naprosto bez problemu" univerzalne lustite vsechny sifry pouzite v SSL/TLS? V tom pripade smekam... (mate zrovna dovcu z NSA, ze jo :-)))Asi jste mel na mysli, ze za urcitych podminek jste schopen SSL/TLS nejak obelstit. Pak se slusi tyto podminky jasne deklarovat, pac se muze ukazat, ze to diky nim tak uplne "naprosto bez problemu" nejni...
-
fermi (neregistrovaný)
Souhlas ;-)
Jenze v tomhle pripade se tem "urcitym podminkam" dokaze vyvojar i uzivatel (je to i o sprave tech koncovych zarizeni - bohuzel...) vyhnout a utocnik ma smulu.
Takhle receno je to, kolego, jiny kafe nez puvodni formulace, ktera zavanela tim, ze SSL/TLS je totalne prolomene. Tak to neni. Jadro toho protokolu je celkem slusne - prinejmensim zamestnava kryptoanalytiky uz pres deset let - a da se pouzit tak, aby to cele z praktickeho hlediska splnilo svuj ucel.
Povim to je jeste jinak: Ve sve praxi "penetratora" jsem potkal jak apky, co pouzivaly SSL/TLS, tak i ty, co mely nejakou vlastni samohonku. Ty s tou vlastni samohonkou dopadaly tak, ze krome tech "urcitych podminek" jim hrozily zavazne utoky i za mnohem, mnohem volnejsich predpokladu. To diky tomu, ze ty "urcite podminky" jsou dany charakterem protokolu a kazdy takovy se s nimi nakonec musi vyporadat. Ti, kdo to zkouseli obejit samohonkou, si navic natloukli kokos jeste v jinych partiich - tam, kde si soucasne verze TLS preci jen uz svoje detsky nemoci odmarodily...
Takze tak.
-
n000 (neregistrovaný)
Zadna aplikace v mobilu nemuze z principu byt 100% bezpecna, alespon ne tak, jako napr. internetove bankovnictvi vyuzivajici alternativni komunikacni kanal (jako autorizacni sms pripadne fyzicky autentizacni kalkulator).
Problem je, ze pokud utocnik ziska kontrolu nad mobilem, muze zjistit jakekoliv informace, at uz odposlouchavanim stisku klavesnice nebo touch displaye nebo primo z bezicich procesu.
Ano, aplikace RB asi stezuje ziskani potrebnych informaci ruznymi obezlickami, ale pokud neni k dispozici alternativni komunikacni kanal, tak i slavnou "dvoufaktorovou" autentizaci v mobilu lze obejit.
Mimochodem - ten druhy faktor je vlastne co, kdyz prvni je pin?
Vlastnictvi te aplikace, tedy nejakeho klice vytvoreneho pri aktivaci a ulozeneho pote v mobilu?Bohuzel vyuziti autorizacnich sms v mobilni aplikaci by i tak bezpecnost nezvysilo, prave proto, ze je vse v jednom zarizeni, ktere pri kompromitaci muze poskytnout vsechny informace nutne pro autorizaci.
Tyto tvrzeni o super bezpecnosti jsou proto pomerne liche a ucelem je pouze vyvolani pocitu vetsiho bezpeci.
Samozrejme nezapomeli zminit, ze neni vhodne "rootnout" telefon, protoze prave v tomto pripade je sance na obejiti techto obezlicek pomerne znacna.
Prakticky to znamena, ze bezpecnost je prave tak velka, jak snadne je "rootnout" telefon, protoze pak uz lze zjistit cokoliv.
-
matfyzak (neregistrovaný)
Nikoliv.
Stoji a pada to s S-PIN a (patrne) nejakym tajnym klicem v mobilnim zarizeni. Pokud dokazete prolomit to zarizeni, tak si jiste umite precist i SMS. Takze timto zpusobem hrave prekonate i jednorazove kody pro web (az na ten druhy faktor, jeho detailni diskusi ovsem nechme stranou - stejne jako S-PIN).
Pokud uz tedy pristoupime na Vasi predstavu totalne nebezpecneho telefonu, pak snadno nahledneme, ze Vase finalni tvrzeni plati stejne tak pro web + SMS.
-
n000 (neregistrovaný)
Ano, presne jak pisete uz jsem to zminoval v mem prvnim prispevku - autorizace pres sms nema pro aplikaci v mobilu vyznam prave proto, ze utocnik muze mit kontrolu nad mobilem a prakticky sms v tomto pripade neni zadny dalsi komunikacni kanal...
Pro bankovni aplikaci v mobilu se stejnou urovni bezpecnosti jako ma internetove bankovnictvi vyuzivajici autorizacni sms by mobil musel byt doplnen jeste autentizacnim kalkulatorem (dalsim fyzickym zarizenim), protoze sms do stejneho mobilu nemaji smysl.
Jinymi slovy, zadna aplikace v mobilu nemuze byt nikdy alespon tak bezpecna jako je internetove bankovnictvi s autorizacnimi sms.
-
matfyzak (neregistrovaný)
Bohuzel opet nesouhlasim. Degradace druheho autentizacniho faktoru pri kompromitaci mobilniho zarizeni, kterou jsem adresoval v predchozi reakci, se tyka stejne tak mobilni aplikace jako int. bankovnictvi s autorizacni SMS. Zamerne jsem napsal web + SMS, a to bez (!) ohledu na to, kde si ten web prohlizime. Dale se pro jednoduchost drzme toho, ze web prohlizime na pracovni stanici.
V obou pripadech nam jeden faktor odpadne a zbyva pouze to, co uzivatel zna. Moznosti prekonani tohoto faktoru se lisi podle konkretni implementace. Pokud se budeme odvolavat na proste uhadnuti, pak jsme na tom v obou pripadech prakticky stejne (pravdepodobnost uhodnuti mozna kratsiho PIN muzeme vuci heslu kompenzovat nizsim poctem pokusu).
Pokud budeme uvazovat o zachyceni druheho faktoru skodlivym kodem (coz je samozrejme narocnejsi uloha nez "jen" vytahnout persistentne ulozeny klic), mame opet k dispozici urcite moznosti v obou pripadech.
Vase teze o nemoznosti pruniku utocnika z pracovni stanice na pridruzeny mobil, zminena vedle, neplati. Nejak jste vynechal utoky typu cross-platform.
Ergo, z diskutovanych aplikaci (mobil vs. web+SMS) nelze zadnou OBECNE povazovat za a-priori horsi.
-
n000 (neregistrovaný)
Uff, tak to jsme se dostali tedy do hoodne teoreticke roviny - tvrzeni, ze potreba ovladnout pouze mobil v pripade mobilni aplikace je obecne stejne narocna/pravdepodobna jako potreba ovladnout pracovni stanici SOUCASNE s mobilem pouzivanym pro autorizacni sms, tak to je podle meho nazoru hodne odvazne a ja rozhodne nesouhlasim ani teoreticky.
V pripade internetoveho bankovnictvi je krome hesla/pinu dalsim faktorem prave autorizacni sms, ktery rozhodne neodpadne (jak chybne tvrdite), pri ovladnuti pracovni stanice utocnikem.
Utoky typu cross-platform?
Zajimavy pojem, rad se necham poucit.OBECNE lze naopak tvrdit, ze v pripade mobilni aplikace je pravdepodobnost kompromitace dana jednim clankem, tj. mobilem.
V pripade internetoveho bankovnictvi na PC s autorizaci sms je pravdepodobnost kompromitace soucasne PC a pridruzeneho mobilu radove nizsi uz jen proto, ze kompromitace mobilu je potreba v obou pripadech.
Abych to shrnul, utocnik muze napsat software, s pomoci ktereho bude schopen plne automatizovane v napadenem mobilu provest jakoukoliv bankovni transakci.
Toto se mu ale nepovede s nicim, co by dostal do PC pouzivaneho k IB s sms, protoze nema jak by se obecne dostal z PC navic k pridruzenemu mobilu, ktery muze byt uplne jakykoliv, klidne bez OS, oproti bankovni aplikaci, kde je podporovane prostredi dane. -
matfyzak (neregistrovaný)
Nebojte, na teorii nedojde - nedavate mi moc sanci vest teoretickou diskusi, nebot ponekud zkreslujete uvedena tvrzeni.
"Obecne" vyroky uvadite prosim zejmena Vy, a to prakticky bez solidnich argumentu (nerku-li dukazu). Ja zde naopak tyto obecne teze v potu tvare vyvracim. Nahlednete k tomu prosim, ze "...obecne plati, ze..." ma zasadne jiny vyznam nez "...neplati obecne, ze...". Druha formulace poukazuje na skutecnost, ze nejaky vyrok neplati v danem kontextu vzdy, ale (mozna) jen v nejakych pripadech.
To je vse, co se Vam celou dobu snazim sdelit - NELZE a-priori, tj. bez uvazeni detailu pouzitych protokolu a implementace, rict, ze web+SMS je nutne bezpecnejsi nez mobilni aplikace. Tecka.
Ano, nekdy muze byt jednodussi napadnout mobilni aplikaci, ale nekdy je to obracene. Vase vyroky o obecnem usporadani sily techto metod jsou zjevne podlozene jen dojmy. V realite zalezi na detailech.
Skutecnost, ze jste vynechal cross-platform utoky trochu vysvetluje, proc jste tak presvedceny o "obecne" sile web+SMS. Vami uplatnena argumentace je tim ovsem vyznamne oslabena. Zkuste se podivat treba sem: http://www.blackhat.com/ad-12/briefings.html#Dmitrienko . Jinak take pomuze strycek Google...
Musim dodat, ze nejsem vubec presvedceny, ze jste kdy skutecne sam napsal nejaky vlastni exploit nebo rovnou kompletni proof-of-concept utok, at uz pro jedno nebo druhe prostredi. Jinak bych napriklad alespon "na pozadi" Vasich tvrzeni videl ponekud peclivejsi reflexi jednotlivych OS, HW platforem, verzi, konfiguraci... Bohorovne odepsani mobilu a protezovani web+SMS un bloc se s hlubsi zkusenosti v tomto oboru neslucuje. Ja tu ovsem nejsem, abych se Vas snazil nejak dotknout, to rozhodne ne (a omlouvam se, pokud se tak nahodou stalo).
Zaverem moc dekuji za diskusi. Po suche skolni teorii je poucne videt nazory uzivatelu :-)
-
n000 (neregistrovaný)
Prosim vysvetlete, co jste myslel vetou "V obou pripadech nam jeden faktor odpadne a zbyva pouze to, co uzivatel zna."
To je podle me hola nepravda, resp. zobecneni velice okrajove situace, kdy by mohl byt proveditelny cross-platform utok na pc a autentizacni mobil.Uvadeny cross platform utok predpoklada, ze na PC pobezi Windows a autentizacni mobil bude mit Android. Pritom mobil nemusi mit vubec zadny OS a na autentizaci sms bude krasne stacit, takze prakticky nebude napadnutelny. PC take nemusi mit Windows, ze.
Pritom v pripade mobilni aplikace jsou cilove platformy pouze 2 a to Android a iOS bez potreby ziskat kontrolu nad vice zarizenimi soucasne.Vy tvrdite, ze ja zkresluji, pritom jste to Vy kdo zobecnuje okrajove situace.
-
matfyzak (neregistrovaný)
OK, nicmene timto svou diskusi opravdu ukoncim. Opakuji, ze ja konkretni priklady pouzivam k vyvraceni Vasich "obecnych" tezi. Mozna se neumim v tomto prostoru jednoduse a prehledne vyjadrit, i tak to muze byt.
K Vasi otazce: Predpokladejme, ze na mobilnim zarizeni je instalovan skodlivy kod. Necht se tam nejak dostal. Vy sam se zdate povazovat instalaci takoveho kodu malem za standardni vybaveni fw, tak at :-) O takovem kodu lze v prvni rade predpokladat (viz dosavadni ZitMo a diskuse kolem), ze bude zejmena umet krast zpravy SMS. Bez ohledu na puvodni zamer (treba chtel hacker jen lechtive zpravy) tak bude utocnik "spamovan" take autentizacnimi SMS obeti. V mnoha pripadech bude po chvili utocnik schopen zjistit, odkud tyto zpravy jsou a jak se pokusit prihlasit (prosim nepredstirejme, ze veci jako id klienta jsou solidni prekazkou). Kolik faktoru mu nyni zbyva k prekonani autentizace na web+SMS? Rekl bych, ze jeden...
Podotykam, ze toto jsem pouzil v konstrukci k vyvraceni platnosti Vasi teze, ze SMS+web je obecne (tj. v kazdem pripade) lepsi varianta nez mobilni aplikace. Podotykam take, ze nyni nechavam stranou i rozbor toho, kdy je na tom mobilni aplikace naopak (!) lepe.
Spokojim se s poukazem na neplatnost Vaseho bodreho vyroku, o obecne lepsi situaci pro web+SMS (a pisu to uz tolikrat, ze byste se nad tim opravdu mohl chtit zamyslet). Snad bych mel take pripomenout, ze negaci atakovaneho vyroku je, ze existuji situace, kdy je bezpecnost mobilni aplikace alespon tak dobra (spatna) jako web+SMS. To je jen jina forma meho drivejsiho tvrzeni.
Mozna chcete namitnout, ze uvazovany skodlivy kod na mobilnim zarizeni ma pri variante s mobilni aplikaci lepsi vyhlidky na prime ziskani prvniho (klic) i druheho (PIN) faktoru . Na to ja rikam: Nekdy ano, ale nikoliv (!) prosim obecne v kazdem jednom pripade (coz je Vase stanovisko). K tomu pripominam, ze je zahodno mnohem pecliveji rozlisoval, jake jsou rozdily mezi skodlivym kodem, ktery jen preposila SMS, kodem, ktery umi vykrast datovy kontejner aplikace (nebo rovnou keychain), a konecne kodem, ktery umi i zachytit text z virtualni klavesnice. Jsou tam vyznamne rozdily v narocnosti a schudnosti vubec.
Sam jste na uvedeny priklad cross-platform utoku reagoval tak, ze to je otazka konkretni situace. Souhlasim. A take ovsem obdivuji, jak jste uz podle abstraktu poznal vsechny okrajove podminky a mozne nuance utoku. Myslite, ze "referencni" implementace se ma chapat jako "jedina mozna"? Nakonec treba ano, ale z toho abstraktu to opravdu nevidim. Ale necht, to je jina vec. Proc ale neberete tak razantne v potaz vyznam konkretni implementace a konfigurace i v pripade mobilni aplikace?! Opakuji, nic nezobecnuji, vyvracim Vasi "obecnost", ze web+SMS je na tom vzdy lepe.
Tak, doufam, ze jsem Vas prilis nepohneval, a preji jen to dobre.
-
fermi (neregistrovaný)
technicka - je to jak, kde
Daji se videt sifrovane SMS chranene klicem na SIM, ale najde se i hodne - a snad i vic, bych rekl od boku - klasickych textovek.Jinak bych k te diskusi jako systemak jeste pripichnul, ze pohadka o oddeleni pracovni stanice a mobilu platila naposledy snad nekdy v dobe Widli 3.11 a Nokia NMT ;-) Zahy se objevilo pomerne dost mobilek s totalne nechranenym bootem. To, co se na nekterych iDevices dneska pracne exploituje, bylo tehdy casto snadno k dispozici. Je trochu zvlastni, ze malware tenhle kanal nezneuzil - driv nebo pozdejc vetsina uzivatelu svuj mobil k jejich kompu pripojila. Treba pro zalohovani kontaktu. I kdyz... kdo vi jiste, jestli to fakt nekdo nekde nepouzil?
-
fermi (neregistrovaný)
Pardon, to jsem nechtel. Dobra zprava je, ze fakt nevim o tom, ze by to nejaky malware aktualne zneuzival. A nejspis by se o tom hodne vsude napsalo, kdyby to ted nekdo najednou vytahl... Inu, berte tu mou hlasku hlavne jako vsuvku do poucne diskuse o "obecne" (ne)porovnatelnosti urcitych metod. V praxi se banky - alespon doufam, smarjajosef - musi snazit adekvatne zabezpecit vsechny sve aplikace, takze by mely byt prvni, kdo by na uvedenou hrozbu nejak reagoval.
Ciste technicky vzato je maximalni ochranou nespojovat ten telefon vubec s pocitacem (ani pres BT). To je, chapu, pro uzivatele hooodne ujete. Chcete-li, tak se tedy alespon snazte ten telefon nerestartovat behem doby, kdy je fyzicky pripojen k pocitaci. Ani kdyby skemral a na kolenou Vas prosil! Tak by se presne mohl malware chovat. Vyjimkou muze byt jedine vedoma aktualizace FW, ale tu byste prave mel delat jedine na duveryhodnem pocitaci. Pokud nahodou uvidite, ze se pripojeny mobil presto sam restartuje, odpojte ho a zrestartujte rucne. Ja osobne bych na Vasem miste urcite vic nedelal. Jinak uz byste se musel zacit bat i utoku ze strany falesne BTS, atp.
Podstatne je byt mimo hlavni radar kriminalniku a doufat, ze si Vas nekdo nevezme jaksi do osobni pece. Pak je kazda rada draha :-)
Takze: "Klid, prosim, byla to jen turbulence. Posadka kpt. Bulika ma letadlo plne pod kontrolou..." ;-)
-
matfyzak (neregistrovaný)
Bohuzel pletete dohromady ruzne pojmy. Mozna byste se chtel podivat, jak je 2faktorova autentizace definovana. Je to snad v kazdem uvodu do bezpecnosti. Zkuste treba: http://en.wikipedia.org/wiki/Two_factor_authentication .
Ani slovo o nutnosti alternativniho kanalu! Muzete ho samozrejme pouzit, pokud je to mozne a vhodne. Jeho absence ovsem nijak neimplikuje, ze v principu nemuze jit o 2faktorovou autentizaci.
Lze tusit, ze druhym faktorem ve smyslu obecne def. je nejaky klic v kontejneru aplikace. V tom s Vami souhlasim, ale stale to JE druhy faktor.
O sile vysledne metody rozhoduje mnoho dalsich aspektu. Sam jste korektne zminil riziko rootovani. Tezko v praxi muzete mluvit o 100 % bezpecnosti cehokoliv. Lze pracovat jen s relativnimi pojmy. Pocit vetsiho bezpeci je tedy zcela OK, pokud je podlozeny. Rajfka se asi snazila o trochu vic nez ostatni. Je to lepsi, nez nedelat nic a vedoucne kyvat hlavou...
-
n000 (neregistrovaný)
Nikdo tady nezpochybnuje definici doufaktorove autentizace, ale spis tvrzeni, jak je to s jejim vyuzitim a implementaci od RB krasne bezpecne - neni a z principu jakakoliv aplikace v mobilu bez alternativniho komunikacniho kanalu nikdy 100% bezpecna nebude.
Urovne bezpecnosti internetovych bankovnictvi, ktere vyuzivaji alternativni komunikacni kanal proste nikdy samostatna aplikace v mobilu zdaleka nedosahne.
Jeste jinak:
- pokud utocnik bude mit plnou kontrolu nad mobilem v dobe, kdy uzivatel zadava pin v RB aplikaci, muze ziskat vse potrebne pro zadani jakekoliv transakce
- pokud utocnik bude mit plnou kontrol nad pocitacem s internetovym bankovnictvim, kde je alternativni komunikacni kanal (sms, kalkulator), zadnou dalsi transakci nema moznost provest, i kdyz bude znat heslo do IB -
fermi (neregistrovaný)
Jste se nam tady nejak rozjel, clovece, viz: "...neni a z principu jakakoliv aplikace v mobilu bez alternativniho komunikacniho kanalu nikdy 100% bezpecna nebude..."
Inu, v praxi abyste 100% bezpecnost cehokoliv pohledal. Ten "vas" internetbanking a SMS ji podle vas snad ma? To si nemyslite, ze ne... ;-)
Ovsem co byste rekl na takovy koncept TEE/TrustZone? OK, ono to zatim funguje lip na papire nez kde jinde, ale jednou to nejspis prijde. Takze s tou raznosti bych trochu ubral, nic ve zlym.
-
V clanku se pise, jak se uzasne zachazi s PIN po aplikacni strance. Nicmene - samotna klavesnice na zadani PINu je stale stejna. Tj. jednoduchy logger obrazovky / tapovani na klavesnici a PIN je doma.
Z clanku je jasne, ze banking RB je opravdu bezpecnejsi, nez u konkurence. Nicmene ta bezpecnost neni vyssi radove ani podle me nasobne. Kazda bezpecnost je tak silna, jak silny je jeji nejslabsi clanek. I u napr. FIO, ktere mam ja, je potreba pro pridani noveho zarizeni ono zarizeni sparovat, tj. prihlasovani pres mobil je oddelene od prihlasovani pres web. Tj. na cizim mobilu se nikdo do bankovnictvi FIO s mymi prihlasovacimi udaji nedostane.
Pri realnem pokusu o napadeni / zneuziti formou ukradeni telefonu je pak podle me napadeni RB uctu dotycneho jednodussi - je snazsi okoukat stale stejny ciselny PIN ktery se zadava na velke ciselne klavesnici nez heslo do FIO, ktery se zadava na plne klavesnici a ma pravidla pro pouziti velkeho pismene / nepismeneho znaku.
-
fermi (neregistrovaný)
Inu, tohle http://www.fio.cz/docs/cz/aktivace_iOS.PNG a tohle http://www.fio.cz/docs/cz/Fio_IB_Globalni_nastaveni_SB_potvrdit_zarizeni.PNG vypada, ze druhym faktorem u FIO je proste UDID resp. IMEI. Fiiiioooo...
Pokud je to tak, potom je prakticke srovnani bezpecnosti takove komedie s klicem ulozenym treba v keychain pod iOS vtip (bez ohledu na PIN/heslo). Byl to vtip?
A co ta nutnost porovnat nebo snad dokonce opsat (brrr) kompletni UDID v podani bezneho uzivatele? To byl druhej vtip, ze jo ;-)
A nakonec, to se mobilni zarizeni u FIO fakt registruje jen zadanim jmena a hesla pro web (do webu)? Uz dost, clovece, to by bylo moc vtipu najednou! :-)
-
Vsak taky rikam, ze RB ma vyssi bezpecnost. Ale ne radove. Napr. takove kreditni karty maji bezpecnost radove nizsi a presto to funguje. Moje pripominka byla ohledne bezpecnosti pri ukradeni mobilu / jednodussi vysledovani PIN na daleko jenodussi klavesnici u RB.
Do FIO bankingu se zadny UDID neprepisuje, zarizeni se prida automaticky a nasledne potvrdi ve webovem rozhrani autorizacnim kodem poslanym SMS.
-
fermi (neregistrovaný)
Ten scenar je hodne specificky utok, kdy zlodejem je nekdo z blizkeho okoli. Takovy typek ma ale sanci dostat se na kobylku i "komplexnimu" heslu. Treba docasnym podhozenim sveho vlastniho mobilu s falesnou apkou. V kazdem pade tu jde o nejakou osobni hygienu pri zadavani PIN/hesla. Napad pro RB: Do dialogu pro vlozeni PIN napsat tucne: "Nezadavejte PIN, pokud je v okoli zevl!" A mozna jeste rovnou do maleho ramecku pustit signal z predni kamery a-la zrcatko na bankomatu. Jdu jim to napsat ;-)
Jinak ale ukradeni mobilu dopada mnohem hur pro FIO. Napriklad UDID (fakt je to ten druhej faktor?) mi piskne i zamceny iPhone jako seriove cislo na USB. Staci ten ulovek pripojit k Linuxu a vypalit oblibene "sudo lsusb -v" (si to zkuste). Takze prvni faktor na iOS padne, sotva mam ten mobil v ruce. Navic ho muzu klidne rychle vratit a pak zevlovat heslo. Dusledek - obet je naprosto spokojena, asi jako jelen v okularu zamerovace. Fiiiioooo :-))) Bum.
Ze by na tom IMEI Androidu bylo nejak lepe? Asi ne, co...
Furt mi to ale nejak nesedi. Skutecne je druhym faktorem ve FIO UDID/IMEI, nebo je to jen identifikator toho zarizeni? Tohle se prece nemuze pustit do sveta. Fiiihaaaa ;-)
-
V dobe kdy jsem si to API debugoval (asi pred pul rokem) to tak opradu bylo - UDID tam behalo press SSL v XML zprave. Tehdy tam jeste meli chybu, ze se neoveroval certifikat, takze sel udelat krasne MitM attack. To uz je nejakou dobu opravene. Mozna ze zmenili i tu komunikaci, takze to co pisi bylo opravdu aktualni pred pul rokem.
Co presne tam maji ted jsem nezkoumal, ale cisty UDID to urcite neni.
-
Co je tam na iOS, nevím, ale na Androidu to je IMEI, nebo unikátní číslo zařízení. Pokud aplikaci spustíte na mobilu, nelze dokončit přihlášení, dokud dané zařízení neaktivujete na desktopu.
Přihlášení do desktopového IB je sice jednofaktorové, ale autorizace změn je dvoufaktorová: Na autorizaci každého příkazu na Desktopu potřebujete Java aplikaci, a heslo k jejímu podepisovacímu klíči.
Na mobilu je autorizace změn dokonce třífaktorová: unikátní id zařízení, heslo do bankovnictví (odlišné od hesla na desktopu), autorizační PIN.
Na desktopu by stačil schopný keylogger, ale na mobilu ne. Útočník by musel získat plnou kontrolu nad mobilem, aby spustil bankovní aplikaci přímo na napadeném mobilu. Při krádeži mobilu, dokonce i s přihlášeným bankovnictvím, zase nebude útočník znát autorizační PIN. Navíc i aplikaci samotnou lze nastavit tak, že se po zatřesení mobilem odhlásí.
ČLÁNKY DO MAILU
