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!uw.edu.pl!pm.waw.pl!defiant.pm.waw.pl!n
    ot-for-mail
    From: Krzysztof Halasa <k...@d...pm.waw.pl>
    Newsgroups: pl.biznes.banki
    Subject: Re: Lukas Bank odmawia uznania STANDARDOWEGO druku wplaty
    Date: 02 Jun 2003 18:54:55 +0200
    Organization: The Palace of Youth in Warsaw
    Lines: 108
    Message-ID: <m...@d...pm.waw.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> <bb2rvg$lrp$1@foka1.acn.pl>
    <m...@d...pm.waw.pl> <bbaqi1$e91$1@foka1.acn.pl>
    NNTP-Posting-Host: defiant.pm.waw.pl
    Mime-Version: 1.0
    Content-Type: text/plain; charset=iso-8859-2
    Content-Transfer-Encoding: 8bit
    X-Trace: defiant.pm.waw.pl 1054572895 17059 195.116.170.36 (2 Jun 2003 16:54:55 GMT)
    X-Complaints-To: n...@d...pm.waw.pl
    NNTP-Posting-Date: Mon, 2 Jun 2003 16:54:55 +0000 (UTC)
    Xref: news-archive.icm.edu.pl pl.biznes.banki:244519
    [ ukryj nagłówki ]

    "Piotr Grzegorz Skowronski" <s...@S...PRECZgazeta.pl> writes:

    > O ile ofiara będzie wiedziała, co to jest numer referencyjny - to
    > zmienią.

    Zgodziles sie, ze nie ma on znaczenia dla kontrahenta.

    > Na pewno nie zaszkodzi wyraźnie podać.

    Oczywiscie ze nie zaszkodzi. Ale tez nie jest to zasadniczy plus.

    > Rozmawialiśmy o procedurze realizacji zlecenia na druku ZBP-owskim.
    > Napisałem:
    > > A więc kasjer powinien wydać wyłącznie
    > > druk zielony.
    > A Ty na to:
    > "Z tym sie oczywiscie zgadzam, ale tylko dlatego, ze wydawanie >1
    > potwierdzenia jest po prostu zbedne, klient tego nie chcial."
    > Dla mnie to jest jednoznaczne.

    A, to inna sprawa, myslalem o innym "kwicie potwierdzenia kasjera",
    nie takim na standardowym druku (skojarzylo mi sie z istniejaca procedura
    w jednym banku).

    Jasne, te dwa potwierdzenia (kopie czy jak to nazwiesz) dotycza jednej
    operacji i wciaz nie widze w tym problemu.

    > Zwróć uwagę, że potwierdzenie kasowe to nie to samo, co potwierdzenie
    > lub duplikat operacji wydane na żądanie klienta.

    Tak, ale tylko dlatego, ze potwierdzenie operacji (o jakim mysle) zawiera
    informacje o zrealizowaniu przelewu, a nie tylko o jego zleceniu.

    > Jeśli natomiast klient chce po prostu kopię potwierdzenia kasowego, to
    > na ksero z tym i nie ma problemu.

    W praktyce tak, bo klient zwykle nie potrzebuje wiecej niz 1 kopii.
    Zreszta tej 1 kopii tez zwykle nie potrzebuje :-)

    > Procedury powinny _zabraniać_ kasjerowi wydania kilku oryginałów druków
    > kasowych na jedną operację.

    Tego to ja juz nie wiem. Czym, Twoim zdaniem, rozni sie oryginal od
    kopii w tym przypadku? Bo chyba nie tym, ze kopia jest odbita na ksero?

    > Nie każdy bank obsługuje wszystkie sesje. Nie każdy księguje przelewy
    > otrzymane ostatnią sesją w tym samym dniu. A czas leci.

    To moze niech kontrahent korzysta z takiego banku, ktory to robi.
    Duzo bardziej bezpieczne od decydowania co zrobic z towarem na podstawie
    pary identycznych kwitkow.

    > Poza tym nie kłopot zabronić anulowania zlecenia, od strony banku który
    > taką usługę świadczy i powiedzieć o tym wszystkim. AFAIK przepisy nie
    > precyzują, czy bank jest obowiązany anulować zlecenie jeśli jest to
    > możliwe.

    A cel tego jest jaki?
    Wez pod uwage, ze nawet posiadajac w dloni podsteplowany kwit nie masz
    100% pewnosci, ze przelew zostanie wykonany: moze to byc wina pracownika
    jednego z bankow lub np. blad systemu komputerowego.
    Normalnie nie jest to oczywiscie problemem, gdyz bank pokryje szkody
    - tyle, ze w tym przypadku platnik moze stracic zainteresowanie w ogole
    wykonaniem tego przelewu, w koncu ma juz towar.

    Dlatego tez nie ma sensu obudowywac procedur bankowych dodatkowymi
    zabezpieczeniami tego typu, gdyz tak czy owak dopiero zaksiegowanie
    przychodzacego przelewu na rachunku sprzedawcy znaczy dla niego wiecej
    niz oswiadczenie kupujacego o zleceniu zaplaty.

    > || To, ze dla wykonania kazdego dowolnego przelewu potrzebny jest (latwy
    > || do zlamania) zmienny kod, wydaje sie akceptowalne dla prawie
    > || wszystkich. Obawiam sie jednak, ze nie byloby to akceptowalne dla
    > || mniej istotnych z punktu widzenia bezpieczenstwa operacjach.
    >
    > Przyznam, że nie rozumiem.

    No, dowolny przelew robi sie niezbyt czesto, w koncu sa stali sprzedawcy
    itd. Ale trudno wymagac wklepywania zmiennego kodu przy kazdej drobnej
    operacji - np. mBank musialby co chwile przysylac nowe listy "hasel".

    > || Dodatkowo 5-cyfrowy kod jest wystarczajaco bezpieczny dla przelewow
    > || (gdyz jest to tylko drugi stopien weryfikacji, nie mozna go latwo
    > || sprawdzic metoda brutalnej sily), ale to za malo dla sprawdzania
    > || przelewow przez osobe, ktora wczesniej nie zalogowala sie w systemie.
    >
    > Tu też masz dwa poziomy weryfikacji - numer operacji i hasło.

    Ale oba sa bardzo slabe, lacznie sa slabsze niz zwykle haslo do systemu
    komputerowego.

    > Zgoda, wygodne to by nie było. Ale czy z punktu widzenia włamu na "brute
    > force" ma znaczenie poziom skomplikowania hasła?

    Oczywiscie, wlasnie to ma zasadnicze znaczenie.

    > ||| Zanim uda Ci się wygenerować poprawny numer i hasło, to ktoś
    > ||| zauważy co robisz i zablokuje.
    > ||
    > || Zablokuje dzialanie systemu bankowego?
    >
    > Nie, odetnie takiemu użytkownikowi dostęp i powiadomi policję.

    Tak by bylo gdybym ja to chcial robic z konkretnego bankomatu banku, ale
    nie w Internecie.
    --
    Krzysztof Halasa
    Network Administrator

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