Názory k článku
Jsou vaše peníze u Citibank v bezpečí?

Není to první dírka, která se u Citibank objevila.

doufam, ze eBanka nema podobne programatory ...

Nedelal bych si iluze ... nejen u eBanky ...

Pri praci na DirectPay jsem podobnych veci videl vice a Citi to bylo oznameno. Jak vidim tak se asi nic moc nestalo.

Nicmene ebanka ma, nebo alepson mela take par radku "kvalitniho" kodu. Napriklad pokud jste behem autorizace platby proces prerusili, platebni brana stejne nahlasila, ze platba je OK.

Nejsem si 100% jistý, ale dělá to tuším i nadále. Proto musí obchodník vždycky žádat i potvrzení emailem o proběhlé platbě, jinak by také mohl splakat nad výdělkem. Vzhledem k tomu, že za to potvrzení se také platí, přibydou eBance k tomu 1% ještě další penízky navíc... proč by to měli spravovat? ;-)

Pojmy a dojmy. Platebni portal eBanky (https://klientX.ebanka.cz/ebts/owa/shop.payment?shopname=XXXXXX....) pokud se nepletu, NIKDY nemel slouzit k tomu a by po zadani platby okazite rekl, zda byla nebo nebyla transakce provedena. Jedina informace kterou online poda je ta, ze prikaz k uhrade byl uspesne prijat (zadán a autorizován). To jestli se platba diky nedostatku prostredku, blokaci na uctu nebo z jineho duvodu provede nebo neprovede je uz vec jina. Pokud imlementujete tento portal do svych obchodu, zcela jiste byste to meli vedet. Email (SMS, FAX), ktery vam potom eBanka posle uz informuje o uspesne realizaci platby. Takze ctete, jinak splacete... :) ...a pokud i tak mate pocit ze dostanete agreement i presto ze platbu prerusite, meli byste konfiguraci sveho shopu reklamovat (chyba mezi zidli a klavesnici). Good luck :)

Milý Saláme, milí spolužáci, maminko a tatínku, vážení smuteční hosté, i ty Petříčku ve třetí řadě, přátelé, kolegové, soudruzi, bratři a sestry, dámy a pánové i ostatní zaměstnanci eBanky

Jak bych Vam to vysvetlil. Snad takto. Platebni brana eBanky nahlasi, ze je autorizace OK, neplest si prosim s provedenim platby ci skutecnym prevodem penez, i tehdy pokud pokud uzivatel cely proces utne v prubehu autorizace. Tzn. uzivatel si nakup rozmyslel a pri autorizaci proces zastavi. Obchodnik se dozvi, ze vse probehlo OK. A muze se jen divit, ze nejsou penize na jeho uctu.

To co tady mily Salame pises je prave tebou zminovane zameneni pojmu za dojem. Implementaci mame za sebou mnoho takze vime o cem mluvime. Priste prosim mlc, kdyz se bavi dospeli chlapce, treba se dovis neco zajimaveho.

P.S: A nauc se prosim podepisovat, ve slusne spolecnosti je to zvykem. Udelejete si u Vas v jeskyni den evropske kultury.

proc se citite hned urazen (tedy citim to tak) to nechapu. Nicmene nevidim duvod proc se chlubit s informace jako moje jmeno, prijmeni, rodne cislo, cislo obcanskeho prukazu a bot nebo treba email do zamestnani, ktere vam stejne k nicemu nejsou. Preji Vam jeste vice uspenych implementaci... Ackoli udela-li vas to spokojenejsim klidne Vam zaslu email se svym jmenem a prijmenim, nicmene nevidim duvod proc takove udaje vystavovat na kazdem WEBu, aby je robot kdejakeho spamera vyzobal a zasoboval me emaily o ktere nestojim. Diky za pochopeni.

Nejsem urazeny, ale v pondeli rano me proste takovy prispevek dokaze dohnat k sarkastickemu prispevku. Nic ve zlem :))))

