Višje sodišče potrdilo sodbo: NLB mora povrniti škodo zaradi vdora v e-banko

Zakaj bi cel internet preverjal?

Fantje, vi ste pa res zeleni.

Senitel je 13. avg 2014 ob 15:00 izjavil:

Sicer dejansko ničesar ne vemo kako je bila zadeva v tem primeru speljana tako da malo ugibam ampak... Saj se niso prijavili brez certifikata.
Problem je ker je NLB sam svoj CA in so njihovi certifikati v bistvu self signed. Nepridiprav komot generira svoj strežniški certifikat in se izdaja za "ACNLB" ter postavi neko napadalno spletno stran, ki se izdaja za klik.nlb.si. Ko bo uporabnik priletel na tako stran ga bo seveda pričakalo opozorilo ala "The site security certificate is not trusted!" in user bo jasno kliknil "add exception" (ista procedura je, ko s clean browserjem prvič prideš na stran od klika). Napadalna stran nato lahko s pomočjo javascripta kriptira poljubne requeste (ki jih uporabnik jasno ne vidi) na uporabnikovi strani in jih posreduje naprej pravemu kliku.
Uporabnikova krivda je v tem primeru samo to, da se je strinjal z novim zaupanja nevrednim server side certifikatom. Na kar ga je pa NLB v bistvu že navadila še preden je sploh začel uporabljat klik.

Ta scenarij se pri NLB ne more zgoditi, ker se uporabljajo server in client certifikati (bi bilo pa čisto možno pri bankah, ki namesto certifikata uporabljajo generator gesel). Phising stran se lahko pretvarja da je NLB, glede self-signed certifikata imaš prav - tako lahko dobi uporabnikovo geslo. Ne more pa phising stran delati requestov v uporabnikovem imenu, ker nima njegovega certifikata. Ponarediti ga ne more, ker NLB preveri izdajatelja (samega sebe). Na NLB strani ni "add exception". Razen če nima v tem postopku NLB konkretne napake v sistemu, ampak če bi bilo to bi bilo tudi veliko več napadov.

Kdor koli je že pobral denar iz računa, je nujno moral imeti uporabnikov certifikat. Torej ali je komitent kar sam podelil certifikat (torej izvoženo datoteko, obisk phishing strani ni dovolj), ali pa je dobil virus/trojanca, ki je to storil namesto njega. Sklepam da je veliko težje ukrasti certifikat, če je zaščiten z geslom, kar je napaka oškodovanca. Mislim da bi edina napaka NLB lahko bila v pomankljivem obveščanju uporabnikov glede phising strani in načina shranjevanja gesel.

Dejstvo je da je imela NLB pred tem dogodkom, ko so se pričele phising strani na NLB zelo zelo slabo varnostno politiko in zelo zanič spletno banko kar se tiče varnosti (poleg tega pa še pobirajo oderuško najemnino za uporabo spletne banke). In že zaradi tega prikimavam sodni odločbi. Imajo denar, imajo sredstva, vendar ne naredijo 0 za svoje izboljšanje varnosti, čeprav so bile že leta pred tem analize, raziskave in odkritja podobnih napadov na tuje banke in delovanje "zlikovcev" na internetu. Torej so v bistvu samo čakali da se zgodi neizbežno.

To je zame isto, kot da bi puščal v skladišču zadnja vrata odklenjena in enkrat nekdo nekoč bo že notri prišel in malce pokradel. Kdo je torej kriv? Tisti ki je imel stvari v skladišču ali skladišče samo, ker ni imelo primerne zaščite? Meni je odgovor na dlani.

MrStein je 13. avg 2014 ob 15:03 izjavil:

Ne ni, AC NLB je trusted. (razen na kakem open sours softveru, ki raje zaupa raznim Comodo-m in podobno... ).

V katerem vesolju je ACNLB trusted? Noben browser nima ACNLB kot zaupanja vrednega izdajatelja certifikatov (govorim za serverske certifikate). Nadaljevanje spodaj...

