Vlákno názorů k článku Chyba v bankovnictví Komerční banky umožňovala přístup k datům o klientech od ZN - Je fakt, ze pouzivat javu pro pristup do...

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í.

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.

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.

Zásadní otázka ovšem je, kdo v této diskusi je ten, který se mýlí :-)

Ale jinak komentář s názvem nebo popisem algoritmu, který je přes OTP schopen přenést klíč, a používá použitelnou délku hesel, by byl jedním z mála užitečných komentářů v této diskusi.

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.

Jenže to "pokud je útočníkovi umožněno jen několik málo pokusů" právě pro útok zevnitř banky neplatí -- hrozí, že by někdo to počítadlo obešel.

Jak?

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ří.

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.

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.

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.