Posílal jsem redakci článek v text/plain a nenapadlo mě, že to tam fouknou
jen tak... takže tam chybí kusy kódu za znakem menší než ... :(((
O.

Tak ho dejte alespon do fora.

Kdyz si date zobrazit zdroj stranky, krasne to uvidite :-)

Diky. :o)

puvodni smycka citybank:
for(i=vlen;i<leng;i+=16)
strncat(trans,str_bin+i,1);

upravena optimalizovana smycka:
if (leng>=8000)
exit(1); /* spatna vstupni data */
for(i=vlen,j=0;i<leng; i+=16, j++)
trans[j] = str_bin[i];
trans[j] = 0;

O.

Pokud snad s touto bankou nejste spokojeni,muzete zcela jednoduse odejit do jine.Ja osobne pouzivam vetsinou Royal Bank.

nejlepsi je Slamnik Bank!

to urcite potvrdi vsichni jejichz slamniky dnes vesele plavou nekde v severnim mori :)

Ac tento prispevek nekdo podepsal "JiKos", rad bych se od nej distancoval.

Ac tento prispevek jsem sam podepsal Solvina, rad bych se od nej distancoval.

Naznacovani, ze kvalita softwaru v nejake bance je lepsi nez v jine (ve ktere vime, ze je velmi spatne) se prudce blizi trestnemu cinu sireni poplasne zpravy ... ;-)

Ve spolecnosti existuje, nikdo vlastne presne nedokaze vysvetlit proc, presvedceni, ze banky jen proto, ze spravuji cizi penize, dbaji na kvalitu kodu v nejake obzvlaste zvysene mire oproti jinym naprosto beznym komercnim uzivatelum software. Pro takovou domenku ale skutecne neexistuje sebemensi duvod ...

Naopak, v bankach plati uplne stejne jako kdekoliv jinde, ze oblibeny je takovy programator (pripadn eexterni programovaci firma), ktery(-a) doda svou praci rychle a lacino. Jak tady nekdo poznamenal na jinem miste - programator, ktery programuje o tretinu pomaleji, protoze provadi audit kodu tak, aby jim dodavany kod neobsahoval chyby nebude patrit mezi zamestnavateli k nejoblibenejsim. C'est la vie ...

Mozna je to nejaka vychodni filozofie, protoze jsem pred casem mel tu pochybnou cest opravovat zdrojaky jedny firemni utility, ktera vznikla tusim na Taiwanu. Clovek, kterej to psal, jednak asi znal C jen z doslechu a krome toho ho nenapadlo, ze by treba na radku ve vstupnim textovym souboru nemusela bejt ani jedna mezera. Diky tomu jeho vyhledavaci smycka behala obcas po cely pameti a semtam neco prepsala - tu dato, tu kus kodu:-)

Myslim, ze to neni vychodni filozofie ani filozofie 1 banky. Filozofie je takova, ze zakaznik(banka) nebo zamestnavatel(banka) to chce co nejdriv, co nejlevneji, pripadne aby to dobre vypadalo. Takze spominany programator, ktery programoval pres noc a po 10 kafich bude pochvalen, jak je snazivej a ten kterej bude travit tyden navic treba auditovanim kodu si moc pochval nevyslouzi. Neni to ale pak chyba programatoru, ze to delaji jak to delaji, reagujou jenom na poptavku. A pokud se nestane nejakej hroznej prusvih, pochybuju, ze se pozadavky pri vyvoji systemu zmeni. A pote se mozna taky nezmeni, pokud se nezmeni mnozi IT odbornici v ruznych institucich (ti kteri prave vytvareji pozadavky).

Ave,
trochu me zarazila jistota, s jakou autor clanku ukoncoval retezec na konci sve opravy:
trans[j] = 0;