celebro je 13. avg 2014 ob 16:46 izjavil:

Senitel je 13. avg 2014 ob 15:00 izjavil:

Sicer dejansko ničesar ne vemo kako je bila zadeva v tem primeru speljana tako da malo ugibam ampak... Saj se niso prijavili brez certifikata.
Problem je ker je NLB sam svoj CA in so njihovi certifikati v bistvu self signed. Nepridiprav komot generira svoj strežniški certifikat in se izdaja za "ACNLB" ter postavi neko napadalno spletno stran, ki se izdaja za klik.nlb.si. Ko bo uporabnik priletel na tako stran ga bo seveda pričakalo opozorilo ala "The site security certificate is not trusted!" in user bo jasno kliknil "add exception" (ista procedura je, ko s clean browserjem prvič prideš na stran od klika). Napadalna stran nato lahko s pomočjo javascripta kriptira poljubne requeste (ki jih uporabnik jasno ne vidi) na uporabnikovi strani in jih posreduje naprej pravemu kliku.
Uporabnikova krivda je v tem primeru samo to, da se je strinjal z novim zaupanja nevrednim server side certifikatom. Na kar ga je pa NLB v bistvu že navadila še preden je sploh začel uporabljat klik.

Ta scenarij se pri NLB ne more zgoditi, ker se uporabljajo server in client certifikati (bi bilo pa čisto možno pri bankah, ki namesto certifikata uporabljajo generator gesel). Phising stran se lahko pretvarja da je NLB, glede self-signed certifikata imaš prav - tako lahko dobi uporabnikovo geslo. Ne more pa phising stran delati requestov v uporabnikovem imenu, ker nima njegovega certifikata. Ponarediti ga ne more, ker NLB preveri izdajatelja (samega sebe). Na NLB strani ni "add exception". Razen če nima v tem postopku NLB konkretne napake v sistemu, ampak če bi bilo to bi bilo tudi veliko več napadov.

Ja uporabljajo server in client certifikat. Ampak tudi njihov server certifikat je bil do nedavnega self-signed. Torej je lahko vsak lolek sproduciral nov server certifikat za svoj attack page, user je dobil "add exception" in attack page je lahko kriptiral requeste na clientu kot sem že opisal.
So pa to pred kratkim spremenili (19.6.2014) in so začeli uporabljat certifikat, ki ga browserji dejansko prepoznajo kot trusted, slava jim.

Njihov varnostni doseg dosedaj je bil, da so ob poteku njihovega self-signed certifikata (lani enkrat?) na prvo stran nabili obvestilo, da se bodo browserji pritoževali glede neveljavnega certifikata in naj userji kliknejo "add exception".

Senitel je 13. avg 2014 ob 17:22 izjavil:

Ja uporabljajo server in client certifikat. Ampak tudi njihov server certifikat je bil do nedavnega self-signed. Torej je lahko vsak lolek sproduciral nov server certifikat za svoj attack page, user je dobil "add exception" in attack page je lahko kriptiral requeste na clientu kot sem že opisal.
So pa to pred kratkim spremenili (19.6.2014) in so začeli uporabljat certifikat, ki ga browserji dejansko prepoznajo kot trusted, slava jim.

Request, ki je bil zakriptiran za phishing stran s self-signed certifikatom ne bo veljaven na NLB serverju, ki uporablja drug (pa čeprav tudi self-signed certifikat). Še prebrati ga ni možno brez privatnega ključa phishing strani. Phishing stran lahko zaradi "add exception" uporabniku pokaže karkoli in od uporabnika dobi poljuben input preko strani (npr. geslo), nikakor pa brez uporabnikovega certifikata ne more komunicirati z NLB strežnikom.

RejZoR je 13. avg 2014 ob 17:13 izjavil:

Čak mal, kako je lahko krivda in malomarnost banke, če uporabnik namesto strani s ključavnico in napisom HTTPS obišče stran http://klik.nalbe.si in vanjo vnese svoje login podatke in je za to nekako kriva banka.

