eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plFinanseGrupypl.biznes.bankiLukas Bank odmawia uznania STANDARDOWEGO druku wplaty › Re: Lukas Bank odmawia uznania STANDARDOWEGO druku wplaty
  • Path: news-archive.icm.edu.pl!news.icm.edu.pl!news.astercity.net!not-for-mail
    From: "Piotr Grzegorz Skowronski" <s...@S...PRECZgazeta.pl>
    Newsgroups: pl.biznes.banki
    Subject: Re: Lukas Bank odmawia uznania STANDARDOWEGO druku wplaty
    Date: Wed, 28 May 2003 19:37:33 +0200
    Organization: Aster City Net
    Lines: 119
    Message-ID: <bb2rvg$lrp$1@foka1.acn.pl>
    References: <b9rl39$29f$1@magusz.net> <b9udkn$rnp$1@foka1.acn.pl>
    <m...@d...pm.waw.pl> <babdr6$2339$1@foka1.acn.pl>
    <m...@d...pm.waw.pl> <baei2p$3i7$1@foka1.acn.pl>
    <m...@d...pm.waw.pl> <balrcv$2a5t$1@foka1.acn.pl>
    <m...@d...pm.waw.pl> <batdir$1unh$1@foka1.acn.pl>
    <m...@d...pm.waw.pl> <bb05c0$2kir$1@foka.acn.pl>
    <m...@d...pm.waw.pl> <bb1o5h$888$1@foka1.acn.pl>
    <m...@d...pm.waw.pl>
    NNTP-Posting-Host: 62.121.95.45
    Mime-Version: 1.0
    Content-Type: text/plain; charset="iso-8859-2"
    Content-Transfer-Encoding: 8bit
    X-Trace: foka1.acn.pl 1054143282 22393 62.121.95.45 (28 May 2003 17:34:42 GMT)
    X-Complaints-To: a...@a...net
    NNTP-Posting-Date: Wed, 28 May 2003 17:34:42 +0000 (UTC)
    X-Tech-Contact: u...@a...net
    X-Priority: 3
    X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1123
    X-Server-Info: http://www.astercity.net/news/
    X-Newsreader: Microsoft Outlook Express 6.00.2800.1123
    X-MSMail-Priority: Normal
    Xref: news-archive.icm.edu.pl pl.biznes.banki:243672
    [ ukryj nagłówki ]

    Krzysztof Halasa wrote:
    || Nie napisales dlaczego kontrahent na podstawie dwoch potwierdzen z
    || dwoma takimi samymi numerami ma domniemywac, ze oba potwierdzenia
    || dotycza tej samej transakcji, i dlaczego ma domniemywac przeciwnie,
    || jesli tych numerow tam w ogole nie bedzie.

    Jeśli na dwóch różnych potwierdzeniach będzie ten sam numer operacji, to
    sprawa jest jasna.
    Jeśli w ogóle nie będzie numeru, a ofiara oczekuje na dwa identyczne
    przelewy od oszusta to oszust ma ułatwione zadanie.
    Inną sprawą jest zaufanie do kontrahenta, które pozwoli na wydanie
    towaru na podstawie świstka. Ja chcę, żeby bankowe procedury nie
    ułatwiały potencjalnym oszustom zadania, nawet jeśli ktoś powie później
    że ofuara sama jest sobie winna.

    || W sensie formalnym, bo nie chodzi mi o "podejrzenia" - te beda
    || zawsze, a papiery nie powinny byc podstawa do wydawania towaru,
    || jesli nie ma sie wystarczajacego zaufania do klienta.

    To prawda.

    ||| Poza tym takie rozwiązanie powinno także usprawnić pracę samego
    ||| banku, w połączeniu z dobrze zorganizowanym archiwum. Po prostu
    ||| wiadomo byłoby od razu, gdzie czego szukać.
    ||
    || To jest inna sprawa, zupelnie nie zwiazana z problemem dwoch
    || potwierdzen.

    Dlatego napisałem "Poza tym".

    ||| Może to dziwne, ale nie byłem :) Albo zlecam przelewy przez
    ||| internet i w ogóle nie mam papierka, albo w kasie dostaję
    ||| potwierdzenie na druku ZBP-owskim,
    ||
    || I wtedy tez masz numer?

    Nie, ale kasjer daje mi tylko jeden druk. Wcześniej pisałeś, że na
    życzenie klienta kasjer powinien dać też swój kwitek potwierdzenia, a ja
    się z tym nie zgadzam.

    ||| Ma znaczenie, bo bank nie musi się tłumaczyć że nie jest wielbłądem.
    ||| Sprawa prosta: na każdym zleceniu jest numer referencyjny, zlecenie
    ||| o takim numerze było albo nie było wykonane, koniec.
    ||
    || A jesli numeru nie ma, to sprawa wyglada inaczej? Bez jaj.

    Klient zlecił 5 identycznych przelewów. Następnie okazał 6 potwierdzeń z
    kasy i zareklamował operację.
    Jeśli bank działa w sposób który opisałem, to nie ma szans na wyłudzenie
    w ten sposób.

    ||| Żeby klient mógł zaoszczędzić czas, a bank mógł się nowym ficzerem
    ||| pochwalić :)
    ||
    || Chyba tylko to drugie :-(

    Myślisz, że nie znalazłby się rynek na taką usługę? Choćby jako
    dodatkowy bajer?

    ||| Poza tym, jak się zastanowiłem to doszedłem do wniosku, że
    ||| bezpieczeństwo byłoby jednak wyższe - z tego względu, że oglądający
    ||| rzeczone potwierdzenie miałby pewność, że właśnie jest połączony z
    ||| serwerem bankowym i ogląda surowe dane bankowe ze źródła. A papierek
    ||| technicznie nie jest zabezpieczony niczym, oprócz świadomości
    ||| odpowiedzialności karnej za fałszerstwo.
    ||
    || To drugie moze byc wazniejsze. A jesli ktos np. anuluje przelew?

    To nie problem - można do każdego zlecenia prezentować jego aktualny
    status; przyjęte - zaksięgowane - wysłane do KIR taką a taką sesją, itp.

    ||| Bank wykonuje operację, nadaje jej swój numer. Następnie szyfruje
    ||| ten numer jakimś algorytmem i dodaje kilka losowych cyfr. Ten numer
    ||| podaje właścicielowi rachunku, który z usługi chce skorzystać.
    ||
    || Czyli generuje dlugi numer. Problem jest taki, ze dluzszy numer
    || bedzie za dlugi dla uzytkownikow, a krotszy mozna uzyc do
    || "enumeracji".

    Kwestia znalezienia złotego środka.
    Korzystanie z e-banków czy IVR-owych bankolinii to też ryzyko i
    konieczność pamiętania haseł, a jednak ludzie korzystają.

    ||| Właściciel ustala hasło, które zabezpieczy dostęp do jego danych.
    ||| Może być stałe dla wszystkich operacji dokonanych na rachunku.
    ||| Następnie dzwoni do kontrahenta, podaje numer operacji i swoje
    ||| hasło dostępowe.
    ||
    || I to ma byc w jakis sposob bezpieczne? Kontrahent ma znac haslo stale
    || dla wszystkich operacji na rachunku? Cos przesadzasz.

    No to zróbmy hasło zmienne :) Ze mną jak z dzieckiem ;)
    A poważnie - jest jeszcze numer zlecenia, który trzeba podać bo inaczej
    nic się nie wyświetli i już.

    ||| Jeśli będziesz chciał "na chama" odpytywać bankowy serwer po kolei o
    ||| różne numery operacji to zajmie Ci dużo czasu żeby trafić na
    ||| istniejący numer w połączeniu z poprawnym hasłem.
    ||
    || Tak jak napisalem, przy sensownej dlugosci numerow zajmie to chwile.

    Podobnie z włamaniem do e-banku, który jest zabezpieczony statycznym
    hasłem logowania. A jakoś nie słychać o tego typu włamaniach. Jeśli
    nawet były, to klient nie stracił - bo byłoby o tym głośno.

    ||| A to co być może uzyskasz, to
    ||| dane jakiejś-tam operacji jakiegoś-tam pana Kowalskiego. Gra
    ||| niewarta świeczki.
    ||
    || Nie. Uzyskam dane o wszystkich realizowanych transakcjach.

    Zanim uda Ci się wygenerować poprawny numer i hasło, to ktoś zauważy co
    robisz i zablokuje.

    --
    ukłony - skowi
    skowi (at) gazeta pl
    gg: 2539349

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1