Nejsem zadny C-guru a tak, pokud se mylim, me omluvte. Ziju v domneni, ze dle standardu neni jasne, jake hodnoty budou mit ridici promenne cyklu po jeho skonceni. Ve vetsine pripadu by to mohlo fungovat, ale zrovna u bankovni aplikace bych si to NIKDY netroufnul zarucit. Uz nejednou jsem se setkal s kompilatorem, ktery si for cyklus zoptimalizoval a misto for (i=0;i<z;i++) provadel v podstate for(i=z;i>0;i--) .. dusledky takove optimalizace by byly v tomto pripade fatalni a myslim, ze chyba by byla na strane programatora.

Jinak co se tyce eBanky, tak pokud se neco nezmenilo, tak jeji vnitrnosti nejsou napsany v Cecku - coz neznamena, ze tam nemohou byt daleko horsi zverstva.

/ Lukas Suchanek

AFAIR to zrovna v C zaručeno je. Na rozdíl od třeba Pascalu. Ty optimalizace, které zmiňujete, (a mnohdy i daleko horší) kompilátor provede pouze v případě, že ví, že si to může dovolit (což je v tomto případě asi jen když to i uvnitř cyklu vůbec nepoužijete). Kdyby náhodou ne, chyba by byla na straně překladače (a programátora taky, že si toho při ladění nevšiml).

Podle mne (ale už léta v C neprogramuji) v C může programátor skutečně počítat s tím, že v řídící proměnné cyklu je během cyklu i po jeho skončení to, co předpokládá, že tam je.

Dokonce mám (už dosti matný) dojem, že s tím může počítat i v Borland Pascalu. (Což je poslední Pascal, ve kterém jsem programoval, ale to je ještě více let. :-)

(Abych opravil Michala Kubečka - Lukáš Suchánek nepsal o hodnotě řídící proměnné BĚHEM cyklu, ale PO SKONČENÍ cyklu.)

Nicméně, kód vypadá takto:

if (leng>=8000)
exit(1); /* spatna vstupni data */

for(i=vlen,j=0;i<leng; i+=16, j++)
trans[j] = str_bin[i];

trans[j] = 0;

Cyklus je natolik komprimovaný (efektivní? možná - ale optimalizátoru to asi nepomůže), že není hned vidět, že řídící proměnnou je i, nikoliv j.

Možná by bylo vhodnější to napsat takto:

j = 0;

for(i=vlen;i<leng;i+=16) {
j++;
trans[j] = str_bin[i];
}

trans[j] = 0;

Takhle je hned jasné, co se kdy provede. A je to jasné stejně tak kompilátoru, jako člověku.

Bohužel, chyby s přetečením bufferu jsou v C programech naprosto běžné. Jsou ve spoustě programů, i ve slavných "velkých" aplikacích slavných firem. Troufl bych si říct, že těžko najdete aplikaci napsanou v C o alespoň miliónu řádků, kde by nějaká taková chyba nebyla.

Ten cyklus je spíš komprimovaný ;-), hlavně šlo o to, aby se v každé iteraci nedělal strncat().
O.

Jasně. Mně šlo zase hlavně o to, že když někdo vyvine aplikaci v C a není to open-source, tak se pak musí snažit, aby se její kód nedostal ven, protože nějaké díry se tam najdou skoro vždycky. (On někdy stačí disassembler.)

Sice se dají stanovit normy pro psaní kódu a existují nástroje, které v kódu hledají místa podezřelá z buffer-overflow, ale stoprocentní to nikdy není.

Když se podíváte na stránky podpory velkých softwarehousů, snadno tam najdete info o podobných chybách. A týká se to i firem, které mají image prvotřídní bezpečnosti.

Tady je obrovská výhoda Javy, .NET a podobné zvěře.

A přitom není problém dodržovat pár základních pravidel, případně
si napsat nějaký/použít wrapper na práci s řetězci a je to ;-).