Banka je v položaju, kjer lahko s svojimi bistveno večjimi sredstvi in tehničnim znanjem (tudi outsourcanim, če ga nima v hiši) poskrbi za uporabo takšnih tehničnih sredstev in postopkov, da se možnost takšne zlorabe zmanjša na stopnjo, ki je poslovno sprejemljiva.

Poslovno sprejemljiva stopnja je takšna, da bo banka lahko krila vso na takšen način povzročeno škodo - bodisi sama neposredno, bodisi z ustreznim zavarovanjem tveganja pri zavarovalnici.

Dosoditev odškodnine je nujno potreben mehanizem, ki banko prisili v takšno ravnanje, saj brez tveganja škode (torej, če bi banka vse zahtevke zavračala) banka ne bo motivirana za to, da bi bolje poskrbela za varnost.

Ubogi NLB:

MrStein je 13. avg 2014 ob 17:59 izjavil:

darkkk je 13. avg 2014 ob 16:46 izjavil:

Lej predstavljaj si, da si namesto na slo-tech.com na slo_tech.com, ki zgleda (skoraj) identično kot originalni site. Nato hočeš postat in vpišeš username & geslo - no tam mu je pobralo certifikat.

Še en, ki se ne spozna 3% na tehnologijo a je "ful pameten"?
Certifikat ne moraš tak mimogrede "pobrati" (če meniš drugače, to mnenje s čim podpri).

Meni je to, ko da bi banko tožil, ker sem šel namest v poslovalnico NLB v poslovalnico NLB. in položil denar na račun.

Sosedu Francu je pristanek na Luni zarota. Pepco pa duhovi obiščejo vsako soboto. Priseže!

RejZoR je 13. avg 2014 ob 17:13 izjavil:

Čak mal, kako je lahko krivda in malomarnost banke, če uporabnik namesto strani s ključavnico in napisom HTTPS obišče stran http://klik.nalbe.si in vanjo vnese svoje login podatke in je za to nekako kriva banka. To je zgolj in samo malomarnost uporabnika

Še en, ki ne ve kako HTTPS klient avtentikacija deluje.

Senitel je 13. avg 2014 ob 17:22 izjavil:

MrStein je 13. avg 2014 ob 15:03 izjavil:

Ne ni, AC NLB je trusted. (razen na kakem open sours softveru, ki raje zaupa raznim Comodo-m in podobno... ).

V katerem vesolju je ACNLB trusted? Noben browser nima ACNLB kot zaupanja vrednega izdajatelja certifikatov (govorim za serverske certifikate).

Noben, razen nekaj milijard instalacij IE (in Chrome in kar še uporablja Windows CryptoAPI).

Hitro, en z Windows Phone naj odpre https://klik.nlb.si/ da vidimo, če nekaj dodatnih milijono namestitev IE tudi ima ACNLB kot trusted.

In ti seveda veš. Bi te pa najprej vprašal kaj zaboga sploh delaš na strani klik.nalbe.si if you haven't fuckin noticed it... ker v 99% primerov gre za stran enakega izgleda s pretkano poimenovanim URL naslovom, ki ob hitrem pogledu deluje enako kot uradni. Kar vi bluzite so preklemano sofisticirani napadi s katerimi se skoraj nihče ne ukvarja. Oz se takrat niso, mogoče se sedaj, ko so začel dodajat gor varnostne "checkpointe".

Invictus je 13. avg 2014 ob 15:51 izjavil:

andromedar je 13. avg 2014 ob 15:50 izjavil:

smash je 13. avg 2014 ob 14:35 izjavil:

se strinjam - če banka ne more zagotoviti varnosti poslovanja, naj gre nazaj na papir

Banka te žal ne more zavarovati pred tvojo neumnostjo in nesposobnostjo upravljanja z računalnikom.

Kar se je zgodilo, je primerljivo s tem, da si ti osebno (vede ali nevede) pooblastil lopova na tvojem računu...pol pa se žališ banki, da je z računa dvignil denar.

