Vlákno názorů k článku Chyba v bankovnictví Komerční banky umožňovala přístup k datům o klientech od Filip Jirsák - Pokud je ten privátní klíč někde uložený tak,...
-
Pokud je ten privátní klíč někde uložený tak, že se dá snadno přečíst (pevný disk, disketa, flashdisk), závisí vlastně veškerá bezpečnost na heslu k privátnímu klíči. Přičemž hádat heslo může případný útočník libovolně dlouho na libovolném množství počítačů.
Přihlašovat se do internetového bankovnictví jen heslem nebývá považováno za bezpečné (proto se používá dvoufaktorová autentizace), a ten neomezený počet pokusů na rozlousknutí k tomu…
Pokud je dnes potřeba pro aktivní operaci potvrzovací kód ze SMS, je to dobře, já mám pocit, že ze začátku stačilo autorizovat operaci zase tím privátním klíčem.
Původní myšlenka asi byla dobrá, kdyby se transakce podepisovali privátním klíčem uloženým na čipové kartě, bylo by to rozumné zabezpečení. Jenže čipové karty a čtečky byly drahé, takže většina lidí zvolila privátní klíč v souboru, a tím šla veškerá bezpečnost do kytek.
Ono nejde ani tak o to, že by někdo našel na ulici flashku s certifikátem. Ale pokud budete mít v počítači nějaký vir, který odposlouchává klávesnici a čte soubory, má při vašem prvním přihlášení do banky vše na stříbrném podnose. No a když už je ve vašem počítači, proč převod z účtu neposlat taky z něj, aby byla stejná IP adresa, případně identifikace prohlížeče apod.
-
Můžete to trochu rozvést? Certifikát je jedna věc, druhá je, že k němu potřebujete znát heslo... A třetí, že i když ho uhodnete, pak ve chvíli, kdy se do elektronického bankovnictví přihlásíte z IP adresy, z níž jste se ještě nepřihlašoval, přijde Vám na mobil potvrzovací kód, bez něhož se nikam nedostanete (nehledě na to, že i v případě známé IP adresy je kód ze SMS potřeba následně pro jakoukoliv aktivní operaci).
Mně takový přístup "naprosto k hovnu" nepřijde, aby se mi někdo dostal na účet, přijde mi, že je třeba výrazně více než jen najít na ulici flashku s mým certifikátem.
-
Když se budou dodržovat základní bezpečnostní pravidla, nemusím se do banky hlásit pomocí jednorázového hesla a zvlášť potvrzovat každou transakci, ale stačí mi ten čtyřmístný PIN. Já ale píšu o případu, kdy se počítá s tím, že někde něco může selhat, a proto jsou bezpečnostní mechanismy mnohonásobně jištěné (což je případ třeba banky).
V bankách se obrana proti útokům zevnitř řeší předpokládám především organizačně (pro kritické operace je potřeba víc lidí, kteří by se museli domluvit), ale já jsem psal o technickém řešení. Ostatně, jak je vidět z článku, pod kterým diskutujeme, dodržovat základní bezpečnostní pravidla se ne vždy daří.
-
_pepak (neregistrovaný)
I krátký klíč (důkaz znalosti klíče) může být odolný proti útoku hrubou silou, pokud je útočníkovi umožněno jen několik málo pokusů. Viz například PIN - má jen 4 číslice, navíc ne všechny kombinace banka dovolí, takže není ani 10000 kombinací - ale v souvislosti s tím, že po třech chybných pokusech se karta zablokuje, je to dostatečně silné.
-
Může se přenášet i důkaz znalosti klíče, ale pořád je potřeba, aby byl dost dlouhý, aby nebylo možné jej najít hrubou silou.
Použitelnou délku hesla myslím pro případ, kdy mi heslo přijde SMS, vygeneruje ho aplikace v mobilu nebo hardwarový generátor OTP a já ho musím ručně přepsat do počítače. Pokud musím použít speciální hardware k PC, to už rovnou můžu použít čipovou kartu s privátním klíčem. Ale třeba budou v dohledné době webové kamery tak běžnou součástí PC, že bude možné přenášet dlouhé heslo přes QR kód.
-
x (neregistrovaný)
Ja mam s timhle zcela osobni zkusenost - managori zakaznika chteli, aby si zakaznici sami mohli zakladat doklady, podivat se na seznam faktur ... a jejich predstava byla, ze se jim proste nainstaluje klientska aplikace ... jejiz zabezpeceni je zcela nepruchozi a nemozny.
Rek sem sefstvu, ze v takovym pripade od toho davam ruce pryc a nechci stim mit nic spolecnyho. Toho se nastesti zalekli, takze z toho nic nebylo.
Alternativa byla napsat prave nejakej mezikus, kterej by jednoduse "neumel" ziskat jina nez povolena data, ale to by nebylo zadara ... ;D.
-
_pepak (neregistrovaný)
Nabízí se otázka, proč by se měl přenášet *klíč* a ne *důkaz znalosti klíče*.
Nabízí se též otázka, co rozumíte "použitelnou délkou hesla" - já si třeba myslím, že i značně dlouhé heslo může být použitelné, pokud se práce s ním udělá chytře (viz např. Yubikey - i když ten zase má horší tu část s důkazem znalosti klíče).
-
To je mi líto, že to váš kolega neumí. Asi jste tím chtěl naznačit, že vy to tedy umíte – ale pak je potřeba ještě přečtené pochopit. A pochopit, že chyby zavlečené implementací jedné nové vlastnosti Javy 7 nejsou principiální problém celé platformy, ani se nevyskytovaly v implementacích Javy 6 a starších. A že někdy před 12 lety, kdy se volila varianta MSIE only ActiveX nebo Java Applet, nebylo možné dnešní problémy Javy očekávat.
-
lojza (neregistrovaný)
Jak to taky možná bylo :-)
Udělali nějakou aplikaci pro obchodníky s tím pojištěním ani to nemuselo být vystrčené ven.¨
Pak někdo přišel s tím že to jako chce mít aby si tam lidi v samoobluze (nebo jak tomu Java bazmeku pro klienty říkají) mohli vidět svoje smlouvy.
Armáda systémových architektů a bussines analytiků prohlásila, že to je tak na tři kvartály, dodavatelé chtěli cenu jak za vystřelení družice k Měsící ... tak nějakou hlavičku napadlo, že jenom vystrčí nějaké URL ven, dá se tam IFRAME nebo nějaká podobná prasárna (pardon technologie) a premie byly doma :-)
Jenomže se to vystrčilo ven celé (protože levá ruka neví co dělá pravá, nebo to jinak nešlo), ve vystrčené stránce se dalo kliknout na něco co tam být nemělo a bylo vymalováno.
V intranetových aplikacích se na bezpečnost spíše peče. Protože náklady. Když pak někdo přijde s tím že tudle tamdle kousek zpřístupní mimo firmu, tak to buď nejde (a rozumný šef to pochopí) nebo z toho může být průšvih.
-
Jirka Vejrazka (neregistrovaný)
Chtel jsem k tomu neco obsahleho napsat, ale udrzim se. Snad jenom http://xkcd.com/386/
-
Neumějí. Autentizační kalkulátory jsou jenom starší způsob, jak generovat jednorázová hesla. A jednorázová hesla jsou symetrická kryptografie, nebo-li stejné udělátko, které vám vygeneruje jednorázové heslo v kalkulátoru, musí být schované i někde v bance. Teoreticky by bylo možné udělat OTP i s asymetrickou kryptografií. Jenže aby to mělo nějaký smysl, musela by generovaná hesla být mnohem delší (proti nějakému desetiznakovému heslu by pořád mohl někdo v bance pustit slovníkový útok). No a s internetovým bankovnictvím, kde se platby potvrzují opsáním 80 znakového kódu, by banka asi neuspěla.
-
Obávám se, že x tohle velice dobře ví, ale stejně bude generalizovat na všechny verze a na celou platformu.
Jinak klientské certifikáty, pokud se implementují dobře, jsou opravdu nejvyšší možnou formou zabezpečení. Jako jediné totiž dokážou chránit nejen proti útokům zvenku, ale také proti útokům zevnitř banky. To s OTP hesly nejde.
-
Lol Phirae (neregistrovaný)
Já o těch posledních chybách v JRE od Oracle něco vím
Hmmm... myslíš asi tohle?
-
Neřekl bych, že Google nějak pomůže při hledání důkazů pro vyfantazírovaná tvrzení. Já o těch posledních chybách v JRE od Oracle něco vím, takže vím ,že je nesmysl zevšeobecňovat je na starší verze a na obecnou děravost. Tak mne právě zajímalo, zda x myslí ještě nějaké jiné chyby, nebo jestli tradičně plácá o něčem, o čem nic neví.
-
Jirka Vejrazka (neregistrovaný)
Java patri v poslednich mesicich mezi top 3 nejproblemovejsi produkty z hlediska bezpecnosti, pomalu neuplyne mesic, aby nebyla nahlasena nejaka nova zranitelnost. Ty znamejsi jsou treba tady:
http://secunia.com/advisories/search/?search=Oracle+JavaMimochodem tvrzeni jednoho z predrecniku o tom, ze klientske certifikaty jsou nejvyssi moznou formou zabezpeceni je zoufale chybne.
-
Lol Phirae (neregistrovaný)
Ano, na nazor Java posuka jsme cekali. Java je proste ouplne nenahraditelna a bez ni bysme vsichni byli na stromech s holou prdeli.
P.S. Bez studovat ten export z Gimpu :-P
-
x (neregistrovaný)
Spis je to o tom, ze java je nebezpecna sama o sobe, a pouzivat deravej nastroj k zabezpeceni je asi tak stejny, jako pouzivat sejto k prelejvani vody.
Navic ta jejich javova appka neustale nefungovala, a vyzadovala vzdy zcela konkretni a zcela prehistorickou (a tudiz jak reseto deravou) javu.
-
x (neregistrovaný)
Ja bych to (i z toho co je videt) odhadoval zhruba tak, ze jednoho krasnyho dne nejakyho hlavouna napadlo, ze by nejaky ty obchodnici s vodou mohli obchazel lidi a uzavirat snima smlouvy doma. Pak zjistil, ze na to potrebujou nejakej pristup do systemu ... samo pres data => pres internet. A samozrejme dalsi polozkou byl pristup prislusnych hlavounu z domova - to aby nemuseli namahat sve hyzdove svalstvo presednutim do limuziny a cestovanim do kancelari.
Dovolim si taky myslet, ze prislusni ITci jej upozornili na to, ze to neni zrovna bezpecny zpusob ... ale hlavoun, jak uz to tak byva, prohlasil neco v tom smyslu, ze ho to nezajima.
I vznikl system vzdaleneho pristupu do bankovnich systemu. Da se predpokladat, ze v teto fazi byl alespon nejak "zakladne" otestovan.
Jenze prisly pozadavky na zmeny tuhle, na zmeny tamhle a nikdo samozrejme uz nevedel jak to ci ono funguje, kde vsude to je/neni provazano a tak nam vznikla tahle pekna dirka. Vi Buh, jak dlouho tam byla.
BTW: Naprosto minimalne bych ocekaval ze takova vec pobezi na nejakem servisnim a zcela oddelenem webu, aby bylo jasne co to je a k cemu to je.
-
Dash (neregistrovaný)
Javu používala KB do nedávna (to jest díky vývoji browserů už dnes není pro přístup do MojíBanky třeba) pro client-side šifrování komunikace certifikátem. To je mimochodem nejbezpečnější možné uspořádání, kam se hrabe Spořka, která jeden čas neměla ani Class 3 certifikát pro web banky.
Takže panáčku, vyjadřuj se k tomu, o čem aspoň něco málo víš.