U jazyků platformě nezávislých (tedy interpretovaných ať už je to bytecode nebo přímo zdroják) zase hrozí nebezpečí v implementaci interpretu a ty většinou píšou zase ony velké software houses, nicméně u lidí kteří píšou kompilátory/interprety se dá předpokládat, že na tom budou znalostně poněkud lépe... ale spolehnout se na to taky nedá...

U OpenSource se dá alespoň trochu doufat, že si ten zdroják někdo prohlídne dřív než to někdo naboří...

O.

Mozna je chyba prave v tech "predpotopnich" null-terminated stringach v Ccku ;-)

O použití uvnitř cyklu jsem psal v souvislosti s otočením směru iterací (je pravdou, že na to, abych si to mohl dovolit, potřebuji řídící proměnnou nepoužít nejen během, ale ani po skončení cyklu).

Jinak uvedená ukázka je názorným příkladem toho, že mluvit u cyklu for v C/C++ o nějaké řídící proměnné obecně dost dobře nejde.

no vy jste tomu pomohl! zatimco v puvodni verzi byla jasne oddelena cast inicializacni, cast podminkova, cast vykonna a samotne telo cyklu, tak vy jste je pomichal a udelal z toho gulas, cehoz dukazem je i to, ze vas cyklus pocita chybne j - misto od 0 ho pocita od 1. jinak zapomente na to, ze by for v cecku melo nejakou ridici promennou - s tim si nema cenu trapit hlavu, for ma proste ukoncovaci podminku, ktera byla i v te puvodni verzi jenom jedna. jedine co bych te puvodni verzi vytknul by bylo na muj vkus prilisne setreni mezerami.

Hm, máte pravdu, j se mělo inicializovat na hodnotu 1, tam mám chybu. Jenomže to jenom ilustruje, jak je ten původní zápis nepřehledný.

Ukončovací podmínku mají i jiné cykly, než for. Čím se tedy liší for od jiných typů cyklu?

Čím se liší "část výkonná" od "samotného těla cyklu"?

Není náhodou tato "část výkonná" jenom "koncem samotného těla cyklu"?

Není náhodou "samotné tělo cyklu" jenom "něčím, co se nemůže dát do části výkonné, aby alespoň něco bylo v samotném těle cyklu a specifikaci bylo učiněno zadost"?

> Ukončovací podmínku mají i jiné cykly, než for. Čím se tedy liší for od jiných typů cyklu?

Na to je jednoduchá odpověď: ničím ;-), resp. liší se pouze syntaxí,
tedy tím, že je to všechno pohromadě, nicméně ekvivalentí zápis uděláte i pomocí while() { }

> Čím se liší "část výkonná" od "samotného těla cyklu"?
Tím, že je to všecho hezky nahoře pohromadě.

> Není náhodou tato "část výkonná" jenom "koncem samotného těla cyklu"?
ANO

> Není náhodou "samotné tělo cyklu" jenom "něčím, co se nemůže dát do části výkonné, aby alespoň něco bylo v samotném těle cyklu a specifikaci bylo učiněno zadost"?

Nejspíš ne, protože přes operátor "," (čárka) asi nepůjde udělat úplně všechno... i když mě zrovna teď nic nenapadá ;-), ale co si budem povídat byl by to hnus... ;-)

Navíc do části výkonné by měly přijít pouze jednoduché věci, které ovlivňují chod cyklu... (z hlediska přehlednosti kódu.)

O.

No bezva, takže souhlasíte s tím, že cyklus for v podání C je jenom komplikovanější a nesrozumitelnější způsob zápisu cyklu while (i ta podmínka není vlastně "ukončovací", ale "pokračovací", protože dokud platí - while - cyklus pokračuje).

Takže když vyslovím hypotézu, že cyklus for je vhodné používat jenom tehdy, když máte nějakou řídící proměnnou, tj. nějaký counter, který inkrementujete nebo dekrementujete - budete s tím souhlasit?