Banka sploh ne bi smela dopustiti da se to zgodi.

A nič ne nadzorujejo svoje infrastrukture, sploh pa kritične zadeve?

Banka nadzoruje svojo ifrastrukturo zelo dobro, ne nadzoruje pa uporabnikove "ifrastrukture".
Napad se (očitno)ni zgodil na bančno ifrastrukturo amapak na uporabnikovo.

vsi bolj pametni od sodišča? verjetno mislite, da sodniki nimajo pojma o tej tematiki, da se niso podučili in da so odločili kartako malo po občutku, ker pač tako si danes ljudje predstavljajo sodišča, kjer nekdo kao o nečem odloči pa čeprav se mu sanja ne - zato smo lahko vsi bolj pametni od sodnikov, v čisto vsaki temi

smash je 13. avg 2014 ob 13:14 izjavil:

Zdaj lahko sam naredim fishing stran in sam sebi ukradem. Potem pa se od banke dobim. Zmaga.

Ja v sloveniji je to zgleda možno.
Se vidi kakšna sodišča imamo.

Spc je 13. avg 2014 ob 20:06 izjavil:

smash je 13. avg 2014 ob 13:14 izjavil:

Zdaj lahko sam naredim fishing stran in sam sebi ukradem. Potem pa se od banke dobim. Zmaga.

Ja v sloveniji je to zgleda možno.
Se vidi kakšna sodišča imamo.

Ce ti dokazejo goljufijo potem bos kar lepo sam kril skodo, poleg tega te pa caka se tozba za krsenje nekaj drugih zakonov, pa verjetno se kakasna civilna iz strani banke za odskodnino...

Sej lepo pise v linkanem zakonu, pise celo kateri clen je najbolj relevanten.

Meni se tu zdi zanimivo vprašanje, čigav je pravzaprav ta denar, ki je bil ukraden? To vendar ni moj denar, ko ga dam banko, postane last banke in ni več moja last. Torej nekdo je ukradel banki njen lasten denar, ki ga je hranila v lastni infrastrukturi, kaj imam jaz s tem? Ukradel ga je tako, da je med postopkom kraje izkoristil mene, vendar jaz o tem nisem nič vedel. Jaz vendar nisem dolžan biti top stručko za vprašanje računalniške varnosti, da bi lahko uporabljal spletno banko. Banka je pripravila spletno banko in mi jo ponudila v uporabo s ciljem kovanja velikih dobičkov, pri čemer ni zahtevala, da sem jaz pri tem strokovnjak za vprašanja računalniške varnosti. Praktično noben klient to ni. Večina jih pojma nima, kaj je to fišing in tudi ni bila zahtevana od njih nobena diploma. Banka iz tega kuje dobiček, jaz pa naj bi prevzel vsa tveganja? Ne. Pravilno je, da banka prevzame tveganja. Oziroma bi bilo, ker jih itak ne, čemur rečemo dokapitalizacija iz mojega žepa.

celebro je 13. avg 2014 ob 21:35 izjavil:

Razen, če je v tistem času bila možnost uporaba klika brez client certifikata

Ni tega takrat omogočal. Pa verjetno prej tudi ne.

celebro je 13. avg 2014 ob 21:35 izjavil:

Uporabnik lahko geslo javno objavi, pa mu nihče ne more ukrasti denarja, dokler ne dobi njegovega privatnega ključa (certifikata). Ključ pa lahko dobi samo če ga uporabnik sam da ali če dobi virus/trojanca. Banka na to ne more vplivati.

Seveda lahko. Lahko vpelje takšen varnostni mehanizem, ki ga kraja zasebnega ključa ne bo pretentala.

Nekateri tukaj ste preveč obsedeni z reševanjem nerešljivega problema in popolnoma slepi za to, da je lahko na drugi strani probleme enostavno in elegantno rešiš v zadovoljstvo vseh. Če banka ni sposobna vpeljati ustreznega varnostnega mehanizma, potem mora sprejeti odgovornosti in pokriti povzročeno škodo.

