Hlavní navigace

Internetové bankovnictví

Na vaše dotazy odpovídá Jan Smítek, produktový manažer přímého bankovnictví Živnostenské banky. ŽB byla jednou z prvních bank, která pod názvem NetBanka uvedla na tuzemský trh služby internetového bankovnictví. Vloni se počet uživatelů NetBanky zvýšil o více než třetinu.

V poradně odpovídá

  • Jan Smítek

    (Poradce pro přímé bankovnictví)
    Produktový manažer přímého bankovnictví Živnostenské banky
Poradna je uzavřena, nelze vkládat nové dotazy.

Dotazy

  • Důvěra v banku

    Přeji hezký den,

    plně souhlasím s názorem, že vztah mezi klientem a jeho bankou je založen na důvěře. Lze však důvěřovat ústavu, který za posledních 5 měsíců udělal následující:

    - informoval své klienty o změně Sazebníku s více než měsíčním zpožděním
    - zdražil minimální roční náklady na vedení účtu s internetovým bankovnictvím o 720 Kč
    - k podané žádosti v listopadu 2003 (kompenzace 2x placených služeb při přechodu na "balíček") se do dnešního dne nijak nevyjádřil
    - přidání uživatele do svého internetového bankovnictví "zvládl" stylem, že manželce nebylo přiděleno ID, zato však k mému ID bylo přeřazeno její jméno
    - pravidelné nedodržování vlastního, právě platného sazebníku (poplatek za vedení platební karty, změna a zadání trvalého příkazu, vždy byla nutná reklamace přes Zelenou linku banky)
    - nabídne možnost kontokorentu, ale až při podpisu se dozvím, že je nutný souhlas manželky (nejde o ten souhlas, ale o to, že touto chybnou informací mě banka připravila o 2 hodiny času)
    - reklamace je expoziturou řešena až po urgenci

    A to vše bez jakékoliv snahy o kompenzaci těchto chyb ze strany banky, navíc podbarvené aktuální reklamou ředitelem této banky v hlavní roli.

    Bohužel, na tento účet mám navázány jisté aktivity a až do konce června 2004 jej musím držet.

    Jak byste se k takové bance zachoval vy?

    Těším se na odpověď,

    Viktor Hollmann
    1. 4. 2004 13:33
  • informace o zmenach

    kdyz doslo k onomu celkem nedavnemu nestastnemu a hojne komentovanemu zdrazeni vasich sluzeb, banka me neinformovala. po rozhovoru s pobockou se ukazalo, ze zprava byla rozesilana s vypisem z uctu. ja vypisy nedostavam, nepotrebuji je a nevidim duvod zbytecne platit za dalsi papir, ktery jenom vyhodim. zajimalo by mne, zda planujete, ze byste klienty meho "typu" /predpokladam, ze takovych je vic/ informovali jinym zpusobem - mailem, zpravou v netbance apod. pripada mi dost nefer ocekavat, ze si tyhle veci bude klient zjistovat sam - obvykle z novin nebo serveru typu mesec. take by nebyla na skodu moznost zaregistrovat si mailem informace o zmenach na vasem webu. treba info o vyse zminenem zdrazeni nebylo k nalezeni.
    30. 3. 2004 9:55
  • XML, odpovědnost, důvěryhodnost

    Když jsem Vás žádal o odpovědi na otázky pana Vejsady, měl jsem na mysli zejména tuto: "... prosím o zodpovězení otázky, proč za zneužití systému nese odpovědnost klient."
    Nehodlám zpochybňovat důvěryhodnost Živnobanky, proto, prosím, považujte následující odstavec za spíše teoretický.
    Co brání podepsaným Java Appletům v tom, aby jednoho krásného dne odeslaly zároveň s pravým příkazem k úhradě také příkaz falešný, s využitím soukromého klíče klienta. Jestliže by byly všechny (Vámi podepsané) applety vhodně načasovány, tvůrce onoho maligního kódu, toho času na Bahamách, by již jen přijímal platby na svůj bahamský účet.
    Z výše naznačených defraudačních důvodů Vás žádám o vyjádření k následující úvaze:
    Vyjdeme-li z obecného předpokladu, že vztah mezi bankovním ústavem a klientem je založen na důvěře, dále, že banka odpovídá za řešení zabezpečení, které nabízí klientům, že klient nese odpovědnost za zneužití systému a že si banka v žádném případě nemůže dovolit poskytnout nějaké nedůvěryhodné či neověřené řešení služeb, co brání bance prokázat naprostou důvěryhodnost jí poskytovaného software zveřejněním zdrojových kódů? Pak zajisté i ti největší skeptici si budou moci libovolně ověřit jejich funkci a beze stínu pochybnosti převzít odpovědnost za jejich používání.
    Mgr.
    29. 3. 2004 18:34
  • on-line platby platebni kartou

    Dobry den,

    1. jsem potesen, ze po intenzivnim stourani uzivatelu do pana Dolaka a spol. z vaseho helpdesku jste vzali na vedomi fakt, ze Microsoft musi skoncit se svou "Javou," ktera se po dobu sveho mrzkeho zivota musela temer kazdy mesic lepit kvuli kritickym bezpecnostnim chybam. Podivejte se do Microsoft Security Bulletinu. Zcela chapu nadseni predchozich tazatelu pro vase applety.
    Microsoft s ni vlastne mel skoncit uz pred tremi mesici, kdy jeste vase banka vubec nedavala uzivatelum jinou moznost, nez bezet deravy nastroj.

    Docela by me zajimalo, kolik klientu se od vaseho internetoveho bankovnictvi odvratilo po reportazi v Obcanskem Judu televize Nova, ktera oznacila cokoliv krome One Time Passwordu (dale OTP) a pouziti nezavisleho kanalu pro jeho doruceni za nedostatecne bezpecne. Asi to nebude vyznamny pocet, ale mate nejaka cisla?

    2. And now for something completely different. Zvazuje vase banka nabidku nejake platebni karty urcene pro platby na Internetu? Co me namatkou jako laika napada:

    • Moznost 1: Pokud pred provedenim transakce kartou na Internetu vyslovne bance nesdelim, ze se chystam provest transakci a v jake vysi, banka ji jednoduse nepovoli.
      Nevim, jak ostatnim ctenarum tohoto serveru, ale mne osobne by vubec nevadilo, kdyby ten system byl "pomaly". Jsem klidne ochoten si pockat treba 24 hodin, nez se nekde "preliji" udaje z nejake databaze do nejake jine databaze.
    • Moznost 2: V Netbance si pred transakci necham vytvorit cislo jednorazove virtualni platebni karty, se kterou provedu jednu transakci. Po provedeni transakce je virtualni karta "rozstrihnuta", takze ji nelze vice pouzit. Muze tak fungovat OTP, mohou tak fungovat vouchery do mobilnich telefonu, proc by tak nemohly fungovat platebni karty?
    Urcite existuji i jine cesty, jak zvysit bezpecnost klasickych karet VISA, ktere vydavate a na ktere jedine v zahranicnich internetovych obchodech s vysoce specializovanym zbozim slysi. Tezko donutim obchodnika za oceanem prijmout platbu vasi platebni branou. Ceske virtualni obchody me nezajimaji. Specialni software a odbornou literaturu, kvuli cemuz jsem vubec nucen neco kupovat na Internetu, tady ani nevedou a pro vsechno ostatni si v nasem vycuranem prostredi nevymahatelneho prava daleko radeji dojdu do skutecneho obchodu.

    Co vy na to?

    PS: Uz vubec samozrejme neberu vazne moznost takzvane doresit bezpecnost po vzoru Ceskoslovenske obchodni banky licomernou nabidkou doplnkove sluzby pojisteni. Viz podobenstvi o nejlepsim lekari.

    id
    27. 3. 2004 18:28
  • USB token

    Dobry den, mohl by jste nam sdelit, kdy ZB nabidne svym klientum ukladani certifikatu na USB token? Pripadne pokud jiz mate predstavu o cene. Dekuji. Stanek
    27. 3. 2004 12:35
  • autentizacni kalkulator

    Dobry den, jsem uzivatelem primeho bankovnicvti ZB a jsem pomerne spokojen. Je pro mne prekvapeni, ze by mela NetBanka chodit v Mozile. Urcite vyzkousim. Ale k memu dotazu. Uvazuje ZB, ze by nabidla take zabezpeceni pomoci autentizacniho kalkulatoru? Ktery by bylo mozne vyuzit pro jakykoliv kanal primeho bankovnictvi? Dle meho nazoru internetove bankovnictvi, ktere je zabezpeceno pomoci SSL protokolu neni az tak uplne mobilni ve smyslu vyuzitelnosti kdekoliv. Jiste navrhnete, ze to neni tak uplne pravda. Vim, ze je mozne protokoly mit napr. na diskete a v tomto smylu je pouzit. Ale prave toto je pro uzivatele urcite omezeni. Musi v jistem smyslu duverovat "cizimu pocitaci". Pokud by ZB tento kalkulator nabizela, jiste bych jej vyuzil. Byl by mozny pouzit i pri telefonickem bankovnictvi a odpadlo by zabezpeceni aktivnich operaci pomoci TAN. Jako priklad vyuziti a.kalkulatoru uvadim Ceskou sporitelnu a eBanku.
    Preji hezky den. Stanek
    26. 3. 2004 9:19
  • XML, odpovědnost

    Připojuji se k prosbě pana Poslušného co se týká odpovědi na můj původní dotaz. Domnívám se, že zde dochází k nepochopení základních principů asymetrické kryptografie. Ve své odpovědi píšete, že banka zodpovídá za použité bezpečnostní řešení. OK, banka nabizí elektronické bankovnictví zabezpečené asymetrickou kryptografií zřejmě X.509, ale bez jakékoli dokumentace. Klient je nucen používat software banky (JavaApplety), které však pro klienta bezpečné nejsou, protože nad nimi nemá kontrolu. Klient neví, co tyto JavaApplety dělají. Pokud banka prohlásí, že pouze podepisují dispozice, které si klient přeje podepsat, je to tvrzení, které není doložitelné. Klient tomu může věřit, ale nemusí. Pokud se rozhodne tomu věřit, nastává situace prakticky ekvivalentní tomu napodepisování bianco dispozic, o kterém se zmiňuji. Klient se totiž nemůže přesvědčit, že ony JavaApplety dělají opravdu jen to co mají. Třeba z důvodu "ochrany klienta" odesílají soukromý klíč klienta do "bezpečného uložiště" v Redmondu nebo do banky. Nevím, pravděpodobně tomu tak není, ale to je právě ono - můžeme se o tom jen dohadovat, nemůžeme se o tom přesvědčit. Naproti tomu kdyby existovala dokumentace jak provést třeba příkaz k úhradě, mohl by se klient rozhodnout, zda využije software nabízený bankou (JavaApplet), nebo zda nabízenému software věřit nebude, napíše si příkaz k úhradě ve svém oblíbeném textovém editoru, podepíše jej svým oblíbeným kryptografickým softwarem a odešle do banky svým oblíbeným prohlížečem, e-mail klientem apod. Tak jak to má např. udělané Ministerstvo financí pro daňová přiznání k DPH. Vytvoří se XML soubor (s daňovým přiznáním, s příkazem k úhradě), dále se podepíše (programem dle volby klienta) a postne webovým prohlížečem na určitou adresu (https://netbanka.cz/input), třeba.

    Asi namítnete, že o toto klienti nemají zájem, je to pro ně příliš složité a nikdo by to nepoužíval. To však není pravda a můžete si dovodit z této diskuse, že by to používal minimálně pan Poslušný a já, jistě i další. Dokonce si troufám tvrdit, že by kvůli tomu Živnostenská banka získala další klienty z řad těch více technicky zaměřených či těch, kterým opravdu na zabezpečení záleží. A přitom by to nikterak neomezilo ty klienty, kteří bance zcela důvěřují a chtějí použít JavaApplety banky, které by udělaly naprosto totéž. Stačilo by to jen zdokumentovat.

    Dále píšete, že klient má výraznou možnost ovlivnit bezpečnost správou přístupových kódů a zabezpečením počítače. Je zcela zjevné, že klient si musí svůj soukromý klíč chránit. Sám si své klíče samozřejmě chráním. Dokonce si je chráním natolik, že je odmítám svěřit JavaAppletu, o kterém nic nevím a z tohoto důvodu také Netbanku nepoužívám. Pokud banka obdrží dispozici podepsanou soukromým klíčem klienta, pochopitelně nebude už dále nic zkoumat, považuje dispozici za ověřenou. Je to opravdu věcí klienta, jak si zabezpečí svůj počítač a jak si bude chránit svůj klíč. Banka s tím nemůže nic dělat.

    Pokusím se to ještě jednou trochu shrnout (budu v tomto příkladu používat program OpenSSL, neboť sám tomuto programu zcela důvěřuji a je k dispozici se zdrojovými kódy a každý si tedy může ověřit, co ten program skutečně dělá):

    1 - Banka specifikuje, jak má vypadat žádost o certifikát. Klient si pomocí OpenSSL či čehokoli jinéhu vygeneruje žádost o certifikát a předloží ho bance k podepsání. NEBO udělá totéž za použití JavaAppletů klikáním v prohlížeči.

    2 - Klient si napíše v textovém editoru příkaz k úhradě, podepíše ho pomocí OpenSSL, vytvoří PKCS7 strukturu a tuto postne na https://netbanka.cz/input NEBO udělá totéž za použití JavaAppletů klikáním v prohlížeči.

    3 - Klient si chce prohlédnout svůj vypis z účtu - stahne si wgetem čí čímkoli jiným z adresy https://netbanka.cz/vypisy/cislo_klienta/vypis.pem, pomocí OpenSSL ho dešifruje a prohlédne si ho. NEBO udělá totéž za použití JavaAppletů klikáním v prohlížeči.

    atd.

    Přičemž - bezpečnost celého systému není pro banku ani pro klienta nikterak snížena.

    Omlouvám se za poněkud delší formulaci, ale snažím se to vysvětlit co nejvíce polopaticky, aby byl základní princip pochopen. Nikde v České republice jsem se zatím nesetkal s tím (až na velmi málo výjímek, které se bohužel netýkají bank), že by byl systém komunikace popsán a že by klient věděl co vlastně dělá. Nezlobte se na mě, ale jestliže soukromý klíč klienta si čtou JavaApplety, byť třeba 3x podepsané VeriSignem a spol., klient si nemůže být jist, co se s jeho soukromým klíčem děje.

    Velice si vážím toho, že zde odpovídáte na dotazy nevyhýbavě a cítím, že je zde jakási šance pochopení situace a že se ŽB stane první bankou s opravdu bezpečnou komunikací.
    26. 3. 2004 8:49
  • XML, odpovědnost II

    Můžete, prosím, odpovědět na všechny otázky pana Vejsady, které položil 23.3. v 8:19 v příspěvku s titulkem 'XML, odpovědnost' - i mne jako Vašeho klienta tato problematika velmi zajímá.
    Mgr.
    25. 3. 2004 11:10
  • SUN Plugin

    Mám dotaz týkající se využití JAVA Pluginu od spol. SUN. Při pokusu o přihlášení do Netbanky se mi zobrazí následující chyba. Můžete mi poradit v čem je problém ?

    Warning: Class iaik.security.dsa.DSA not found!
    (java.lang.NoClassDefFoundError: iaik/security/dsa/RawDSA)

    Warning: Class iaik.security.dsa.DSAKeyPairGenerator not found!
    (java.lang.NoClassDefFoundError: iaik/java/security/interfaces/DSAParams)


    java.security.AccessControlException: access denied
    (java.util.PropertyPermission * read,write)

    at java.security.AccessControlContext.checkPermission(Unknown Source)

    at java.security.AccessController.checkPermission(Unknown Source)

    at java.lang.SecurityManager.checkPermission(Unknown Source)

    at java.lang.SecurityManager.checkPropertiesAccess(Unknown Source)

    at java.lang.System.getProperties(Unknown Source)

    at iaik.security.provider.IAIK.a(Unknown Source)

    at iaik.security.provider.IAIK.addAsProvider(Unknown Source)

    at bsc.security.Secto.init(Secto.java)

    at java.lang.Class.newInstance0(Native Method)

    at java.lang.Class.newInstance(Unknown Source)

    at sun.applet.AppletPanel.createApplet(Unknown Source)

    at sun.plugin.AppletViewer.createApplet(Unknown Source)

    at sun.applet.AppletPanel.runLoader(Unknown Source)

    at sun.applet.AppletPanel.run(Unknown Source)

    at java.lang.Thread.run(Unknown Source)
    24. 3. 2004 17:27
  • Podněty k Netbance

    Je nějak možné zadat do Netbanky výpověď vkladu ze spořícího (depozitního) účtu? Uvítal bych i možnost zadat svolení k inkasu přes rozhraní NetBanky. Dále se přimlouvám za už zmiňovanou možnost vytvořit a uložit šablony platebních příkazů a výpisy z účtu v delší periodě než 90dní k odeslání mailem).

    Nechystáte nějakou formu komunikace s NetBankou E-Mailem šifrovaného podpisovým certifikátem (např. možnost poslat si výpis z účtu v XML formátu, který lze importovat např. do GNU Cash nebo účetního programu)?

    Je nějak chystána podpora PDA a handheldů (jmenovitě Palm OS)? K tomu by se právě hodila offline komunikace např. E-mailem.

    Poslední připomínku mám ke zpoplatnění NetBanky a ost. služeb veškerá nová cenová politika směřuje pro náročné zákazníky, neexistuje program pro běžného spotřebitele na úrovni průměrného příjmu. Vydávat cca1% ročních příjmů za uložení peněz v bance je nejen na české poměry příliš zvlášť je-li výnos z úroků takto uložených peněz zanedbatelný. Mnoho neřeší ani balíčky os. konto - cena 1180,-(1800,-)Kč je příliš i na poměry EU a cenu nevyváží ani "lepší" karty s pojištěním - ne každý je potřebuje. Běžné bank. služby nejsou luxusní záležitost, používá je každý, dřívější cenová politika (málo poboček a el. přístup) odlišoval Živnobanku od ostatních našich bank. V okamžiku kdy někdo nabídne standartní ceny jako v EU, odejdu od ŽB.
    24. 3. 2004 7:44
Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).