S tim ja nesouhlasim. Bezne se v C++ pouzivaji iteratory stylem

for (iter.start(); !iter.done(); iter.next()) {
...
}

a prijde mi to daleko prehlednejsi nez to delat pomoci while.

Takže i a j ve zde diskutovaném příkladu jsou iterátory?

Ne, ja se jenom s vama hadam, ze for je pouzitelny a vhodny i bez ridici promenne. ;-)

Řídící proměnná je iterátor - je to prostě jednoduchá implementace iterátoru. Proto jsem vás chtěl dostat k tomu, že i a j jsou řídící proměnné.

Ale ono je to ještě jinak a teď mi to došlo. To co je v závorce za "for", je implementace iterátoru. Takže iterátor není i nebo j, ale celý obsah té závorky.

Takže vám ctění kolegové dávám za pravdu a děkuji za objasnění. Když se na to člověk umí dívat takto, je použití cyklu for v podobě uvedené v článku přehledné.

Pro velmi jednoduché iterátory je skutečně rozumné používat zápis:

for (iterátor)
příkaz

A pokud je to zvláště jednoduchý případ

for (i = 0;i < 10;i++)
příkaz

můžeme i považovat za iterátor a tedy i za řídící proměnnou - a není to nesmysl a není to "zatěžování hlavy".

Ikdyz v tomto pripade samozrejme o inkrementovani nejake promenne v principu jde.
Ale dovedu si rovnez predstavit daleko slozitejsi cykly for a urcite jsem je nejednou pouzil.
for v C/C++ zkratka neni synonymem pascalovskeho cyklu for, o dalsich jazycich nemluve...

Ohledne 'Borland Pascalu' - dnesniho Object Pascalu (Delphi 6) je hodnota promenne pouzite ve smycce na konci nedefinovana (viz dokumentace). Pri pokusu o pouziti teto promenne po skonceni smycky dostanete pri kompilaci warning: [Warning] xxx: FOR-Loop variable <name> may be undefined after loop

Troufam si tvrdit, ze zmenit takto vyznam cyklu je mozne jen v naprosto jednoduchem pripade a ve vetsine pripadu si to kompilator nedovoli, protoze bud na to jeho inteligence nesaha a nebo zjisti, ze nesmi. Pokud bychom se nemohli spolehnout ani zakladni paradigmata tak bych tech kav denne vypil asi tolik, ze za tyden by me mohli prazit na kavu nove znacky... - jednoduse - netvrdim, ze to nikdy kompilator nevyprodukoval, ale 99% pripadu to nezbasti a nebo je v nem hodne zasadni chyba... BTW kdyz uz jsme u toho, jak se po strance taktu lisi JMP if ZERO nebo JMP if Equal (hodne chytry optimalizator to pro X (iteraci) < nez vhodna konstanta rozvede...:->)? Mne to prijde ekvivalentni, takze o jake 'optimalizaci' hovorite?

No mel jsem tu cest programovat neco nad SETem v podani MUZO, mohu rici, ze sice vysledek byl funkcni, ale asi tak 40% specifikace si musel clovek domyslet... hlavne ze to melo asi tak 40 stranek ve Wordu, prisernou typografickou upravu, spoustu vomacky a kecu okolo, ale opravdu zasadni udaje pro programatora (a ze to byl skutecne dokument zvany Reference guide for programming.... (bla bla bla..)) tam chybely...

Na druhou stranu ne ja, ale kolegove meli tu cest delat neco napr. s puvodnim Juice Eurotelu, jak se vyjadril - ani halir by pres to neposlal... zrejme vedel proc...

Takze tech radoby dokonalych bastlu v republice je daleko lepe (navic kdyz se clovek obcas dostal v techto 'velkych' firmach operujicich s minimalne stamiliony korun k tomu, jak zpracovavaji data (namatkou Komercni banka, Ceska posta), doslova a do pismene trpel uz na pohled) a skutecne cest vyjimkam. Proti eBance nemohu rici nic vice, nez ze jsem nezaznamenal uspesny hack jejich systemu, Vy ano?