Krivda tukaj ni bila objektivna, temveč kar neposredna. Rešitev, ki takšne zlorabe omejijo na poslovno sprejemljivo raven, je vedno dovolj na voljo. Malomarnost pri izbiri rešitev je posledično odgovornost banke.

Ali bi kdo z razumevanjem gledal banko, ki bi dovoljevala dvig iz bankomata brez PIN-a? Češ, če si dovolil, da ti zmaknejo kartico, si popolnoma sam kriv za vsko škodo. Čeprav vse ostale banke uporabljajo PIN in je takšnih zlorab pri njih neprimerno manj.

MrStein je 13. avg 2014 ob 17:59 izjavil:

Senitel je 13. avg 2014 ob 17:22 izjavil:

MrStein je 13. avg 2014 ob 15:03 izjavil:

Ne ni, AC NLB je trusted. (razen na kakem open sours softveru, ki raje zaupa raznim Comodo-m in podobno... ).

V katerem vesolju je ACNLB trusted? Noben browser nima ACNLB kot zaupanja vrednega izdajatelja certifikatov (govorim za serverske certifikate).

Noben, razen nekaj milijard instalacij IE (in Chrome in kar še uporablja Windows CryptoAPI).

Hitro, en z Windows Phone naj odpre https://klik.nlb.si/ da vidimo, če nekaj dodatnih milijono namestitev IE tudi ima ACNLB kot trusted.

1.) slovenski CA-ji se namestijo na Windows XP z enim Windows update, ki pa ni Critical/Important ampak Optional: KB931125

Od Viste dalje pa je avtomatsko. Kdor še nima kakega slovenskega CA v trusted spisku, naj (z IE) obišče eno spletno stran, ki uporablja certifikat izdan od tega AC, in bo videl, da bo AC avtomatsko dodan v listo in bo naložilo stran brez opozoril o certifikatu.

2.) test z Windows Phone seveda nima pomena, odkar ima Klik drugi korenski certifikat (Entrust).

PS: Slovenske CA šteje MS za zaupanja vredne že dolgo časa, mislim da so jih dodali nekje med slovenskim predsedovanjem EU (leta 2008).

AndrejO je 13. avg 2014 ob 23:23 izjavil:

celebro je 13. avg 2014 ob 21:35 izjavil:

Uporabnik lahko geslo javno objavi, pa mu nihče ne more ukrasti denarja, dokler ne dobi njegovega privatnega ključa (certifikata). Ključ pa lahko dobi samo če ga uporabnik sam da ali če dobi virus/trojanca. Banka na to ne more vplivati.

Seveda lahko. Lahko vpelje takšen varnostni mehanizem, ki ga kraja zasebnega ključa ne bo pretentala.

Nekateri tukaj ste preveč obsedeni z reševanjem nerešljivega problema in popolnoma slepi za to, da je lahko na drugi strani probleme enostavno in elegantno rešiš v zadovoljstvo vseh. Če banka ni sposobna vpeljati ustreznega varnostnega mehanizma, potem mora sprejeti odgovornosti in pokriti povzročeno škodo.

Krivda tukaj ni bila objektivna, temveč kar neposredna. Rešitev, ki takšne zlorabe omejijo na poslovno sprejemljivo raven, je vedno dovolj na voljo. Malomarnost pri izbiri rešitev je posledično odgovornost banke.

Ali bi kdo z razumevanjem gledal banko, ki bi dovoljevala dvig iz bankomata brez PIN-a? Češ, če si dovolil, da ti zmaknejo kartico, si popolnoma sam kriv za vsko škodo. Čeprav vse ostale banke uporabljajo PIN in je takšnih zlorab pri njih neprimerno manj.

Če je napadalcu uspelo pridobiti certifikat z oškodovančevega računalnika, bi lahko hkrati pustil na računalniku še poljuben virus/rootkit/spyware. Potem je edini varnostni mehanizem ki še lahko pomaga to, da na ločeno napravo dobiš vse podatke o plačilu (znesek, številko računa in sklic) ki ga izvajaš in ga potrdiš v kombinaciji s to napravo. Ko imaš okužen računalnik ti noben generator gesel, sporočilo na login strani, dodatno geslo, virtualna tipkovnica ne more preprečiti napada, lahko ga samo zakasni - okužba računalnika mora trajati dokler uporabnik na okuženem računalniku ne izvede plačila.

Koliko bank ti pred plačilom pokaže vse podatke o plačilu na ločeni napravi?

NLB je uporabljala "PIN in kartico" (geslo in certifikat). Uporabnik je "PIN" vnesel v napravo, ki ni bila bankomat, kartico je pa izgubil. Kar se ti dejansko pritožuješ je: "Ali bi kdo z razumevanjem gledal banko, ki bi dovoljevala dvig iz bankomata brez potrdila dviga na telefonu".

Ali ti mogoče poznaš kakšen drug varnostni mehanizem, ki se ga ne bi dalo obiti v trenutku kraje certifikata z računalnika? Pa da ga kdo dejansko uporablja.

thramos je 14. avg 2014 ob 09:00 izjavil:

AndrejO je 13. avg 2014 ob 23:23 izjavil:

Seveda lahko. Lahko vpelje takšen varnostni mehanizem, ki ga kraja zasebnega ključa ne bo pretentala.

Vse varnostne mehanizme se da pretentati. Vprašanje je samo, ali banka vpelje dovolj stroge mehanizme, da jih skrben a povprečen uporabnik lahko uporablja brez zlorabe. Oziroma ali jih zavestno ne uvede (zaradi preprostosti uporabe), noče pa prevzeti odgovornosti za posledične vdore.

Da, seveda se da vse mehnizme pretentati. Naslednjič lahko prebereš vse, kar sem napisal, vključno z ravnijo poslovnega tveganja. Tudi tebi se je zapisalo "uporablja brez zlorabe", čeprav je obeme jasno, da se gre zgolj za zmanjašanje rizika z zmanjšanjem verjetnosti negativnega dogodka. Obešanje na žargon je tako odveč, ker se ne da nikomur več pisati "uvede postopke, ki zmanjšajo verjetnost neželjenega dogodka".

Zavestno ali po malomarnosti izbrati slabe mehanizme tudi ne igra vloge. Če bi bilo zavestno, potem so zavestno sprejeli tudi večje tveganje tovrstne škode in bi morali za poplačilo te škode ustvariti več rezervacij ali pa pridobiti drugačno zavarovanje. Če je to bila malomarnost, potem so si krivi sami. V poslovnem smislu je idealna točka tam, kjer imaš namanjšo vsoto vseh stroškov: ocenjen izpad prihodka zaradi prezahtevne uporabe + neposreden strošek tehnologije + strošek rezervacij/zavarovanja.

Zato odpade tudi vprašanje strogih mehanizmov. Edina dva razloga, da odškodnine ne bi plačali, sta goljufija oz. poskus goljufije (ugotavljanje česar je sicer delo organov pregona) ali pa huda malomarnost uporabnika.

thramos je 14. avg 2014 ob 09:00 izjavil:

Brez podrobnejših informacij (kot so v novici) o tem, kakšen je bil način vdora oz. kakšna naj bi bila uporabnikova malomarnost je precej težko soditi, ali je sodba upravičena ali ne.

Ne glede na omejene informacije, je iz dosegljivih razvidno, da se je banka branila s poskusom dokazovanja domnevne hude malomarnosti uporabnika, pri čemer ji te malomarnosti ni uspelo dokazati. Vse ostalo je sledilo iz te, za postopek bistvene ugotovitve.

Pa še tako čisto realno: osnovni cilj vedno novih kvazi varnostnih mehanizmov, ki jih vpeljujejo banke, nimajo ničesar z varnostjo, temveč več s tem, da banka v postopku lažje dokaže hudo malomarnosti. Karikirano: "Uporabnik si ni zapomnil 27 različnih gesel in PIN številke za 28-faktorsko avtentikacijo, temveč jih zapisal na ukraden list papirja, čeprav je bil v pogojih jasno opozorjen, da tega ne sme nikoli storiti. Hudo je bil malomaren."