nejsem ani assembler guru, ale toliko si snad z hodin assembleru pamatuji, ze odcitani je rychlejsi nez pricitani, takze predpokladam, ze kompilatory podobne optimalizace delani nikoliv kvuli podmince same, ale kvuli zmene ridici promenne. Ale .. neni tohle uz diskuse na jine tema nez o jakem je clanek :-) ?

No je to sice dost off-topic, ale prinejmensim na i80x86 to neni pravda. Scitani je stejne rychle jako odcitani.

Ekvivalentní to není, test, jestli je i různé od nuly (nebo kladné) je jedna instrukce, na test zda je i různé od z (nebo menší než z) potřebujete dvě. Před tím je totiž musíte dát ještě test. Nehledě na to, že můžete na x86 použít přímo instrukci loop, která je opět o něco rychlejší.

Zapomente na pojem ridici promenna cyklu, v C nic takoveho neni. Jen ukoncovaci podminka cyklu. Optimalizator muze v zasade cokoli, ale nesmi zmenit smysl kodu. Takze napriklad:

for ( i = 0; i < 10; ++i ) ;

muze nahradit jako

i = 9;

Vas priklad samozrejme take, ale ne vzdy:

for ( i = 0; i < z; ++i ) {
if (Something[i]) {
break;
}
}

by mel prochazet vzdy od zacatku. Aspon doufam :-)

Hodnoty promennych po ukonceni cyklu maji spravnou hodnotu a bezne se pouzivaji. Vyjimkou je C++:

for ( int i = 0; i < N; ++i ) {
...
}

kde promenna i neni mimo telo cyklu pristupna. Bohuzel, spravne to umi az nejnovejsi verze prekladacu, starsi pristup umozni.

(hmm, proc to zere mezery na zacatku radku?)

Ta prvni nahrada ma byt samozrejme i = 10; Ach jo. Jeste ze zrovna nepisu optimalizator...

Az na kompilatory jedne nejmenovane firmy, kde ma promenna i platnost i po skonceni cyklu. Ale mozna uz to je v nove verzi jinak.

No, ono je asi špatně hlavně to, že tohle všechno musíte vědět, abyste s tím mohli rozumně pracovat. Proto je programování takový problém, jaký je. (A neříkejte, že není. :-)

Tohle zrovna není dobrý příklad, pokud píšete programy s přesvědčením, že překladač vyhovuje normě, pak si chyby ani nevšimnete (protože vás vůbec nenapadne tu proměnnou za cyklem použít).

Ano, je to jinak a posledni verze (no.13) od jedne nejmenovane firmy to ma konecne spravne ;-)

Nebyl bych si tak jistej tou prvni nahradou - co kdyz je i float, ne integer?

mas pravdu, vse na cem zalezi je ORACLE PL/SQL, bizuterie okolo je Delphi, MSVC, Perl, ...

Programuji eshop s platbami a citibank je zarucene nejhorsi. Napriklad uz jim nekolik tydnu nejede server pro overovani plateb... Jsem rad ze vetsina karet ma defaultne zakazany platby pres internet, jinak by vznikala spousta podvodu.

Muzete mi rici, jak jste na to prisel, ze nejde server pro overovani plateb ? Vcera jsem zaplatil pres jednoho obchodnika a platba byla autorizovana bez problemu. Doporucuji si nejdriv overit, jestli neni chyba na vasi strane nez neco takoveho napisete verejne ....

Server citibank, na kterem testuji, jiz nekolik tydnu nejde, vraci chybovou hlasku 92, nebo jak to je, MACHINE DOWN...

aha, sice nevim, co a jak testujete, ale vim, ze ja jsem byl presmerovan na Platebni branu, ci jak tomu rikaji a zaplatil jsem.... Vysledek autorizace - Autorizovano... To mi neprijde jako MACHINE DOWN :-))

Již při vzniku aplikace mojebanka jsem programátory upozorňoval na možnost vykradení účtu mnou popsaným způsobem a jejich závěr byl, že sice možnost takového způsobu vykradení účtu připustili, ale nic se stím nakonec nestalo.

Naopak jsem jasne rekl,ze kdyz se Vam nelibi service jedne banky,tak pochopitelne muzete jit do jine,tak jak je to jezde na zapade udela zcela normalne myslici clovek ,ani o tom nemusi uvazovat a rozhodne o tom nemusi psat dalekosahle clanky.Priste me prosim usetrete vsech vice nez naivnich nazoru a pripominek.

Vážený!

Jak má laik vědět, že je aplikace pro vzdálený přístup k účtu děravá? Bankovními úředníky je klient při uzavírání smlouvy ubezpečován, že je vše O.K. Řekněte mi, kolik klientů bank si přečte tento nebo podobný článek a zda se vlastně klient banky používající služeb vzdáleného přístupu k účtu má po takových článcích pídit, jestliže asi zcela normálně myslící člověk - mám-li použít Vámi použité slovní spojení logicky asi očekává, že pro bezpečnost je uděláno maximum.....

Cela podstata je v tom, ze pokud diky chybe banky nekde zmizi penize tak to zatahne banka, ne vy. A chyba banky to je apriori vzdycky pokud zakaznik neprizna ze to byla chyba jeho anebo pokud vysetrovatel banky neprokaze chybu zakaznika. Takze chyby v aplikacich bank muzou zpusobit neprijemnosti (s vymenou karet a pod.) ale to je taky vsechno co muzou zpusobit. A jak tu podotyka skoro kazdy - ostatni banky na tom nejsou o moc lip, i kdyz je fakt ze Citi je opravdu lahudka.

Tim bych si nebyl tak jisty ani v Americe, natoz v Cechach...

No, ja bych si zrovna timhle byl docela jisty i v cechach. Tezko bude banka zakaznikum rikat - "My sme meli chybu v SW tak ted mate na uctu o par tisic min a nemuzete s tim vubec nic delat." Rozdil je v tom kdo by to zaplatil, ve statech banka (pripadne FDIC), v CR stat penezi danovych poplatniku.

A co kdyz o chybe vi jen par lidi? Ty to daji do novin, banka mezitim chybu potichu opravi a novinari pak jen konstatuji, ze banka je bezpecna?
Jeden konkretni pripad je na http://underground.cz/784 .
Zacalovat klienty neni nic prijemneho, navic se toho chyti konkurence... A nerikejte, ze u soudu by jste mel proti bance sanci.

Vypadá to, že článek někdo ze Citibank četl, protože na adrese
v článku se už zdrojáky nenacházejí.
O.

Tak jsem si dnes založil konto u Citibank. Možná bych to nedělal, kdybych si předtím přečetl tento článek a reakce. Na druhou stranu jelikož chci konto používat jen pro běžné drobné platby, tak v tom nevidím problém. Podle diskuze výše je myslím téměř jedno, kterou banku pro takový účet zvolit.
S pozdravem,
průměrný uživatel.
PS: U jakého ústavu byste si ho založili (ho máte založený)? A proč?

Treba ja jsem si zalozil ucet u Zivnobanky. Dulezite pro mne byl vcelku funkcni internetbanking (ackoliv je - doufam "zatim" - omezen na MSIE s uzivatelem prihlasenym s administratorskymi pravy), solidni jmeno banky, nizke poplatky (ucet me stoji rocne 950 za VISA Classic kartu + cca 100Kc rocne za vedeni uctu, vypisy, internet banking a zonu 24 nebo jak se to jmenuje). Jsem u teto banky od zari lonskeho roku a zatim si nemohu stezovat, potreboval-li bych dalsi ucet, sel bych zase do ZB.