Kako lahko brez informacij o tem, kaj je uporabnik počel, sodiš, ali je ravnal hudo malomarno ali ne?

O tem je sodilo sodisce, njihova sodba je pa znana. Glede na budget ki ga imajo banke za jebanje komitentov v glavo, bi sel stavit da so se zelo potrudili prepricati sodisce v hudo malomarnost svojega komitenta, pa jim vseeno ni uspelo. Meni to veliko pove, sploh ker ni nikjer indica da je res prislo do malomarnosti.

thramos je 14. avg 2014 ob 09:50 izjavil:

No, saj. Kako lahko brez informacij o tem, kaj je uporabnik počel, sodiš, ali je ravnal hudo malomarno ali ne?

Citat iz novice: "Banka o vračilu ni hotela slišati, češ da je bil potrošnik malomaren, ker da ni primerno zaščitil računalnika in ni prepoznal lažne spletne strani. Argument o neprimerni zaščiti sploh ne drži, saj je imel potrošnik nameščeno ustrezno protivirusno in protivohunsko opremo."

Iz tega citata je razvidno:
- obramba banke se je glasila: malomarnost uporabnika;
- odločitev sodišč na obeh stopnjah se je glasila: malomarnost ni bila dokazana.

Glede na to, da edini drugi razlog (goljufija) ni niti omenjen, je to vse, kar je. Druge obrambe banka tako ali tako ni imela.

thramos je 14. avg 2014 ob 09:50 izjavil:

Stopnja malomarnosti pa je seveda odvisna od mehanizmov varnosti. In v čem se "kvazi novi" razlikujejo od "starih"?

Narobe. Stopnja malomarnosti je pri povprečnem uporabniku odvisna od upoštevanja navodil banke in ravnanja povprečne osebe. Če so bila vsa navodila banke izpolnjena in bi povprečna oseba v enakem položaju ravnala enako, potem o malomarnosti ni možno govoriti.

Uporabljeni varnostni mehanizmi so pri tem ugotavljanju dejansko nepomembni. Za S-T so zanimivi zgolj toliko, da je lepo videti kako malo je dala konkretna banka na varnost in kako je očitno računala, da ne bo nikoli rabila izplačati kakršne koli škode.

AndrejO je 14. avg 2014 ob 10:02 izjavil:

Citat iz novice: "Banka o vračilu ni hotela slišati, češ da je bil potrošnik malomaren, ker da ni primerno zaščitil računalnika in ni prepoznal lažne spletne strani. Argument o neprimerni zaščiti sploh ne drži, saj je imel potrošnik nameščeno ustrezno protivirusno in protivohunsko opremo."

Iz tega citata je razvidno:
- obramba banke se je glasila: malomarnost uporabnika;
- odločitev sodišč na obeh stopnjah se je glasila: malomarnost ni bila dokazana.

Glede na to, da edini drugi razlog (goljufija) ni niti omenjen, je to vse, kar je. Druge obrambe banka tako ali tako ni imela.

Če slepo verjamemo sodiščem, potem je debata nepotrebna, se strinjam. Če pa želimo debatirat o tem, kaj so primerna zaščita banke in uporabnika, ter kaj je malomarno dejanje, je informacij premalo.

AndrejO je 14. avg 2014 ob 10:02 izjavil:

Narobe. Stopnja malomarnosti je pri povprečnem uporabniku odvisna od upoštevanja navodil banke in ravnanja povprečne osebe. Če so bila vsa navodila banke izpolnjena in bi povprečna oseba v enakem položaju ravnala enako, potem o malomarnosti ni možno govoriti.

Ja, navodila pa so odvisna od varnostnih mehanizmov. Ampak če te prav razumem, je edini namen novih varnostnih mehanizmov (še enkrat, se v čem razlikujejo od starih) lažje dokazovanje malomarnosti?