Castecne souhlasim, taky mam ucet u Netbanky, pouze se zastavuji u formulace "vcelku funkcni". ja jsem marne zkousel verit jejich Netbance vice nez rok. Prvni hesla pro vygenerovani certifikatu jsem dostal s PREHLASOVANYM pismenem a jak jsem zjistil na kontaktnim telefonu, nebyl jsem sam. Celkem jsem za 9 mesicu zadal o vydani hesel 4x. Pokazde jsem musel na pobocku, ktera mela otevreno od 9.30 do 16.30.... Pri posledni serii hesel jsem se opravdu snazil a zadal naprosto stupidni heslo typu "strom1" , hned jsem si prihlaseni asi 10x vyzkousel a s dobrym pocitem, ze to bude konecne fungovat jsem vypnul PC. Druhy den rano jsem se pokusil prihlasit znovu a co myslite - spatne heslo... Pak uz jsem to nezkousel a radsi si nechal vydat kartu do samoobsluzne zony... Ta je bez problemu, pokud nepocitam, ze terminaly jsou obcas off-line.**Jeste ke karetnim limitum - ja chtel jen debetku, dosel jsem na pobocku a zazadal o ni - zpusob stanoveni vyse karetniho limitu me sokoval - slecna mi sdelila, ze v tuto chvili mam na ucte 7000, muze mi tedy nabidnout limit 3500 a tento limit jeste musim rozdelit mezi hotovostni a platebni cast (obchodnici). Zadne prumerne zustatky, prutoky na ucet, nic nepomohlo. Nakonec jsem nepomerne vyssi zustatky zacal prevadet pryc, protoze jsem nemel moznost s nimi manipulovat.. Ale to jsou jen drobne postrehy, souhlasim s puvodnim nazorem, ze je to banka levna, pomerne moderni a vcelku spolehliva... Kuprikladu i vypisy chodi velice pravidelne a vcas...

Tak takovy problem jsem opravdu nemel. Dokonce jsem ztratil certifikaty a tak jsem pozadal o novy pristup k CA. Obe obalky prisly (dokonce mam dojem, ze zadarmo). Problem byl v tom, ze po vygenerovani certifikatu pri jeho ukladani spadl IE. Tak jsem volal do banky a po overeni moji identity (samozrejme stylem rodne cislo apod.) tam neco "odskrtli" a to jednorazove jmeno/heslo pro pristup do CA mi na dalsi pokus opravdu zafungovalo. To by mne nenapadlo, jake s tim nekdo muze mit problemy.
Tim vcelku funkcni jsem myslel to, ze vyzaduje MSIE, vyzaduje Microsofti Javu, zkratka a dobre pokud nejste zakaznik/fanousek Billovych vyplodu, mate smulu. Jinak s funkcnosti (pominu-li fakt, ze IE uz pouzivam pouze a jedine pro Netbanku, coz mne docela stve) jsem nemel problemy az na detaily (jeden cas, zhruba tyden, to pri vypisu transakci negenerovalo popisy, takze akorat nejaky sileny kod a suma, nicmene hotline byl velmi rychly a vstricny). Dulezite je, ze ten internetbanking umi vsechno, co potrebuju, na pobocku nemusim a je to levne. Nejsem totiz silenec, abych za bankovni ucet s internet pristupem platil tisice korun za rok.
Jeste jsem zapomnel na jeden detail - velmi si cenim dvou prvnich vyberu v mesici z bankomatu zdarma, to je fakt super (v porovnani s ostatnimi bankami).

Jestli jsem tem technickym detailum rozumnel spravne (pripadne oprave se nebranim) - nemel by popisovany problem mit vliv na tok a bezpeci financi "z" a "na" Vas ucet, ale spis je to technicky problem Citibank, ze by jejich server mohl byt zahlcen. Panove, chapu to spravne ?