Ker se nisem spuscal v podrobnosti, me pa mocno zanima, morda kdo ve na katerem OS-u se je zgodil ta primer?
Nekaj mi govori da bi znal biti MacOS user

Katera banka danes za spletno bančništvo zahteva uporabo fizičnega ključka, ki generira časovno odvisne kode?

Jaz imam na HypoNET taksno resitev.

thramos je 14. avg 2014 ob 10:20 izjavil:

Če slepo verjamemo sodiščem, potem je debata nepotrebna, se strinjam. Če pa želimo debatirat o tem, kaj so primerna zaščita banke in uporabnika, ter kaj je malomarno dejanje, je informacij premalo.

Nekako je moj običajen instinkt, da zaključkom sodišč verjamem, dokler višja instanca ne dokaže nasprotno.

Primerna zaščita uporabnika je takšna, ki ga bo zavarovala pred škodo in, pogosto, tudi njegovo lastno neumnostjo.

Primerna zaščita banke je takšna, ki jo bo zavarovala pred škodo in, pogosto, tudi njeno lastno malomarnostjo.

Občasno ta dva cilja sovpadata, ne pa vedno. Zakon je spisan tako, da v sporu ščiti šibkejšo stranko in banko sili v izbiro takšnih vrst zaščite, ki sočasno ščitijo tudi njene uporabnike.

Za malomarno dejanje pa je iz besedila že jasno: če bi uporabnik opustil kateri koli ukrep o katerem ga je banka obvestila (ga ni, ker se izrecno omenja kaj vse je storil) ali pa bi ravnal na način, ki bi bil drugačen od ravnanja povprečne osebe (kar po mnjenju sodišča ni).

Sicer mi je zabavna debata o relativni kvaliteti phishing strani, vendar pa v času dogodka banka ni sprejela že takrat znanih in razumnih ukrepov, da bi svoj sistem izvedla tako, da bi uporabnik lažje ugotovil, da gre za phishing (self-signed potrdila?), zaradi česar bi lahko bila čisto povprečna oseba zlahka zavedena in to ne po lastni krivdi.

thramos je 14. avg 2014 ob 10:20 izjavil:

Ja, navodila pa so odvisna od varnostnih mehanizmov. Ampak če te prav razumem, je edini namen novih varnostnih mehanizmov (še enkrat, se v čem razlikujejo od starih) lažje dokazovanje malomarnosti?

Za banko je fokus na odvračanju škode, kar lahko storijo tudi tako, da lažje dokažejo malomarnost stranke. V smislu "kako neumen moraš biti, da ..." Izbira teh mehanizmov se lahko pokrije tudi z interesi strank (dejansko zmanjšanje števila zlorab ali obsega posamičnih zlorab), lahko pa tudi ne (moja redukcija do absurda z 28-faktorskim preverjanjem je redukcija dejanskih "varnostnih" idej kakšnih bank v ZDA).

Primer takšnega odvračanja pozornosti so npr. kartice s čipom. V fazi uvajanja se je število zlorab zmanjšalo, sedaj pa znova raste, ker je kriminalcem zmanjkalo "poceni tarč" in so to pač naslednje najlažje po vrsti. Če je včasih veljala teorija, da skimming čipov in možen, je danes že jasno, da je praksa čisto drugačna.

Pri temu ne pozabiti, da so varnostni mehanizmi niso samo na točki avtorizacije, temveč tudi na točki naknadnega preverjanja. Npr. dnevna omejitev obsega prometa preko te poti, kontakt uporabnika, ko se pojavijo transakcije, ki odstopajo od povprečja, ... Tudi to je varnost, ne samo preverjanje enih ključkov.

Ne vem, ali je bilo že kaj govora o tem, ampak kako bi lahko izvedel še dodatno geslo, ki ga dobiš po pošti? Namreč tisto geslo se potem uporablja, ko želiš npr. prenakazati denar ipd, in potem vneseš 3 znake v virtualno tipkovnico....