http://orzeczenia.lodz.sr.gov.pl/content/$N/152510100000603_II_C_000383_2015_Uz_2015-09-28_001

W skrócie, poszkodowana straciła kasę (19k) z konta podając swoje dane autoryzacyjne na podstawionej stronie udającej oryginalną stronę banku. Klasyka.
Pozwała bank by oddał jej kasę bo to nie ona autoryzowała te przelewy. Sąd przychylił się do  poszkodowanej argumentując, Ĺźe zgodnie z prawem na banku ciąży obowiązek zwrĂłcenia kwoty, jeśli została ona wydana w sposĂłb nieautoryzowany przez uĹźytkownika z jakim wiąże umowa o dany instrument płatniczy. Skoro nie ona dokonała tych przelewĂłw oznacza, Ĺźe nie była to transakcja autoryzywana:

"Udostępnienie przez powódkę za pośrednictwem podstawionej witryny internetowej swoich danych identyfikacyjnych oraz haseł z listy będącej w jej posiadaniu osobom nieuprawnionym o nieustalonej tożsamości umożliwiło tym osobom zalogowanie się do jej konta i wykonanie dwóch przelewów. Czynności te z punktu widzenia systemu informatycznego Banku były przeprowadzone poprawnie, przy wykorzystaniu właściwych narzędzi autoryzacyjnych. Mimo tego, kwestionowanych transakcji płatniczych wykonanych z konta powódki w dniach 22 i 23 maja 2014 r. nie można uznać za transakcje autoryzowane."


Dalej sąd stwierdza, Ĺźe prawo oczywiście ogranicza w pewnym zakresie odpowiedzialność banku  w przypadku rażącego niedbalstwa uĹźytkownika, ale sąd takiego niedbalstwa się Ĺźe strony poszkodowanej nie dopatrzył:

" W ocenie Sądu oczywistym jest, że w okolicznościach niniejszej sprawy nie można powódce przypisać zgody ani woli podjęcia czynności zmierzających do przeprowadzenia kwestionowanych transakcji płatniczych przy użyciu posiadanych przez nią instrumentów płatniczych, a które to okoliczności świadczyłyby o autoryzowaniu przez nią transakcji. Nie można jej również przypisać umyślnego doprowadzenia do nieautoryzowanych transakcji płatniczych, a to choćby z tej przyczyny, że o ich dokonaniu powódka dowiedziała się dopiero w dniu 27 maja 2014 r. Zostały one zatem przeprowadzone bez jej wiedzy. Nie można jej również przypisać rażącego niedbalstwa w naruszeniu obowiązków, wynikających z art. 42 ustawy. Wprawdzie powódka, jak wskazano powyżej, udostępniła osobom nieuprawnionym dane z listy haseł jednorazowych, czego nie powinna czynić, jednak nie nastąpiło to w okolicznościach świadczących o rażącym niedbalstwie z jej strony."

--
Marek

On 3/19/2016 6:22 PM, Marek wrote:

http://orzeczenia.lodz.sr.gov.pl/content/$N/152510100000603_II_C_000383_2015_Uz_2015-09-28_001


W skrócie, poszkodowana straciła kasę (19k) z konta podając swoje dane
autoryzacyjne na podstawionej stronie udającej oryginalną stronę banku.
Klasyka.
Pozwała bank by oddał jej kasę bo to nie ona autoryzowała te przelewy.
Sąd przychylił się do  poszkodowanej argumentując, Ĺźe zgodnie z prawem
na banku ciąży obowiązek zwrócenia kwoty, jeśli została ona wydana w
sposób nieautoryzowany przez użytkownika z jakim wiąże umowa o dany
instrument płatniczy. Skoro nie ona dokonała tych przelewów oznacza, że
nie była to transakcja autoryzywana:

"Udostępnienie przez powódkę za pośrednictwem podstawionej witryny
internetowej swoich danych identyfikacyjnych oraz haseł z listy będącej
w jej posiadaniu osobom nieuprawnionym o nieustalonej tożsamości
umożliwiło tym osobom zalogowanie się do jej konta i wykonanie dwóch
przelewów. Czynności te z punktu widzenia systemu informatycznego Banku
były przeprowadzone poprawnie, przy wykorzystaniu właściwych narzędzi
autoryzacyjnych. Mimo tego, kwestionowanych transakcji płatniczych
wykonanych z konta powódki w dniach 22 i 23 maja 2014 r. nie można uznać
za transakcje autoryzowane."


Dalej sąd stwierdza, że prawo oczywiście ogranicza w pewnym zakresie
odpowiedzialność banku  w przypadku rażącego niedbalstwa uĹźytkownika,
ale sąd takiego niedbalstwa się że strony poszkodowanej nie dopatrzył:

" W ocenie Sądu oczywistym jest, że w okolicznościach niniejszej sprawy
nie można powódce przypisać zgody ani woli podjęcia czynności
zmierzających do przeprowadzenia kwestionowanych transakcji płatniczych
przy użyciu posiadanych przez nią instrumentów płatniczych, a które to
okoliczności świadczyłyby o autoryzowaniu przez nią transakcji. Nie
można jej również przypisać umyślnego doprowadzenia do nieautoryzowanych
transakcji płatniczych, a to choćby z tej przyczyny, że o ich dokonaniu
powódka dowiedziała się dopiero w dniu 27 maja 2014 r. Zostały one zatem
przeprowadzone bez jej wiedzy. Nie można jej również przypisać rażącego
niedbalstwa w naruszeniu obowiązków, wynikających z art. 42 ustawy.
Wprawdzie powódka, jak wskazano powyżej, udostępniła osobom
nieuprawnionym dane z listy haseł jednorazowych, czego nie powinna
czynić, jednak nie nastąpiło to w okolicznościach świadczących o rażącym
niedbalstwie z jej strony."

Nareszcie.

Skoro bank udostępnia narzędzie, wiedząc, że to narzędzie jest wadliwe i umożliwia wypłatę przez osoby inne niż upoważnione to ponosi za to odpowiedzialność.

On Sat, 19 Mar 2016, witek wrote:

Nareszcie.

Skoro bank udostępnia narzędzie, wiedząc, że to narzędzie jest wadliwe i umożliwia wypłatę przez osoby inne niż upoważnione to ponosi za to odpowiedzialność.

[...]
"Jak wynika z poczynionych ustaleń, pozwany Bank wywiązywał się z obowiązku zapewnienia, że indywidualne zabezpieczenia instrumentu płatniczego nie są dostępne dla osób innych niż użytkownik uprawniony do korzystania z tego instrumentu, powódka natomiast swoim obowiązkom wymienionym w art. 42 ust. 2 ustawy uchybiła, udostępniając instrument płatniczy osobom nieuprawnionym przez wpisanie przynajmniej dwukrotnie w dniach 22 i 23 maja 2014 r. kodów z listy haseł jednorazowych na podstawionej stronie internetowej."
[...]
"Dostawca jest obowiązany udowodnić inne okoliczności wskazujące na autoryzację transakcji płatniczej przez płatnika albo okoliczności wskazujące na fakt, że płatnik umyślnie doprowadził do nieautoryzowanej transakcji płatniczej, albo umyślnie lub wskutek rażącego niedbalstwa dopuścił się naruszenia co najmniej jednego z obowiązków, o których mowa w art. 42."

Jak rozumiem sąd uznał, że skoro ta kretynka zainstalowała sobie jakiś malware to nie dopuściła się w ocenie tego żałosnego sądu rażącego niedbalstwa tylko jakiegoś innego niedbalstwa. Ten kraj mnie osłabia. Banki mogą sobie żonglować TOiP jak chcą i wyłudzać w ten sposób od ludzi wzięte z czapki kwoty, kablówki mogą wciskać ludziom usługi których nikt nie chce i potem domagać się na fakturach kwot wyższych od ustalonego abonamentu bo ktoś kliknął nie ten przycisk na pilocie, telekomy zawsze bardzo chętnie przywalą opłatę za SMSy przychodzące najlepiej użytkownikom umów abonamentowych, bo tam nie ma limitu jak w prepaidzie. To jest wszystko wporządku. Ale jak trafi się debil, który poda jakimś bambusom swoje dane autoryzacyjne do konta to sąd się pochyla nad jego losem, bo <cytat z wyroku>:

"Jak wynika ze zgromadzonego w sprawie materiału dowodowego, do zainfekowania komputera użytkownika usług bankowości elektronicznej może dojść w podstępny, lecz prosty sposób, np. przez kliknięcie przez użytkownika w zdjęcie na ekranie czy otwarcie załącznika do wiadomości nadesłanej pocztą elektroniczną, informującej np. o nierozliczonych płatnościach czy zawierającej rzekome faktury. "

swoją drogą to uzasadnienie jest wadliwe, bo żaden popularny program pocztowy ani przeglądarka nie umożliwiają zainstalowania czegokolwiek przez kliknięcie na zdjęcie. Trzeba jeszcze potwierdzić, że chce się zainstalować kod na który użytkownik wyraża zgodę i bierze odpowiedzianość za jego wykonanie. A to już nie jest klikanie "na zdjęcie" tylko na odpowiedni komunikat systemu/programu pocztowego czy przeglądarki.

On 3/20/2016 4:33 AM, Rafal Jankowski wrote:

swoją drogą to uzasadnienie jest wadliwe, bo żaden popularny program
pocztowy ani przeglądarka nie umożliwiają zainstalowania czegokolwiek
przez kliknięcie na zdjęcie.

ty tak na serio?

Rafal Jankowski <jankowsr@oceanic.wsisiz.edu.pl> writes:

[...]

swoją drogą to uzasadnienie jest wadliwe, bo żaden popularny program
pocztowy ani przeglądarka nie umożliwiają zainstalowania czegokolwiek
przez kliknięcie na zdjęcie. Trzeba jeszcze potwierdzić, że chce się
zainstalować kod na który użytkownik wyraża zgodę i bierze

Dasz sobie głowę uciąć? Pod androidem podatnym na Stagefright też?


KJ

--
http://wolnelektury.pl/wesprzyj/teraz/
I am a traffic light, and Alan Ginzberg kidnapped my laundry in 1927!

On Sun, 20 Mar 2016, Kamil Jońca wrote:

Rafal Jankowski <jankowsr@oceanic.wsisiz.edu.pl> writes:

[...]

swoją drogą to uzasadnienie jest wadliwe, bo żaden popularny program
pocztowy ani przeglądarka nie umożliwiają zainstalowania czegokolwiek
przez kliknięcie na zdjęcie. Trzeba jeszcze potwierdzić, że chce się
zainstalować kod na który użytkownik wyraża zgodę i bierze

Dasz sobie głowę uciąć? Pod androidem podatnym na Stagefright też?

Pod każdym systemem, który ma niezałataną jakąś dziurę (znaną lub nie) może się tak zdarzyć, ale:

-po pierwsze taka sytuacja nie miała miejsca (przynajmniej żadna ze stron tego nawet nie próbowała sugerować)

-po drugie nikt nie powiedział , że bank ponosi odpowiedzialność za dziury w sofcie po stronie użytkownika

Rafal Jankowski <jankowsr@oceanic.wsisiz.edu.pl> writes:

[..]

-po drugie nikt nie powiedział , że bank ponosi odpowiedzialność za
dziury w sofcie po stronie użytkownika

Ale tu mówimy o dochowaniu należytej staranności przez
użytkownika. Który na dodatek nie musi być "profesjonalistą w zakresie
informatyki"
KJ
--
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
I have become me without my consent.

On Sun, 20 Mar 2016, Kamil Jońca wrote:

Rafal Jankowski <jankowsr@oceanic.wsisiz.edu.pl> writes:

[..]

-po drugie nikt nie powiedział , że bank ponosi odpowiedzialność za
dziury w sofcie po stronie użytkownika

Ale tu mówimy o dochowaniu należytej staranności przez
użytkownika. Który na dodatek nie musi być "profesjonalistą w zakresie
informatyki"

To jest już inny przypadek niż ten, którego dotyczyła ta sprawa. Gdyby sąd uznał, że dane autoryzacyjne były zdobyte przy użyciu świeżutkiego exploita i w takim przypadku nie można mówić o rażącej niedbałości to pewnie bym się chwilę zastanowił czy nazwać taki sąd żałosnym. Chociaż i tak jest jeszcze wiele rzeczy których użytkownik mógł dopilnować nawet na taką okoliczność - np. z jakiej racji komputer a tym bardziej aplikacja do łączenia się z bankiem ma mieć prawo do łączenia się z całym internetem w chwili robienia przelewu.
No ale załóżmy że to są już kazmaty informatyki zarezerwowane dla "profesjonalistów".
Tak czy inaczej dla mnie to przykład nie tylko głupoty sądu ale i kiepskiej jakości prawa, które powinno pozostawiać możliwie mało pola manewru subiektywnej ocenie, a obydwie omawiane sytuacje (dziura w bezpieczeństwie i zainstalowanie złośliwego oprogramowania) to przypadki bardzo proste do przewidzenia i to nie sąd a przepisy powinne jasno określać zarówno to kto ponosi ciężar dowodu jaka z tych sytuacji miała miejsce jak i to kto w konsekwencji płaci za wyprowadzone z konta środki.

On 2016-03-20 13:17, Rafal Jankowski wrote:

Tak czy inaczej dla mnie to przykład nie tylko głupoty sądu ale i
kiepskiej jakości prawa, które powinno pozostawiać możliwie mało pola
manewru subiektywnej ocenie

Okiem informatyka: to wynik dziadostwa robionego przez banki. Zwóroc uwagę że banki robia wszystko aby "ułatwić" korzystanie z bankowości. Od zakładania kond przelewem za grosz przez używanie absurdalnie łatwych do złamania zabezpieczeń informatycznych.

Oczywiście matematyka i informatyka mają skuteczne metody zabezpieczanie transakcji (np. tokeny sprzętowe). Problem w tym że znaczna częśc społeczeństwa to idioci a znaczna część managerów w bankach to debile. Efektem czego systemy zabezpieczeń banków bazują na poziomie mułu czyli zakładają że system operacyjny usera jest bezpieczny oraz że imie panieńskie babki jest absolutnie nie do podsłuchania podane 40 razy przez telefon.

, a obydwie omawiane sytuacje (dziura w

bezpieczeństwie i zainstalowanie złośliwego oprogramowania) to przypadki
bardzo proste do przewidzenia

Nie da się w sposób oczywisty stwierdzić czy twoj komputer posiada malware. Nawet zaawansowany informatyk nie jest w stanie tego stwierdzić. Windows, bo o nim tu domyslnie mowa, jest pod tym wzgledem praktycznie niemożliwy do oceny. Innymi słowy twoje "przypadki proste do przewidzenia" powinny zakończyć się absolutnym zakazem uzywania kanałów informatycznych do operacji bankowych. Bo można prosto przewidzieć że każdy user ma jakieś malware. Da się? Da. To niech nie używa.

i to nie sąd a przepisy powinne jasno
określać zarówno to kto ponosi ciężar dowodu jaka z tych sytuacji miała
miejsce jak i to kto w konsekwencji płaci za wyprowadzone z konta środki.

Ciężar dowodu? Wiesz, że nie da się w sposob bezwzględny ocenić czy komputer użytkownika zawiera malware? Tak technicznie rzecz biorąc, a nie prawnie. Technicznie nie masz szans ocenić przy ataku ukierunkowanym i unikatowym czy dowolnie wybrany system operacyjny z 3 obecnie używanych na rynku [1] jest bez malware. To wynika z faktu że 3 obecnie powszechnie używane OSy są po prostu gówno warte pod wzgędem bezpieczeństwa.

[1] Win, OS X, Linux.

PS. Banki migrują z tokentów sprzetowych w kierunku gówno wartych SMSów itp szitu. Trudno powiedzieć komu należy za to natłuc po mordzie. Byc może to "zarządzanie ryzykiem" które sprowadza się do stwierdzenia że przeciętny Kowalski nie ma czasu pozwać banku za ich żałosne zabezpieczenie.

On Sun, 20 Mar 2016, Sebastian Biały wrote:

On 2016-03-20 13:17, Rafal Jankowski wrote:

 Tak czy inaczej dla mnie to przykład nie tylko głupoty sądu ale i
 kiepskiej jakości prawa, które powinno pozostawiać możliwie mało pola
 manewru subiektywnej ocenie

Okiem informatyka: to wynik dziadostwa robionego przez banki. Zwóroc uwagę że banki robia wszystko aby "ułatwić" korzystanie z bankowości. Od zakładania kond przelewem za grosz przez używanie absurdalnie łatwych do złamania zabezpieczeń informatycznych.

Oczywiście matematyka i informatyka mają skuteczne metody zabezpieczanie transakcji (np. tokeny sprzętowe). Problem w tym że znaczna częśc społeczeństwa to idioci a znaczna część managerów w bankach to debile. Efektem czego systemy zabezpieczeń banków bazują na poziomie mułu czyli zakładają że system operacyjny usera jest bezpieczny oraz że imie panieńskie babki jest absolutnie nie do podsłuchania podane 40 razy przez telefon.

Można o tym dyskutować. Tak samo jak to czy słusznie jest skazać gościa którego samochód zabił człowieka a on sam 100m dalej był chwilę później nawalony jak Messerschmit. Niestety czasem przeprowadza się procesy poszlakowe i jakoś trzeba z tym żyć, ale w sprawie której dotyczy wątek w zasadzie nie pojawiają się żadne wątpiwości co do zdarzeń jakie miały miejsce.

  >

, a obydwie omawiane sytuacje (dziura w

 bezpieczeństwie i zainstalowanie złośliwego oprogramowania) to przypadki
 bardzo proste do przewidzenia

Nie da się w sposób oczywisty stwierdzić czy twoj komputer posiada malware. Nawet zaawansowany informatyk nie jest w stanie tego stwierdzić. Windows, bo o nim tu domyslnie mowa, jest pod tym wzgledem praktycznie niemożliwy do oceny. Innymi słowy twoje "przypadki proste do przewidzenia" powinny zakończyć się absolutnym zakazem uzywania kanałów informatycznych do operacji bankowych. Bo można prosto przewidzieć że każdy user ma jakieś malware. Da się? Da. To niech nie używa.

 i to nie sąd a przepisy powinne jasno
 określać zarówno to kto ponosi ciężar dowodu jaka z tych sytuacji miała
 miejsce jak i to kto w konsekwencji płaci za wyprowadzone z konta środki.

Ciężar dowodu? Wiesz, że nie da się w sposob bezwzględny ocenić czy komputer użytkownika zawiera malware? Tak technicznie rzecz biorąc, a nie prawnie. Technicznie nie masz szans ocenić przy ataku ukierunkowanym i unikatowym czy dowolnie wybrany system operacyjny z 3 obecnie używanych na rynku [1] jest bez malware. To wynika z faktu że 3 obecnie powszechnie używane OSy są po prostu gówno warte pod wzgędem bezpieczeństwa.

[1] Win, OS X, Linux.

Jednoznacznie udowodnić się nie da, ale bardzo często materiał dowodowy wskazuje na przebieg zdarzeń w tak prawdopodobnym stopniu, że żadna ze stron nie poddaje w wątpliwość tego co się wydarzyło.

PS. Banki migrują z tokentów sprzetowych w kierunku gówno wartych SMSów itp szitu. Trudno powiedzieć komu należy za to natłuc po mordzie. Byc może to "zarządzanie ryzykiem" które sprowadza się do stwierdzenia że przeciętny Kowalski nie ma czasu pozwać banku za ich żałosne zabezpieczenie.

I tutaj token sprzętowy nic by nie pomógł (zakładając, że przelewy zostały wykonany w krótkim czasie od chwili wyłudzenia haseł), bo kobieta po prostu przepisałaby hasła z tokena.

On 2016-03-20 13:58, Rafal Jankowski wrote:

Oczywiście matematyka i informatyka mają skuteczne metody
zabezpieczanie transakcji (np. tokeny sprzętowe). Problem w tym że
znaczna częśc społeczeństwa to idioci a znaczna część managerów w
bankach to debile. Efektem czego systemy zabezpieczeń banków bazują na
poziomie mułu czyli zakładają że system operacyjny usera jest
bezpieczny oraz że imie panieńskie babki jest absolutnie nie do
podsłuchania podane 40 razy przez telefon.

Można o tym dyskutować. Tak samo jak to czy słusznie jest skazać gościa
którego samochód zabił człowieka a on sam 100m dalej był chwilę później
nawalony jak Messerschmit.

Absolutnie nie widze związku. Nawalenie się odbywa się jeszcze w stanie świadomym. Instalacja malware odbywa się w stanie kompletnie nieświadomym.

Jednoznacznie udowodnić się nie da, ale bardzo często materiał dowodowy
wskazuje na przebieg zdarzeń w tak prawdopodobnym stopniu, że żadna ze
stron nie poddaje w wątpliwość tego co się wydarzyło.

"Pan na pewno ma zawirusowany komputer" usłyszałem nie tak dawno na infolini. E panie, pieprzenie z tymi procesami poszlakowymi i "wszyscy się zgadzają". Ponadto dla sądu jakiekolwiek dywagacjie techniczne i tak są scifi. Kazdy taki proces jest poszlakowy bo nie sposób aby prawnik zrozumiał dowód jesli jakims cudem by się pojawił.

I tutaj token sprzętowy nic by nie pomógł

Token pojawił się jako przyklad równiania banków do poziomu mułu.

zostały wykonany w krótkim czasie od chwili wyłudzenia haseł), bo
kobieta po prostu przepisałaby hasła z tokena.

To nie jest takie trywialne, token w powiązaniu z unikatową cechą komputera (numer seryjny cpu etc) uniemożliwia tego typu przekręt w sposób wystarczająco skuteczny. Ba, kto mówi do tokenie z ktorego się cos przepisuje, dlaczego nie wtykany w USB?. Niech zgadne, bankowy debilomanager właśnie obcina koszty, bo komu potrzebne są jakieś numery seryjne cpu.

PS. Informatyka i matematyka mają *perfekcyjne* i *tanie* sposoby zapobiegania takim przestępstwom. Jakieś 20-30 lat minimum. Tylko który bank ma potrzebe im zapobiegać?

On Sun, 20 Mar 2016, Sebastian Biały wrote:

On 2016-03-20 13:58, Rafal Jankowski wrote:

>  Oczywiście matematyka i informatyka mają skuteczne metody
>  zabezpieczanie transakcji (np. tokeny sprzętowe). Problem w tym że
>  znaczna częśc społeczeństwa to idioci a znaczna część managerów w
>  bankach to debile. Efektem czego systemy zabezpieczeń banków bazują na
>  poziomie mułu czyli zakładają że system operacyjny usera jest
>  bezpieczny oraz że imie panieńskie babki jest absolutnie nie do
>  podsłuchania podane 40 razy przez telefon.
 Można o tym dyskutować. Tak samo jak to czy słusznie jest skazać gościa
 którego samochód zabił człowieka a on sam 100m dalej był chwilę później
 nawalony jak Messerschmit.

Absolutnie nie widze związku. Nawalenie się odbywa się jeszcze w stanie świadomym. Instalacja malware odbywa się w stanie kompletnie nieświadomym.

Związek jest taki, że tu też nie ma 100% pewności, tzn. ten gość mógł:
-nawalić się po tym zdarzeniu
-zostać do tego zmuszony
-nie mieć z tym nic wspólnego po za tym, że był to jego samochód

Teoretycznie to w sądzie trzeba udowodnić jego winę, ale wiadomo jak gość nie przedstawi wiarygodnego alibi to a małe szanse  na taką linię obrony.

 Jednoznacznie udowodnić się nie da, ale bardzo często materiał dowodowy
 wskazuje na przebieg zdarzeń w tak prawdopodobnym stopniu, że żadna ze
 stron nie poddaje w wątpliwość tego co się wydarzyło.

"Pan na pewno ma zawirusowany komputer" usłyszałem nie tak dawno na infolini. E panie, pieprzenie z tymi procesami poszlakowymi i "wszyscy się zgadzają". Ponadto dla sądu jakiekolwiek dywagacjie techniczne i tak są scifi. Kazdy taki proces jest poszlakowy bo nie sposób aby prawnik zrozumiał dowód jesli jakims cudem by się pojawił.

 I tutaj token sprzętowy nic by nie pomógł

Token pojawił się jako przyklad równiania banków do poziomu mułu.

 zostały wykonany w krótkim czasie od chwili wyłudzenia haseł), bo
 kobieta po prostu przepisałaby hasła z tokena.

To nie jest takie trywialne, token w powiązaniu z unikatową cechą komputera (numer seryjny cpu etc) uniemożliwia tego typu przekręt w sposób wystarczająco skuteczny. Ba, kto mówi do tokenie z ktorego się cos przepisuje, dlaczego nie wtykany w USB?. Niech zgadne, bankowy debilomanager właśnie obcina koszty, bo komu potrzebne są jakieś numery seryjne cpu.

PS. Informatyka i matematyka mają *perfekcyjne* i *tanie* sposoby zapobiegania takim przestępstwom. Jakieś 20-30 lat minimum. Tylko który bank ma potrzebe im zapobiegać?

Jak OS był skompromitowany to powiązanie tokena z konkretną osobą, numerem seryjnym, CPU dalej nic nie da. Musiałbyś jeszcze coś w rodzaju bezpiecznej enklawy na najnowszym skylake'u.
Moje przesłanie było takie, że banki robią pełno wałów polegających na podpisywaniu umów bez weryfikacji, wpisują jakieś opłaty do TOiP i nic się nie dzieje. A jak użytkownik popisze się głupotą to jest właśnie tą głupotą usprawiedliwiony.

On 2016-03-20 14:42, Rafal Jankowski wrote:

Teoretycznie to w sądzie trzeba udowodnić jego winę, ale wiadomo jak
gość nie przedstawi wiarygodnego alibi to a małe szanse  na taką linię
obrony.

Nie da się przedstawić alibi kiedy w gre wchodzi współczesny system operacyjny z rodziny Windows. Da się przedstawić alibi kiedy kolega prawnik widział mnie po wypadku trzeźwego. To *różne* sytuacje.

Z punktu widzenia banku istnieje zasada domniemanego zarażenia malware. I słusznie, klient nie ma jak udowodnić że malware nie było więc bank nie jest nigdy stratny.

PS. Informatyka i matematyka mają *perfekcyjne* i *tanie* sposoby
zapobiegania takim przestępstwom. Jakieś 20-30 lat minimum. Tylko
który bank ma potrzebe im zapobiegać?

Jak OS był skompromitowany to powiązanie tokena z konkretną osobą,
numerem seryjnym, CPU dalej nic nie da.

Da się. Transakcje da się wykonać wyłacznie kiedy robi to ktoś posiadający fizyczny token. Możesz sobie kompromitować dowoli: obecność tokena (np. wyświetlającego kwotę, konto i potwierdzającego pinem na jego własnej klawiaturze) jest absolutnie nie do zlamania, choc należy wtedy zakładać niedebilnośc inzynierów o co coraz trudniej. Mimo to można w sposob absolutnie pewny powiązać obecność tokena, danych transakcji, upoważnionego usera w jedność. Malware możesz mieć w dowolnej ilości, co najwyżej transakcja nie zostanie zaakceptowana przez bank.

Musiałbyś jeszcze coś w rodzaju
bezpiecznej enklawy na najnowszym skylake'u.

Ależ są takie rozwiązania, TPM. Tylko że przygłupy bankowe jeszcze wiele dziesięcioleci dzieli od zaczajenia co z tym można zrobić. Oni na razie tworzą kolejny gówno warty portal bankowości opierający się o JavaScript i studentów-programatorów kupowanych na rynku na kilogramy. "Więcej ikonek i animacji, k..wa".

Moje przesłanie było takie, że banki robią pełno wałów polegających na
podpisywaniu umów bez weryfikacji, wpisują jakieś opłaty do TOiP i nic
się nie dzieje. A jak użytkownik popisze się głupotą to jest właśnie tą
głupotą usprawiedliwiony.

Czekam na "dobra zmianę" ktora uniemozliwi zakładanie kont przelewami, otwieranie kredytu smsami, realizowanie kasy kresokopia dowodu. Ale się nie doczekam. Wyraźnie widać że nie ma nikt w tym interesu.

On Sun, 20 Mar 2016, Sebastian Biały wrote:

On 2016-03-20 14:42, Rafal Jankowski wrote:

 Teoretycznie to w sądzie trzeba udowodnić jego winę, ale wiadomo jak
 gość nie przedstawi wiarygodnego alibi to a małe szanse  na taką linię
 obrony.

Nie da się przedstawić alibi kiedy w gre wchodzi współczesny system operacyjny z rodziny Windows. Da się przedstawić alibi kiedy kolega prawnik widział mnie po wypadku trzeźwego. To *różne* sytuacje.

Z punktu widzenia banku istnieje zasada domniemanego zarażenia malware. I słusznie, klient nie ma jak udowodnić że malware nie było więc bank nie jest nigdy stratny.

To samo możesz powiedzieć o każdym innym systemie, który nie jest OS. A Twojego kolegi (czy to prawnik czy nie to akurat bez znaczenia) równie dobrze mogło nie być i wtedy wszystkie poszlaki świadczą przeciwko Tobie.

>  PS. Informatyka i matematyka mają *perfekcyjne* i *tanie* sposoby
>  zapobiegania takim przestępstwom. Jakieś 20-30 lat minimum. Tylko
>  który bank ma potrzebe im zapobiegać?
 Jak OS był skompromitowany to powiązanie tokena z konkretną osobą,
 numerem seryjnym, CPU dalej nic nie da.

Da się. Transakcje da się wykonać wyłacznie kiedy robi to ktoś posiadający fizyczny token. Możesz sobie kompromitować dowoli: obecność tokena (np. wyświetlającego kwotę, konto i potwierdzającego pinem na jego własnej klawiaturze) jest absolutnie nie do zlamania, choc należy wtedy zakładać niedebilnośc inzynierów o co coraz trudniej. Mimo to można w sposob absolutnie pewny powiązać obecność tokena, danych transakcji, upoważnionego usera w jedność. Malware możesz mieć w dowolnej ilości, co najwyżej transakcja nie zostanie zaakceptowana przez bank.

Podany przez Ciebie przykład TPMa to tylko dodatkowa warstwa zabezpieczeń która rownie dobrze może być skompromitowana jak i OS, więc z tą "absolutną" pewnością to trochę pojechałeś. Nie mówiąc już o tym, że podobnie jak numer w totolotku można go "zgadnąć", chociaż w zależności od implementacji pewnie trochę więcej bitów jest do odgadnięcia.

 Musiałbyś jeszcze coś w rodzaju
 bezpiecznej enklawy na najnowszym skylake'u.

Ależ są takie rozwiązania, TPM. Tylko że przygłupy bankowe jeszcze wiele dziesięcioleci dzieli od zaczajenia co z tym można zrobić. Oni na razie tworzą kolejny gówno warty portal bankowości opierający się o JavaScript i studentów-programatorów kupowanych na rynku na kilogramy. "Więcej ikonek i animacji, k..wa".

Ja podałem przykład SGXa, Ty TPMa, jeden 8====o. To tylko różne implementacje sprzętowych DRMów, które stanowią dodatkowe zabezpieczenie, ale jeśli chodzi o absolutną pewność to dobrze wiesz, czego w życiu człowiek może być pewien.

 Moje przesłanie było takie, że banki robią pełno wałów polegających na
 podpisywaniu umów bez weryfikacji, wpisują jakieś opłaty do TOiP i nic
 się nie dzieje. A jak użytkownik popisze się głupotą to jest właśnie tą
 głupotą usprawiedliwiony.

Czekam na "dobra zmianę" ktora uniemozliwi zakładanie kont przelewami, otwieranie kredytu smsami, realizowanie kasy kresokopia dowodu. Ale się nie doczekam. Wyraźnie widać że nie ma nikt w tym interesu.

Nie mam nic przeciwko kontom zakładanym na SMSa, mogą być nawet anonimowe dopóki tylko na takim koncie nie może powstać debet czy inne zobowiązanie po stronie klienta.

On 2016-03-20 19:28, Rafal Jankowski wrote:

Z punktu widzenia banku istnieje zasada domniemanego zarażenia
malware. I słusznie, klient nie ma jak udowodnić że malware nie było
więc bank nie jest nigdy stratny.

To samo możesz powiedzieć o każdym innym systemie, który nie jest OS.

Czekaj, bo to zdanie nie ma sensu. Co masz pod skrótem OS? Open Source? Operating System?

Open Source nie sluzy do ochrony przed kompromitacją systemu przez malware.

A
Twojego kolegi (czy to prawnik czy nie to akurat bez znaczenia) równie
dobrze mogło nie być i wtedy wszystkie poszlaki świadczą przeciwko Tobie.

Domniemanie niewinności w akcji :)

Podany przez Ciebie przykład TPMa to tylko dodatkowa warstwa
zabezpieczeń która rownie dobrze może być skompromitowana jak i OS

Dawaj. Mozesz pokazać przykład kompromitacji jakiegoś współczesnego TPMa? Żeby nie było: Ja moge, ale mocno niepraktyczny w analizowanym scenariuszu. A z uwagi na unikatowośc kluczy należy nie tyle złamać jeden, co konkretny egemplarz.

, więc

z tą "absolutną" pewnością to trochę pojechałeś. Nie mówiąc już o tym,
że podobnie jak numer w totolotku można go "zgadnąć", chociaż w
zależności od implementacji pewnie trochę więcej bitów jest do odgadnięcia.

TPM i inne metody zabezpieczania kryptograficznego planuje się i impelmentuje z myślą o *NIEŁAMALNOŚCI* w realnych warunkach dzisiaj i za kilkanascie lat. Jesli masz śladowe pojęcie o fizyce, połprzewodnikach itp duperelach proponuje poczytać jakiego typu zabezpieczenia stosowane są w scalakach TPM. Nigdzie sobie nie pojechałem. Odgadnięcie czegokolwiek z TPMa jest niemożliwe w sensownym czasie, szczegolnie w scenariuszu gdzie masz dostep do niego tylko przez interfejs. A do komputerów kwantowych daleko. Prezentujesz rozumowanie typowego debilomanagera z banku: przeciez wszystko można złamać, więc lepiej spierdolić od razu. Chwilowo sprzętowy token jest niełamalny o ile nie zrobili go debile co się czasem zdarza w świecie inżynierii.

Wykonanie nielamalnego, nawet profesjonalnie, tokena to kwestia max kilku dolarow. Jestem gotów je zaplacić. Problem w tym że nie mam komu, bo wszędzie uważa się że najlepszą ochorna moich pieniedzy jest stado studentów developujących na produkcji tony gówna w javascripcie.

On Sun, 20 Mar 2016, Sebastian Biały wrote:

On 2016-03-20 19:28, Rafal Jankowski wrote:

>  Z punktu widzenia banku istnieje zasada domniemanego zarażenia
>  malware. I słusznie, klient nie ma jak udowodnić że malware nie było
>  więc bank nie jest nigdy stratny.
 To samo możesz powiedzieć o każdym innym systemie, który nie jest OS.

Czekaj, bo to zdanie nie ma sensu. Co masz pod skrótem OS? Open Source? Operating System?

Open Source nie sluzy do ochrony przed kompromitacją systemu przez malware.

Open Source. O każdym systemie, który nie jest open source możesz powiedzieć, że nie wiadomo co robi i nie widzę powodu dla specjalnego wyróżnienia Windowsa.

 A
 Twojego kolegi (czy to prawnik czy nie to akurat bez znaczenia) równie
 dobrze mogło nie być i wtedy wszystkie poszlaki świadczą przeciwko Tobie.

Domniemanie niewinności w akcji :)

W polskim prawie nie ma nigdzie wprost napisane, że istnieje jakiekolwiek domniemanie niewinności, chociaż winę trzeba udowodnić. Jak poszlaki świadczą przeciwko Tobie to sąd może dać wiarę Twoim tłumaczenim albo nie Jak nie da to te poszlaki stanowią właśnie "dowód" i masz przechlapane.

 Podany przez Ciebie przykład TPMa to tylko dodatkowa warstwa
 zabezpieczeń która rownie dobrze może być skompromitowana jak i OS

Dawaj. Mozesz pokazać przykład kompromitacji jakiegoś współczesnego TPMa? Żeby nie było: Ja moge, ale mocno niepraktyczny w analizowanym scenariuszu. A z uwagi na unikatowośc kluczy należy nie tyle złamać jeden, co konkretny egemplarz.

, więc

 z tą "absolutną" pewnością to trochę pojechałeś. Nie mówiąc już o tym,
 że podobnie jak numer w totolotku można go "zgadnąć", chociaż w
 zależności od implementacji pewnie trochę więcej bitów jest do
 odgadnięcia.

TPM i inne metody zabezpieczania kryptograficznego planuje się i impelmentuje z myślą o *NIEŁAMALNOŚCI* w realnych warunkach dzisiaj i za kilkanascie lat. Jesli masz śladowe pojęcie o fizyce, połprzewodnikach itp duperelach proponuje poczytać jakiego typu zabezpieczenia stosowane są w scalakach TPM. Nigdzie sobie nie pojechałem. Odgadnięcie czegokolwiek z TPMa jest niemożliwe w sensownym czasie, szczegolnie w scenariuszu gdzie masz dostep do niego tylko przez interfejs. A do komputerów kwantowych daleko. Prezentujesz rozumowanie typowego debilomanagera z banku: przeciez wszystko można złamać, więc lepiej spierdolić od razu. Chwilowo sprzętowy token jest niełamalny o ile nie zrobili go debile co się czasem zdarza w świecie inżynierii.

Wykonanie nielamalnego, nawet profesjonalnie, tokena to kwestia max kilku dolarow. Jestem gotów je zaplacić. Problem w tym że nie mam komu, bo wszędzie uważa się że najlepszą ochorna moich pieniedzy jest stado studentów developujących na produkcji tony gówna w javascripcie.

Jesteś fanatykiem. Nie znam TPMów, nie będę się wypowiadał. Jest to jednak zwykły kawałek krzemu realizujący jakieś funkcje kryptograficzne pewnie podobne do np. HSMów albo SGXa i owszem, zwiększają one bezpieczeństwo ale o ile ich model matematyczny może wyglądać bardzo fajnie to zawsze są pewne słabości albo od takich trywialnych że wpinasz się kabelkami pomiędzy scalak a ściezki na płycie i wyciągasz wrażliwe informacje. Może być tak, że klucz nigdynie opuszcza scalaka i niby to nie da się go (w teorii) stamtąd wyskrobać, nie mówiąc już o przypadku użycia go przez nieuprawnioną osobę (do tego pewnie była ta kamerka) i inne cuda niewida.

On 2016-03-20 20:32, Rafal Jankowski wrote:

Czekaj, bo to zdanie nie ma sensu. Co masz pod skrótem OS? Open
Source? Operating System?
Open Source nie sluzy do ochrony przed kompromitacją systemu przez
malware.

Open Source. O każdym systemie, który nie jest open source możesz
powiedzieć, że nie wiadomo co robi i nie widzę powodu dla specjalnego
wyróżnienia Windowsa.

Przecież to samo można powiedzieć o każdym systemie OpenSource! Wiesz co robi twoje Ubuntu kiedy instaluje setkę aktualizacji? Myslisz że miliny oczu sledzą? Milony ludzi sprawdza każdą linie kodu nastepnego programu do ściągania pornoli? Serio?

Domniemanie niewinności w akcji :)

W polskim prawie nie ma nigdzie wprost napisane, że istnieje
jakiekolwiek domniemanie niewinności, chociaż winę trzeba udowodnić. Jak
poszlaki świadczą przeciwko Tobie to sąd może dać wiarę Twoim
tłumaczenim albo nie Jak nie da to te poszlaki stanowią właśnie "dowód"
i masz przechlapane.

Bierzemy więc technologie i już nie muszę się przed nikim tłumaczyć. Na sasiedniej grupie "prawo" jest całe zbiegowisko ludzi których czas nie posiada ceny i z chęcia udowodnia sobie cokolwiek przed sądem. Ja nie mam czasu aby mnie jakieś bankowe debile miały czołgać udowadniając że ich dziadostwo to moja wina.

Wykonanie nielamalnego, nawet profesjonalnie, tokena to kwestia max
kilku dolarow. Jestem gotów je zaplacić. Problem w tym że nie mam
komu, bo wszędzie uważa się że najlepszą ochorna moich pieniedzy jest
stado studentów developujących na produkcji tony gówna w javascripcie.

Jesteś fanatykiem.

Nie. Jestem programista i elektronikiem. O maly włos również materiałoznawcą z dziedziny kryształów i okolic. Daje mi to pewne podstawy do wypowiadania się o tym i o owym.

Nie znam TPMów, nie będę się wypowiadał. Jest to
jednak zwykły kawałek krzemu realizujący jakieś funkcje kryptograficzne
pewnie podobne do np. HSMów albo SGXa i owszem, zwiększają one
bezpieczeństwo ale o ile ich model matematyczny może wyglądać bardzo
fajnie to zawsze są pewne słabości albo od takich trywialnych że wpinasz
się kabelkami pomiędzy scalak

No właśnie. Nic nie wiedz o TPM. Czasy Januszy Kryptografii mineły bezpowrotnie.

Tu możesz sobie zobaczyć te twoje kabelki na scalak:

https://www.youtube.com/watch?v=rEUH1WGa2_0

Koszt wyciągniecia jednego klucza z jednego ezemplarza TPM szacuje się na 1ml zł i bez gwarancji powodzenia z uwagi na złożone zabezpieczenia. *Egzemplarza* powtarzam, bo to ważne. Koszt produkcji scalaka jest pomijalny.

informacje. Może być tak, że klucz nigdynie opuszcza scalaka i niby to
nie da się go (w teorii) stamtąd wyskrobać, nie mówiąc już o przypadku
użycia go przez nieuprawnioną osobę (do tego pewnie była ta kamerka) i
inne cuda niewida.

Ba, pomyśl co bedzie jak w taki token przypierd... meteoryt. To dyskwalifikuje tą technologię od razu. Back to javascript i dużo number of animacji. Niech zyje security by poverty!

On Sun, 20 Mar 2016, Sebastian Biały wrote:

On 2016-03-20 20:32, Rafal Jankowski wrote:

>  Czekaj, bo to zdanie nie ma sensu. Co masz pod skrótem OS? Open
>  Source? Operating System?
>  Open Source nie sluzy do ochrony przed kompromitacją systemu przez
>  malware.
 Open Source. O każdym systemie, który nie jest open source możesz
 powiedzieć, że nie wiadomo co robi i nie widzę powodu dla specjalnego
 wyróżnienia Windowsa.

Przecież to samo można powiedzieć o każdym systemie OpenSource! Wiesz co robi twoje Ubuntu kiedy instaluje setkę aktualizacji? Myslisz że miliny oczu sledzą? Milony ludzi sprawdza każdą linie kodu nastepnego programu do ściągania pornoli? Serio?

Świetnie, czym więc windows zasłużył na wyróżnienie w tym zestawie?

Nie. Jestem programista i elektronikiem. O maly włos również materiałoznawcą z dziedziny kryształów i okolic. Daje mi to pewne podstawy do wypowiadania się o tym i o owym.

[...]

No właśnie. Nic nie wiedz o TPM. Czasy Januszy Kryptografii mineły bezpowrotnie.

Tu możesz sobie zobaczyć te twoje kabelki na scalak:

https://www.youtube.com/watch?v=rEUH1WGa2_0

Koszt wyciągniecia jednego klucza z jednego ezemplarza TPM szacuje się na 1ml zł i bez gwarancji powodzenia z uwagi na złożone zabezpieczenia. *Egzemplarza* powtarzam, bo to ważne. Koszt produkcji scalaka jest pomijalny.

 informacje. Może być tak, że klucz nigdynie opuszcza scalaka i niby to
 nie da się go (w teorii) stamtąd wyskrobać, nie mówiąc już o przypadku
 użycia go przez nieuprawnioną osobę (do tego pewnie była ta kamerka) i
 inne cuda niewida.

Ba, pomyśl co bedzie jak w taki token przypierd... meteoryt. To dyskwalifikuje tą technologię od razu. Back to javascript i dużo number of animacji. Niech zyje security by poverty!

Nie będę poznawał nowej technologii tylko do tego, żeby prowadzić taką dyskusję, bo na razie nie podałeś żadnych konkretów, a ludzi potencjalnie sprytniejszych od Cieie (managerów bankowych doskonale orientujących się w dostępnych na rynku technologiach bezpieczeństwa) wyzywasz od debiili. Skoro uważasz że ten TPM jest takim lekarstwem na całe zło to powiedz na jakiej podstawie tak twierdzisz? Że niby generuje się w nim niemożliwy do wyciągnięcia klucz prywatny i wszystkie operacje są nim podpisywane? Że aplikacja, która żąda tego podpisu też musi być podpisana? Nie wiem jak w takim wypadku przebiega przekazanie klucza publicznego do banku. Pewnie bank sam tego TPMa używa żeby dostać klucz publiczny i potem wysyła z już wygenerowanym prywatnym, ale nie jestem pewien czy można ufać jakiemuś chińskiemu scalakowi przy którym manipulowali bankowcy, bo jak poznam czy to co dostałem nie jest czymś o tym samym API ale z już wyciągniętym kluczem prywatnym?

On 2016-03-20 21:22, Rafal Jankowski wrote:

Świetnie, czym więc windows zasłużył na wyróżnienie w tym zestawie?

Popularnością malware z powodu popularności OSa. Jest zdecydownie popularnieszy niż cała reszta w kupie.

Nie będę poznawał nowej technologii tylko do tego, żeby prowadzić taką
dyskusję, bo na razie nie podałeś żadnych konkretów

Konkrety masz przed soba. Internet się to nazywa. Spodziewasz się że pokaże Ci jak robi się w krzemie detektory światła, jak tworzy się mesh, co to jest zakłucanie opcodów, jak dzialają bezpieczniki, gdzie są te "kabelki"? Wybacz. Obejrzyj choć linka ktory podesłalem aby móc pojąć jak głupim konceptem są te kabelki.

, a ludzi
potencjalnie sprytniejszych od Cieie (managerów bankowych doskonale
orientujących się w dostępnych na rynku technologiach bezpieczeństwa)
wyzywasz od debiili.

Mam konta w 3 bankach. Kazdy z nich tworzy frontend usera zdecydowanie glupszy od poprzedniego, bardziej niebezpieczny, generujacy setki potencjalnych kłopotów i dróg przez ktore może dostać się malware. Po drugie wiekszość z nich uzyskała śmieciowe technicznie wykształcenie. Sugerujesz że misiaczek po marketingu bądź bankowości "świetnie orientuje się w technologii"? Zapewne świetnie orientuje się w kolorach słupkow idących w góre i w dół. Ale żeby w krzemie, ftu, silikonie? Szacun, panie. Gdzie nie spojrzeć, ekspert od kryptografii albo fizyki ciała stałego i jeszcze zarządzać bankiem umi.

Skoro uważasz że ten TPM jest takim lekarstwem na
całe zło to powiedz na jakiej podstawie tak twierdzisz?

Matematycznej. Niestety nie twierdze że na całe, bo na przykład upierniczylo mi wczoraj miernik przepiecie i na to nie poradzi. Na Pawłowicz w Sejmie też. Jest duzo przypadków gdzie sobie nie poradzi. tak, że nie wszystkie. Ale na autoryzację/autentykację czy inną cykację ma szanse lepszą niż panienka żądająca nazwiska panieńskiego babki.

Że niby generuje
się w nim niemożliwy do wyciągnięcia klucz prywatny i wszystkie operacje
są nim podpisywane?

Nie. Tak. Może. Zależy. W końcu to producent decyduje co można tym zrobić. Można tez powoli migać diodą co może byc interesującą dodatkową opcją security dla biznesmenów.

Że aplikacja, która żąda tego podpisu też musi być
podpisana?

A po ch... Zasadą działania TPM jest to że może pracować w kompie z milionem wirusów, trojanów, malware. I nic. Dalej jest trusted i pozwala na bezpieczne przeprowadzanie operacji. Zabawne jak ten zdrowy rozsądek nijak nie pasuje do rzeczywistości, nie?

Nie wiem jak w takim wypadku przebiega przekazanie klucza
publicznego do banku.

Nie jest przekazywany. Zmartwie Cie jednak: od jakiś 30 lat przekazujemy klucze przez nieszyfrowany internet i robimy to bezpiecznie. Ale tutaj nie musimy.

Pewnie bank sam tego TPMa używa żeby dostać klucz
publiczny i potem wysyła z już wygenerowanym prywatnym

Nie masz pojecia o kryptografii.

, ale nie jestem
pewien czy można ufać jakiemuś chińskiemu scalakowi przy którym
manipulowali bankowcy

Ufasz zatem:
a) bandzie studentów impelemntujacych systemy bankowe "na produkcji"
b) stadzie prawników ktorych głownym powodem istnienia jest egzekwowanie sprawiedliwości w sposób mądry i jakże bezinteresowny
b) kasjerom ktorzy autoryzują milionowe przelewy koslawym znaczkiem nazywanym podpisem i własna oceną jakości makijażu

, bo jak poznam czy to co dostałem nie jest czymś o
tym samym API ale z już wyciągniętym kluczem prywatnym?

Nie masz pojecia o kryptografii.

On Sun, 20 Mar 2016, Sebastian Biały wrote:

On 2016-03-20 21:22, Rafal Jankowski wrote:

 Świetnie, czym więc windows zasłużył na wyróżnienie w tym zestawie?

Popularnością malware z powodu popularności OSa. Jest zdecydownie popularnieszy niż cała reszta w kupie.

Napisałeś "Windows, bo o nim tu domyslnie mowa, jest pod tym wzgledem praktycznie niemożliwy do oceny." To jakby sugerowało że Windows różni się czymś od reszty i o ile popularność malware na windowsa nie budzi zastrzeżeń to trudność w ocenie czy taki malware był czy go nie było nie ma z Windowsem nic wspólnego.

 Nie będę poznawał nowej technologii tylko do tego, żeby prowadzić taką
 dyskusję, bo na razie nie podałeś żadnych konkretów

Konkrety masz przed soba. Internet się to nazywa. Spodziewasz się że pokaże Ci jak robi się w krzemie detektory światła, jak tworzy się mesh, co to jest zakłucanie opcodów, jak dzialają bezpieczniki, gdzie są te "kabelki"? Wybacz. Obejrzyj choć linka ktory podesłalem aby móc pojąć jak głupim konceptem są te kabelki.

Ja się pytam o model użycia TPMa w którym absolutnie byłbyś w stanie udowodnić, że jakąś operację wykonałeś lub nie.
Chwilę dalej piszesz o kryptografii, matematyce informatyce a Ty nawijasz coś o kabelkach i kryształkach krzemowych. Dobra, załóżmy że nie da się wyciągnąć danych z tego scalaka. Nie będę się o to spierał.

Pytam o model użycia TPMa w którym absolutnie byłbyś w stanie udowodnić, że jakąś operację wykonałeś lub nie. Niezaprzeczalność i integralność to cechy charakterystyczne niektórych operacji kryptograficznych, ale nie napisałeś jak zastosować TPMa, gdzie dostajesz go w kopercie z banku (a może nie z banku) i bank absolutnie nie może Ci zarzucić, że pewne operacje nie były przez Ciebie autoryzowane.

, a ludzi
 potencjalnie sprytniejszych od Cieie (managerów bankowych doskonale
 orientujących się w dostępnych na rynku technologiach bezpieczeństwa)
 wyzywasz od debiili.

Mam konta w 3 bankach. Kazdy z nich tworzy frontend usera zdecydowanie glupszy od poprzedniego, bardziej niebezpieczny, generujacy setki potencjalnych kłopotów i dróg przez ktore może dostać się malware. Po drugie wiekszość z nich uzyskała śmieciowe technicznie wykształcenie. Sugerujesz że misiaczek po marketingu bądź bankowości "świetnie orientuje się w technologii"? Zapewne świetnie orientuje się w kolorach słupkow idących w góre i w dół. Ale żeby w krzemie, ftu, silikonie? Szacun, panie. Gdzie nie spojrzeć, ekspert od kryptografii albo fizyki ciała stałego i jeszcze zarządzać bankiem umi.

Widocznie wyliczyli, że taniej im zapłacić 10 razy w roku po 20 tysięcy niż milion razy po 5 dolarów. Konta z tokenami zapewne na rynku istnieją dla chętnych.

 Skoro uważasz że ten TPM jest takim lekarstwem na
 całe zło to powiedz na jakiej podstawie tak twierdzisz?

Matematycznej. Niestety nie twierdze że na całe, bo na przykład upierniczylo mi wczoraj miernik przepiecie i na to nie poradzi. Na Pawłowicz w Sejmie też. Jest duzo przypadków gdzie sobie nie poradzi. tak, że nie wszystkie. Ale na autoryzację/autentykację czy inną cykację ma szanse lepszą niż panienka żądająca nazwiska panieńskiego babki.

 Że niby generuje
 się w nim niemożliwy do wyciągnięcia klucz prywatny i wszystkie operacje
 są nim podpisywane?

Nie. Tak. Może. Zależy. W końcu to producent decyduje co można tym zrobić. Można tez powoli migać diodą co może byc interesującą dodatkową opcją security dla biznesmenów.

Napisałeś już w dyskusji ze mną z 5 długich postów. Albo przestań pisać albo opisz konkretny przypadek użycia tego TPMa. Ja opisałem jeden:
"Bank wysyła urządzenie do klienta z już wygenerowanym kluczem prywatnym (którego nigdy nie opuszcza scalaka), sobie zostawia publiczny. Wszystkie operacje są podpisywane (w urządzeniu) przez klucz prywatny. Aplikacja bamnkowa jest podpisana żeby było wiadomo, że żaden malware nie prosi o podpis."

To jeden z możliwych scenariuszy. Wyśmiałeś go i OK, ale sam nie podałeś lepszego.

 Że aplikacja, która żąda tego podpisu też musi być
 podpisana?

A po ch... Zasadą działania TPM jest to że może pracować w kompie z milionem wirusów, trojanów, malware. I nic. Dalej jest trusted i pozwala na bezpieczne przeprowadzanie operacji. Zabawne jak ten zdrowy rozsądek nijak nie pasuje do rzeczywistości, nie?

Opisałem wyżej po co aplikacja bankowa ma być podpisana. Pewnie da się i bez tego, ale nie opisałeś więc tego nie wiemy.

 Nie wiem jak w takim wypadku przebiega przekazanie klucza
 publicznego do banku.

Nie jest przekazywany. Zmartwie Cie jednak: od jakiś 30 lat przekazujemy klucze przez nieszyfrowany internet i robimy to bezpiecznie. Ale tutaj nie musimy.

Owszem, klucza publicznego nie musisz szyfrować. Jeśli jednak go nie podpiszesz (a nie masz go czym podpisać, bo dopiero ustanawiasz relację z bankiem) to bank nie może mieć pewności, że należy on do Ciebie.

 Pewnie bank sam tego TPMa używa żeby dostać klucz
 publiczny i potem wysyła z już wygenerowanym prywatnym

Nie masz pojecia o kryptografii.

O Twojej faktycznie nie mam pojęcia.

, ale nie jestem
 pewien czy można ufać jakiemuś chińskiemu scalakowi przy którym
 manipulowali bankowcy

Ufasz zatem:
a) bandzie studentów impelemntujacych systemy bankowe "na produkcji"
b) stadzie prawników ktorych głownym powodem istnienia jest egzekwowanie sprawiedliwości w sposób mądry i jakże bezinteresowny
b) kasjerom ktorzy autoryzują milionowe przelewy koslawym znaczkiem nazywanym podpisem i własna oceną jakości makijażu

Nigdy nie poddawałem w wątpliwość tego, że TPM (czy jakakolwiek inna podobna technologia, odwołałem się wcześniej do SGX i HSM) podnosi bezpieczeństwo, ale zakwestionowałem Twoje słowo "absolutnie" w stosunku do oferowanego poziomu bezpieczeństwa.

, bo jak poznam czy to co dostałem nie jest czymś o
 tym samym API ale z już wyciągniętym kluczem prywatnym?

Nie masz pojecia o kryptografii.

Powtarzasz się.

On Sun, 20 Mar 2016, Rafal Jankowski wrote:

 Konkrety masz przed soba. Internet się to nazywa. Spodziewasz się że
 pokaże Ci jak robi się w krzemie detektory światła, jak tworzy się mesh,
 co to jest zakłucanie opcodów, jak dzialają bezpieczniki, gdzie są te
 "kabelki"? Wybacz. Obejrzyj choć linka ktory podesłalem aby móc pojąć jak
 głupim konceptem są te kabelki.

Ja się pytam o model użycia TPMa w którym absolutnie byłbyś w stanie udowodnić, że jakąś operację wykonałeś lub nie.
Chwilę dalej piszesz o kryptografii, matematyce informatyce a Ty nawijasz coś o kabelkach i kryształkach krzemowych. Dobra, załóżmy że nie da się wyciągnąć danych z tego scalaka. Nie będę się o to spierał.

Hm, miałem się nie czepiać wyciągania klucza ze scalaka, ale caly filmik jest o tym jak gościu się onanizuje skrobaniem tego TPMa i jechaniem po jego producentach jak po łysych psach. W okolicy 15:55 jeśli dobrze słyszę dorzuca jeszcze coś o gościach którzy shackowali Nagravision, całkiem zdaje się jak na swoje czasy przyzwoity DRM naszego ziomala Kudelskiego. Ale nie ważne, powiedzmy, że to wszystko dotyczy starych chipów i że te nowe są już dobre i bezpieczne. Załóżmy, że współcześnie stosowane algorytmy kryptograficzne też są bezpieczne bo jak sam zauważyłeś komputerów kwantowych pod naszą strzechą przez jakiś czas jeszcze się nie ma co spodziewać. Jedyną rzeczą jakiej mam zamiar się przyczepić to sposób użycia i wdrożenia tego cuda, ale czekam aż tą procedurę opiszesz.

Rafal Jankowski <jankowsr@oceanic.wsisiz.edu.pl> writes:

Hm, miałem się nie czepiać wyciągania klucza ze scalaka, ale caly
filmik jest o tym jak gościu się onanizuje skrobaniem tego TPMa i
jechaniem po jego producentach jak po łysych psach. W okolicy 15:55
jeśli dobrze słyszę dorzuca jeszcze coś o gościach którzy shackowali
Nagravision, całkiem zdaje się jak na swoje czasy przyzwoity DRM
naszego ziomala Kudelskiego. Ale nie waĹźne, powiedzmy, Ĺźe to wszystko
dotyczy starych chipów i że te nowe są już dobre i bezpieczne.

To nieważne, ale dlatego, że w praktyce wymaga fizycznego dostępu,
oraz dlatego, że łamanie TPMa byłoby tu niezbyt przydatne.
--
Krzysztof Hałasa

On Tue, 22 Mar 2016, Krzysztof Halasa wrote:

Rafal Jankowski <jankowsr@oceanic.wsisiz.edu.pl> writes:

Hm, miałem się nie czepiać wyciągania klucza ze scalaka, ale caly
filmik jest o tym jak gościu się onanizuje skrobaniem tego TPMa i
jechaniem po jego producentach jak po łysych psach. W okolicy 15:55
jeśli dobrze słyszę dorzuca jeszcze coś o gościach którzy shackowali
Nagravision, całkiem zdaje się jak na swoje czasy przyzwoity DRM
naszego ziomala Kudelskiego. Ale nie waĹźne, powiedzmy, Ĺźe to wszystko
dotyczy starych chipów i że te nowe są już dobre i bezpieczne.

To nieważne, ale dlatego, że w praktyce wymaga fizycznego dostępu,
oraz dlatego, że łamanie TPMa byłoby tu niezbyt przydatne.

Owszem, ale ja nie podważałem przydatności TPMa tylko "absolutnej pewności" jaką on daje. A fizycznego dostępu nie można wykluczyć. A więc jest możliwy (bardzo trudny do zrealizowania, ale mówimy o "absolutnej pewności") scenariusz, że ten klucz zostanie wyskrobany a transakcja przeprowadzona w momencie gdy użytkownik jest w posiadaniu tokena.

On 2016-03-22 08:46, Rafal Jankowski wrote:

Owszem, ale ja nie podważałem przydatności TPMa tylko "absolutnej
pewności" jaką on daje.

Zauważyłeś że TMP sa słabo zabezpieczne przed pierdolnięciem meteorytu? Skandal. Panienka pytająca o nazwiska w rodzinie po założeniu garnka na glowę mogła by więcej wytrzymać.

A fizycznego dostępu nie można wykluczyć.

Ba, a jesli ten meteoryt to statek marsjan ablo mesjasz albo kupa zamarzniętego moczu z samolotu? Niczego nie można wykluczyć.

Innymi slowy wracamy do czeków podpisanych kulfonem i wydawanych na gębę. Albo nie, czekaj, przelewy faksem. To jest dopiero pewność i bezpieczeństwo w jednym.

A więc
jest możliwy (bardzo trudny do zrealizowania, ale mówimy o "absolutnej
pewności") scenariusz, że ten klucz zostanie wyskrobany a transakcja
przeprowadzona w momencie gdy użytkownik jest w posiadaniu tokena.

Tak, podobnie jak pierdolnięcie meteorytu. Musimy to brać pod uwage, prawda? To kluczowe że z TPMa mozna wyskrobać hasło do konta kowalskiego już za tylko 1mln dolarów. To calkowicie dyskwalifikuje tą technologię. No i jak zwykle zostają podpisy i panienki od interesujących pytań.

PS. Tak wiem, zaraz napiszeszm maila o tym jakim chamem jestem że takie chamskie mam odzywki. Ale przepraszam, na Twoj poziom absurdu traktowany poważnie jedyną odtrutką jest poziom absurdu do kwadratu.

On Wed, 23 Mar 2016, Sebastian Biały wrote:

 A więc
 jest możliwy (bardzo trudny do zrealizowania, ale mówimy o "absolutnej
 pewności") scenariusz, że ten klucz zostanie wyskrobany a transakcja
 przeprowadzona w momencie gdy użytkownik jest w posiadaniu tokena.

Tak, podobnie jak pierdolnięcie meteorytu. Musimy to brać pod uwage, prawda? To kluczowe że z TPMa mozna wyskrobać hasło do konta kowalskiego już za tylko 1mln dolarów. To calkowicie dyskwalifikuje tą technologię. No i jak zwykle zostają podpisy i panienki od interesujących pytań.

Widzę, że nie rozumiesz słów których używasz - "absolutna pewność" w odniesieniu do czegoś co jest niepewne przy zainwestowaniu czegoś co kosztuje (jak twierdzisz) $1MUSD. Ale zdaje się, że co gorsze nie rozumiesz zbytnio linków które sam podsyłasz:

8:52 - I removed this shield with hydrofluorid acid in about two minutes
15:45-15:55 - you don't even need high tech equipment to image this ROM
44:20 [to repeat the process] on infineon it took me 6 hours, on ST(?) significantly less

PS. Tak wiem, zaraz napiszeszm maila o tym jakim chamem jestem że takie chamskie mam odzywki. Ale przepraszam, na Twoj poziom absurdu traktowany poważnie jedyną odtrutką jest poziom absurdu do kwadratu.

Nie, nie jesteś chamem. Jesteś zwykłym głupkiem.

On 2016-03-23 19:02, Rafal Jankowski wrote:

Widzę, że nie rozumiesz słów których używasz - "absolutna pewność" w
odniesieniu do czegoś co jest niepewne przy zainwestowaniu czegoś co
kosztuje (jak twierdzisz) $1MUSD. Ale zdaje się, że co gorsze nie
rozumiesz zbytnio linków które sam podsyłasz:
8:52 - I removed this shield with hydrofluorid acid in about two minutes
15:45-15:55 - you don't even need high tech equipment to image this ROM
44:20 [to repeat the process] on infineon it took me 6 hours, on ST(?)
significantly less

Może nalezy wobec tego obejrzeć inny:

https://www.youtube.com/watch?v=62DGIUpscnY

a) aktywny mesh
b) sensory światła
c) manglowane opcody
d) detekcja kombinowania z rejestrami
e) pierdyliard innych zabezpieczeń przed fizycznym ingerowaniem w chip

Po drugiej stronie siedzi sliniacy się wpierniczacz pizzy który odpowiada za 99% ataków na konta Kolwaskiego przez maile z fakturami.

Masz tam swoje mln dolarów, podczas prezentacji pada kwota jaka jest potrzebna do wyjęcia tego co chcesz. Nie, tym razem nie używa się szkla powiększającego, zaostrzonego ołówka ani kilku przylutowanych drucików Lutolą.

Tak, koleś podnieca się domieszkowanym krzemem z naplutym aluminium. To dalece odbiega od podniecania się kolorowymi słupkami w power poincie, rozumiem to.

No i zawsze pozostaje ewentualnośc że może pierdalnąć meteoryt i klucz się wysypie z krzemu na podlogę!

Nie, nie jesteś chamem. Jesteś zwykłym głupkiem.

Kilka razy pytalem lekarzy czy da się takie zaświadczenie wystawic, ale zazwyczaj pukali się w głowe że chyba glupi jestem. Więc niestety nie mogę potwierdzić. Ale żem cham - to chyba mogę bez zaświadczeń.

On 2016-03-21 01:10, Rafal Jankowski wrote:

Hm, miałem się nie czepiać wyciągania klucza ze scalaka, ale caly filmik
jest o tym jak gościu się onanizuje skrobaniem tego TPMa

Myslę żen ie pojąłeś kuczowego: kazdy kto będzie chciał wydlubać klucz bedzie musial skrobać scalak. Współczesnie sprzęt do skrobania jest tylko w kilku(nastu) egzemplarzach i jest to zagadnienie nietrywialne. Tu jest *powód* dla którego TPM stosuje się w informatyce.

Kudelskiego. Ale nie ważne, powiedzmy, że to wszystko dotyczy starych
chipów i że te nowe są już dobre i bezpieczne.

Żaden nie jest bezpieczny. Ale jesli wydlubanie klucza kosztuje 1mln czegokolwiek to są one *wystarczająco* bezpieczne.

jeszcze się nie ma co spodziewać. Jedyną rzeczą jakiej mam zamiar się
przyczepić to sposób użycia i wdrożenia tego cuda, ale czekam aż tą
procedurę opiszesz.

To proste. Odkładasz katalog z jachtami. Ruszasz swoją tłusta dupe żeby przeczytać co to jest kryptografia. Prosisz o pomoc kogokolwiek kto ma pojęcie o naukach ścisłych i aż do bólu starasz się przegryźć te wszystkie nowe pojęcia. Razem dajecie rade pojąć że technologia istnieje od bardzo dawana. I teraz najwazniejsze: masz dwie opcje, pierwsza polega na olaniu tematu i przeglądaniu dalej katalogu z jachtami, druga polega na zaryzykowaniu. Poniewaz jachty sa bardziej interesujące niż ryzykowanie to to wdrożenie nie ma szans. No chyba że ktos jest charyzmatycznym wizjonerem. Ale takich nie znajdziesz w korposzczurach awansujących do debilomanagerów.

PS. Tak naprawde to proste: zamawiasz kilkaset scalaków, robicie testy i jak się uda to wprowadzacie rekami chińczyków wersje dla biznesu w szczotkowanym aluminium reklamując go jako "nawet mafia uzywa" albo coś w ten deseń. Potem stopniowo dajesz każdemu i już można w TV brylować jaki ten bank nowoczesny i jak wielu mądrych ludzi ma. I pierś wypinać po następny medal dyrektora miesiąca. Tak, calośc tego procesu wymaga obecności elektroników, projektantów, matematyków, administratorów itp plebsu. Ale przeciez dyrektor doskonale orientujący się w nowinkach technicznych powinien mieć śladowe o tym pojęcie, więc co ja bedę tlumaczył.

Rafal Jankowski <jankowsr@oceanic.wsisiz.edu.pl> writes:

"Bank wysyła urządzenie do klienta z już wygenerowanym kluczem
prywatnym (ktĂłrego nigdy nie opuszcza scalaka), sobie zostawia
publiczny. Wszystkie operacje są podpisywane (w urządzeniu) przez
klucz prywatny. Aplikacja bamnkowa jest podpisana żeby było wiadomo,
Ĺźe Ĺźaden malware nie prosi o podpis."

To jeden z możliwych scenariuszy. Wyśmiałeś go i OK, ale sam nie
podałeś lepszego.

Nie jest najlepszy, bo zawsze można wtedy bankowi zarzucić, że sam sobie
podpisał zlecenie. Jeśli już się w ogóle bawimy w kryptografię
asymetryczną, to klucz prywatny powinien być generowany w tokenie,
a bank dostawałby tylko część publiczną, w obecności klienta.

Ale to trudniejsze w uĹźyciu niĹź wersja z challenge & response.
--
Krzysztof Hałasa

On Tue, 22 Mar 2016, Krzysztof Halasa wrote:

Rafal Jankowski <jankowsr@oceanic.wsisiz.edu.pl> writes:

"Bank wysyła urządzenie do klienta z już wygenerowanym kluczem
prywatnym (ktĂłrego nigdy nie opuszcza scalaka), sobie zostawia
publiczny. Wszystkie operacje są podpisywane (w urządzeniu) przez
klucz prywatny. Aplikacja bamnkowa jest podpisana żeby było wiadomo,
Ĺźe Ĺźaden malware nie prosi o podpis."

To jeden z możliwych scenariuszy. Wyśmiałeś go i OK, ale sam nie
podałeś lepszego.

Nie jest najlepszy, bo zawsze można wtedy bankowi zarzucić, że sam sobie
podpisał zlecenie. Jeśli już się w ogóle bawimy w kryptografię
asymetryczną, to klucz prywatny powinien być generowany w tokenie,
a bank dostawałby tylko część publiczną, w obecności klienta.

Ale to trudniejsze w uĹźyciu niĹź wersja z challenge & response.

Zakładamy, że transakcja została podpisana kluczem z TPMa, który go nie opuścił, więc tak czy inaczej musiałby ją podpisać użytkownik jedynie na podstawie tego co wyświetla mu aplikacja (też podpisana). Wówczas teoretycznie można zweryfikować czy taka aplikacja mogła wyświetlić userowi coś innego a co innego podpisać. Może jeszcze coś przeoczyłem. To oczywiście nie jest takie proste ale to najlepszy scenarusz który w danej chwili przyszedł mi do głowy i (zwróć uwagę) to w dodatku nie jako kandydadat do wdrożenia tylko punkt wyścia do mojej uwagi że sam TPM nie jest rozwiązaniem problemu nieautoryzowanych transakcji. Problem w tym, że mój przedpiśca mnie wyśmiał, a sam poza zapodaniem hasła TPM nic lepszego w sumie nie zaproponował.

Rafal Jankowski <jankowsr@oceanic.wsisiz.edu.pl> writes:

Zakładamy, że transakcja została podpisana kluczem z TPMa, który go
nie opuścił, więc tak czy inaczej musiałby ją podpisać użytkownik
jedynie na podstawie tego co wyświetla mu aplikacja (też podpisana).
Wówczas teoretycznie można zweryfikować czy taka aplikacja mogła
wyświetlić userowi coś innego a co innego podpisać.

Co tu weryfikować, przecież wiadomo że mogła.
--
Krzysztof Hałasa

On Tue, 22 Mar 2016, Krzysztof Halasa wrote:

Rafal Jankowski <jankowsr@oceanic.wsisiz.edu.pl> writes:

Zakładamy, że transakcja została podpisana kluczem z TPMa, który go
nie opuścił, więc tak czy inaczej musiałby ją podpisać użytkownik
jedynie na podstawie tego co wyświetla mu aplikacja (też podpisana).
Wówczas teoretycznie można zweryfikować czy taka aplikacja mogła
wyświetlić userowi coś innego a co innego podpisać.

Co tu weryfikować, przecież wiadomo że mogła.

Może tak, sam podpis przez Bank faktycznie niczego tu nie daje, ale jeśli dodatkowo znany jest jej hash i on był częścią tego co podpisał TPM to można wymagać od banku aby dostarczył kod źródłowy z którego da się skompilować aplikację o takim właśnie hashu i wtedy to już można stwierdzić czy aplikacja ma zaimplementowaną logikę, która może robić taki wał. Nie twierdzę, że to najlepsze zaadresowanie tego problemu, ale jakieś jest.

On Tue, 22 Mar 2016, Rafal Jankowski wrote:

[...]

Może tak, sam podpis przez Bank faktycznie niczego tu nie daje, ale jeśli dodatkowo znany jest jej hash i on był częścią tego co podpisał TPM to można wymagać od banku aby dostarczył kod źródłowy z którego da się skompilować aplikację o takim właśnie hashu i wtedy to już można stwierdzić czy aplikacja ma zaimplementowaną logikę, która może robić taki wał. Nie twierdzę, że to najlepsze zaadresowanie tego problemu, ale jakieś jest.

Mała autokorekta. To powyżej też jest słabe, bo przecież bank może wypuścić aplikację dobrą i złą i ta zła będzie dawać do podpisu hash tej dobrej. Ja chyba odpuszczam temat bo w końcu to miałem być oskarżycielem tego rozwiązania a stałem się jego autorem i obrońcą ;).
Inna sprawa, że w wersji z tokenem, który ma kamerkę i tą kamerką zczytuje kod QR z zawirusowanego systemu też mamy problem tego typu, że na tym tokenie musi być aplikacja zaufana, więc jak bank nie jest zaufany to mamy dokładnie ten sam problem. Pewnie i to da się jakoś rozwiązać, ale mi się już chyba nie chce kombinować, bo ja tu miałem być od czepiania się a nie od podawania rozwiązań.

Rafal Jankowski <jankowsr@oceanic.wsisiz.edu.pl> writes:

Inna sprawa, że w wersji z tokenem, który ma kamerkę i tą kamerką
zczytuje kod QR z zawirusowanego systemu też mamy problem tego typu,
że na tym tokenie musi być aplikacja zaufana, więc jak bank nie jest
zaufany to mamy dokładnie ten sam problem. Pewnie i to da się jakoś
rozwiązać, ale mi się już chyba nie chce kombinować, bo ja tu miałem
być od czepiania się a nie od podawania rozwiązań.

Jeśli nie ufamy bankowi, to niestety problem jest nierozwiązywalny -
przynajmniej do momentu, w którym sami jesteśmy w stanie zbudować sobie
system do podpisywania zleceń. Ale to nie jest nasz aktualny problem.

Zakładamy, że bankowi możemy jednak ufać. To m.in. dlatego nie wymagamy
od klienta bezpiecznego podpisu cyfrowego, a jedynie jakieś tam kody
autoryzujące.
Bank może dać nam (klientowi) bezpieczne urządzenie (token), który
będzie wyświetlał nam na ekranie szczegóły zlecanej właśnie operacji,
oraz (w przypadku akceptacji) będzie informował bank, np. wyświetlając
kod jednorazowy, który wklepiemy w przeglądarkę. To jest rozwiązanie
bezpieczne (wystarczająco).

Jeśli coś takiego będziemy mieć w np. telefonie, albo w ogóle w pececie,
to niestety nie będzie to bezpieczne, ponieważ na tych urządzeniach
instalujemy nie wiadomo jaki soft, i nie możemy mieć do nich żadnego
zaufania. TPM ani nic podobnego też nam go nie zapewni. Musimy mieć
urządzenie, na którym w praktyce nie można nic zainstalować, najlepiej
odporne na zanurzanie w wodzie, na upadki na podłogę itd.

Stąd (często wykorzystywana) koncepcja kamery z kodem QR, trzeba jedynie
zadbać by program czytający QR przypadkiem nie wykonał tego, co
przeczyta (a tylko wyświetlał to, liczył odpowiednie m.in. hashe
i generował odpowiedź).
--
Krzysztof Hałasa

On Mon, 28 Mar 2016, Krzysztof Halasa wrote:

Zakładamy, że bankowi możemy jednak ufać.

No ale to założenie nie jest niezbędne. Wystarczy przecież, że bank opublikuje kody źródłowe aplikacji i (dla uproszczenia) binarki na tego tokena. Wówczas klient może sobie tokena kupić w dowolnym miejscu i wgrać samemu a klucz publiczny dostarczyć do biura banku z dowodem tożsamości.

Rafal Jankowski <jankowsr@oceanic.wsisiz.edu.pl> writes:

Zakładamy, że bankowi możemy jednak ufać.

No ale to założenie nie jest niezbędne. Wystarczy przecież, że bank
opublikuje kody źródłowe aplikacji i (dla uproszczenia) binarki na
tego tokena. Wówczas klient może sobie tokena kupić w dowolnym miejscu
i wgrać samemu a klucz publiczny dostarczyć do biura banku z dowodem
tożsamości.

To nie wystarczy. Przede wszystkim, nie wiadomo czy potrzebujemy w ogóle
kluczy asymetrycznych. Po drugie, "wgrywanie aplikacji" do tokena (bez
jego destrukcji) nie powinno być specjalnie łatwe, gdyż w przeciwnym
razie ktoś mający przez chwilę dostęp do tokena (niekoniecznie po
stronie klienta, może to być pracownik banku) mógłby go przeprogramować.
Jasne jest chyba, że 99%+ klientów nie będzie tam nic instalować.

Podpisywanie zleceń bankowych kluczem prywatnym to oczywiście nie SF
i jest to stosowane od lat, ale raczej nie w przypadku klientów
indywidualnych (poza ew. częścią private).
--
Krzysztof Hałasa

On Tue, 29 Mar 2016, Krzysztof Halasa wrote:

To nie wystarczy. Przede wszystkim, nie wiadomo czy potrzebujemy w ogóle
kluczy asymetrycznych. Po drugie, "wgrywanie aplikacji" do tokena (bez
jego destrukcji) nie powinno być specjalnie łatwe, gdyż w przeciwnym
razie ktoś mający przez chwilę dostęp do tokena (niekoniecznie po
stronie klienta, może to być pracownik banku) mógłby go przeprogramować.
Jasne jest chyba, że 99%+ klientów nie będzie tam nic instalować.

Ktoś mający przez chwilę dostęp do tokena jest w posiadaniu znajdującego się w nim klucza (w sensie: może go użyć) jeśli nie mamy dodatkowych zabezpieczeń które powiązują token z osobą. Jeżeli aplikację wgrywa bank to:

- po pierwsze w dalszym ciągu można postawić mu zarzut "daliście mi token
   z kluczem i aplikacją, a teraz mówicie, że transakcja była
   uwierzytelniona bo tak wskazuje wasz system informatyczny". W przypadku
   gdy klient sam generuje klucz i wgrywa aplikację taki zarzut pod adresem
   banku już jest niemożliwy

- po drugie wyobrażam sobie że można wtedy dość skutecznie przeprowadzić
   od strony banku atak ukierunkowany na konkretną osobę wysyłając coś co w
   rzeczywistości bezpiecznym tokenem nie jest a klucz prywatny ma
   atakujący. Jak dyrektor banku przeczyta, że ktoś go zwyzywał na niusach
   od debili to ma pokusę aby to zrobić. Jeśli w token każdy zaopatruje się
   indywidualnie i anonimowo tudzież w podobny sposób wgrywa aplikację to
   taki atak jest właściwie wykluczony.

Piszesz, że nie koniecznie potrzebujemy kluczy asymetrycznych. Możesz wyjaśnić jak to się odbywa bez takich kluczy? Wyobrażam sobiem, że taki sam klucz symetryczny musiałby powstać jednocześnie w tokenie użytkownika i infrastrukturze banku. Ale zakładając, że wogóle on nie powinien opuszczać chipa jest to jakieś wyzwanie technologiczne. Rozumiem, że coś na kształt takiej technologii istnieje? Chodzi o provisionowanie klucza na zasadzie jakiegoś DRMa? Możesz podać jakieś hasło albo wyjaśnienie o co chodzi?

Rafal Jankowski <jankowsr@oceanic.wsisiz.edu.pl> writes:

Ktoś mający przez chwilę dostęp do tokena jest w posiadaniu
znajdującego się w nim klucza (w sensie: może go użyć) jeśli nie mamy
dodatkowych zabezpieczeń które powiązują token z osobą. Jeżeli
aplikację wgrywa bank to:

- po pierwsze w dalszym ciągu można postawić mu zarzut "daliście mi token
  z kluczem i aplikacją, a teraz mówicie, że transakcja była
  uwierzytelniona bo tak wskazuje wasz system informatyczny". W przypadku
  gdy klient sam generuje klucz i wgrywa aplikację taki zarzut pod adresem
  banku już jest niemożliwy

Owszem, ale 99,xxx% klientów banku nie potrafi tego bezpiecznie zrobić.
Nie ma sensu rozważać takich sytuacji.
Po prostu należy założyć, że bank (ale niekoniecznie jego szeregowi
pracownicy) jest godny zaufania.

Alternatywą jest normalny podpis cyfrowy, ale to bardziej skomplikowane,
wymaga "przeszkolonego pracownika", i nie do zaoferowania klientowi
indywidualnemu. Zresztą w sytuacji z przeszkolonym pracownikiem to także
zwykle nie jest bezpieczne, przecież jak przyjedzie serwisant z banku to
XX % ludzi da im pełny dostęp do wszystkiego. Po prostu to są
technologie dla specyficznych części wojska albo innych agencji itp.

- po drugie wyobrażam sobie że można wtedy dość skutecznie przeprowadzić
  od strony banku atak ukierunkowany na konkretną osobę wysyłając coś co w
  rzeczywistości bezpiecznym tokenem nie jest a klucz prywatny ma
  atakujący.

Dlatego napisałem, że programowanie tokena (inne niż
generowanie/ustawianie klucza) nie powinno być dostępne.

Jak dyrektor banku przeczyta, że ktoś go zwyzywał na niusach
  od debili to ma pokusę aby to zrobić.

Poważnie? Może jakiś partyjny dyrektor :-)

Jeśli w token każdy zaopatruje się
  indywidualnie i anonimowo tudzież w podobny sposób wgrywa aplikację to
  taki atak jest właściwie wykluczony.

Nie jest, każdy wie do czego służą takie tokeny i co może dać atak na
nawet niewielką część z nich. Przykład - afera w RSA Security
(i spowodowane nią włamania w Lockheedzie oraz przypuszczalnie wiele
innych, o których nie wiemy).

Piszesz, że nie koniecznie potrzebujemy kluczy asymetrycznych. Możesz
wyjaśnić jak to się odbywa bez takich kluczy? Wyobrażam sobiem, że
taki sam klucz symetryczny musiałby powstać jednocześnie w tokenie
użytkownika i infrastrukturze banku. Ale zakładając, że wogóle on nie
powinien opuszczać chipa jest to jakieś wyzwanie technologiczne.

Bez problemu, bank może generować klucz i zapisywać go w tokenie (typowy
schemat). User także może zapisać nowy klucz (przy odrobinie wysiłku) -
token przestanie wtedy "działać" z bankiem.

Rozumiem, że coś na kształt takiej technologii istnieje?

Tak naprawdę to nie jest nawet żadna specyficzna technologia, to tak
jakby pytać o technologię kalkulatora.

Ja osobiście nie zajmuje się projektowaniem dokładnie takich rzeczy,
ale jakbym miał coś takiego zrobić, to sprawa byłaby prosta: Cortex M4,
wyświetlacz OLED 3"+, touchscreen MT, akumulator, mała kamera. Ew. USB
jako "wyjście" (emulacja klawiatury?). Sklejona obudowa.

Chodzi o
provisionowanie klucza na zasadzie jakiegoś DRMa?

Rozwiniesz skrót? Żaden mi nie pasuje. Generalnie to są proste rzeczy,
aczkolwiek niewątpliwie wiele "zamkniętych" implementacji było
wadliwych. Teraz można zamówić taki sprzęt "pod klucz" w niewielkich
seriach (nie tylko w kontekście banku). Kryptograficznie wszystko składa
się ze znanych klocków - AES, SHA, RSA itd.
--
Krzysztof Hałasa

On 2016-03-22 08:43, Rafal Jankowski wrote:

jest rozwiązaniem problemu nieautoryzowanych transakcji. Problem w tym,
że mój przedpiśca mnie wyśmiał

Wyśmiałem pomysły rodem ze średniowecza o ktorych w kółko pisaleś jak to trzeba klucze wymieniać przez internet. NIE TRZEBA. NIE WOLNO. TMP działa w taki sposób że klucz istnoeje tylko w nim i jest niewyjmowalny. Jest to na tyle pewne że spokojnie stosuje się klucze symetryczne i nie ma w tym nic dziwnego.

, a sam poza zapodaniem hasła TPM nic
lepszego w sumie nie zaproponował.

Sami do tego powoli dochodzicie. Wystarczyu zamiast krytykować po prostu chwile pomyśleć.

TMP może podpisywać kanał komunikacyjny z bankiem i jednoczesnie wyświetlać na wyswietlaczu dane transakcji. Nie ma tutaj zadnej aplikacji poza prostym kawalkiem kodu który robi za transparent proxy internet<->dongle. Komunikacja nawet nie musi być szyfrowana, choć pewno to wskazane z powodu ochrony danych. TMP tylko podpisuje strumień bajtów po uprzednim wyświetleniu i potwierdzeniu pinem na własnej klawiaturze. Wsijo. Ten prymitywny sposób jest wystarczający aby załatwić *najpopularniejszy* obecnie sposób wykradania pieniędzy z kont. Albo można udawać idiote, jak robią wszystkie banki.

On Wed, 23 Mar 2016, Sebastian Biały wrote:

On 2016-03-22 08:43, Rafal Jankowski wrote:

 jest rozwiązaniem problemu nieautoryzowanych transakcji. Problem w tym,
 że mój przedpiśca mnie wyśmiał

Wyśmiałem pomysły rodem ze średniowecza o ktorych w kółko pisaleś jak to trzeba klucze wymieniać przez internet. NIE TRZEBA. NIE WOLNO. TMP działa w taki sposób że klucz istnoeje tylko w nim i jest niewyjmowalny. Jest to na tyle pewne że spokojnie stosuje się klucze symetryczne i nie ma w tym nic dziwnego.

Symetryczny klucz niewyjmowalny? Szkoda tylko, że bank nie będzie miał jak odszyfrować tego co TPM zaszyfruje.

, a sam poza zapodaniem hasła TPM nic
 lepszego w sumie nie zaproponował.

Sami do tego powoli dochodzicie. Wystarczyu zamiast krytykować po prostu chwile pomyśleć.

TMP może podpisywać kanał komunikacyjny z bankiem i jednoczesnie wyświetlać na wyswietlaczu dane transakcji. Nie ma tutaj zadnej aplikacji poza prostym kawalkiem kodu który robi za transparent proxy internet<->dongle. Komunikacja nawet nie musi być szyfrowana, choć pewno to wskazane z powodu ochrony danych. TMP tylko podpisuje strumień bajtów po uprzednim wyświetleniu i potwierdzeniu pinem na własnej klawiaturze. Wsijo. Ten prymitywny sposób jest wystarczający aby załatwić *najpopularniejszy* obecnie sposób wykradania pieniędzy z kont. Albo można udawać idiote, jak robią wszystkie banki.

Czyli mam wierzyć, że ten kawałem plastiku z krzemem, który dostałem w kopercie od banku jest bezpiecznym urządzeniem przy którym nikt nie majstrował, a tą aplikację co wgrywał do TPMa bank pisali dobrzy ludzie?

On 2016-03-23 19:10, Rafal Jankowski wrote:

Symetryczny klucz niewyjmowalny? Szkoda tylko, że bank nie będzie miał
jak odszyfrować tego co TPM zaszyfruje.

Ale te krypotologi głupie głupki. Cale szczęscie dowiedzieli się na newsach że kryptografia symetryczna polega na posiadaniu jednego ezemplarza niewyjmowalnego klucza. A te głupki myslały że klucz posiada rowniez bank! Haha.

Czyli mam wierzyć, że ten kawałem plastiku z krzemem, który dostałem w
kopercie od banku jest bezpiecznym urządzeniem przy którym nikt nie
majstrował, a tą aplikację co wgrywał do TPMa bank pisali dobrzy ludzie?

Tak. Tak samo jak wierzysz że kasjer w twoim banku jest zawodowym grafologiem. W profesjonalnej bankowości słowo harcerza jest niezwykle ważnym składnikiem bezpieczeństwa!

https://zaufanatrzeciastrona.pl/post/prawie-udany-skok-na-150-milionow-dolarow-za-pomoca-podrobionego-faksu/

PS. Kawałek plaskiku który masz obecnie w portfelu był projektowany przez imbecyli:

https://niebezpiecznik.pl/post/karty-kredytowe-z-chipem-podatne-na-atak/

On Wed, 23 Mar 2016, Sebastian Biały wrote:

On 2016-03-23 19:10, Rafal Jankowski wrote:

 Symetryczny klucz niewyjmowalny? Szkoda tylko, że bank nie będzie miał
 jak odszyfrować tego co TPM zaszyfruje.

Ale te krypotologi głupie głupki. Cale szczęscie dowiedzieli się na newsach że kryptografia symetryczna polega na posiadaniu jednego ezemplarza niewyjmowalnego klucza. A te głupki myslały że klucz posiada rowniez bank! Haha.

Możesz ten bełkot ubrać ten bełkot w jakąś sensowną logikę?

 Czyli mam wierzyć, że ten kawałem plastiku z krzemem, który dostałem w
 kopercie od banku jest bezpiecznym urządzeniem przy którym nikt nie
 majstrował, a tą aplikację co wgrywał do TPMa bank pisali dobrzy ludzie?

Tak. Tak samo jak wierzysz że kasjer w twoim banku jest zawodowym grafologiem. W profesjonalnej bankowości słowo harcerza jest niezwykle ważnym składnikiem bezpieczeństwa!

https://zaufanatrzeciastrona.pl/post/prawie-udany-skok-na-150-milionow-dolarow-za-pomoca-podrobionego-faksu/

PS. Kawałek plaskiku który masz obecnie w portfelu był projektowany przez imbecyli:

https://niebezpiecznik.pl/post/karty-kredytowe-z-chipem-podatne-na-atak/

Ale po co mi to piszesz? Po to, żeby mi udowodnić że może być jeszcze gorzej? Ja po prostu zarzuciłem przedstawionemu modelowi bezpieczeństwa, że zakładasz tam zaufanie do banku po którym cały czas jedziesz w sytuacji gdy nie jest to konieczne. Że już nie wspomnę tej Twojej legendarnej "absolutnej pewności". W sumie to nawet nie bardzo zrozumiałem o co właściwie proponujesz bo ten paragraf powyżej o symetrycznej kryptografii gdzie tylko jedna strona zna klucz to jakieś pijackie mamrotanie a pisałeś to chyba jeszcze przed końcem meczu.

On 2016-03-24 08:42, Rafal Jankowski wrote:

On 2016-03-23 19:10, Rafal Jankowski wrote:

 Symetryczny klucz niewyjmowalny? Szkoda tylko, że bank nie będzie miał
 jak odszyfrować tego co TPM zaszyfruje.

Ale te krypotologi głupie głupki. Cale szczęscie dowiedzieli się na
newsach że kryptografia symetryczna polega na posiadaniu jednego
ezemplarza niewyjmowalnego klucza. A te głupki myslały że klucz
posiada rowniez bank! Haha.

Możesz ten bełkot ubrać ten bełkot w jakąś sensowną logikę?

Ma. Pokazuje że w sposob idiotyczny zakładasz że niejaki Biały miał na mysli istnienie jednego egzemplarza klucza symetrycznego mimo że między zdaniami była kropka i dotyczyły innych rzeczy.Z moich obserwacji wynika że na takie nadęte opinie najlepiej nadaje sie ironia bo luzuje krawat.

https://niebezpiecznik.pl/post/karty-kredytowe-z-chipem-podatne-na-atak/

Ale po co mi to piszesz? Po to, żeby mi udowodnić że może być jeszcze
gorzej?

Wrażasz już poraz kolejny opinie że nie ufasz programistom, sprzetowi, bankowi i diabli wiedza komu jeszcze. Jednocześnie ufasz (bo uzywasz, czy nie?) gównie zaimplementowanemu na kartach chipowych. Ja rozumiem że mozna mieć wątpliwości, alw twoje tezy zmierzają do pozostania przy przelewach na faks, panience od nazwisk panieńskich z czasów dinozaurów i kasjerów grafologów. To dopiero SZAMBO które kazdy bank nazywa cutting edge bezpieczeństwa. Czy rozumiesz dlaczego nazywam managerów i dyrektorów bankow idiotami zajętymi wertowaniem katalogow z jachtami?

Ja po prostu zarzuciłem przedstawionemu modelowi bezpieczeństwa,
że zakładasz tam zaufanie do banku po którym cały czas jedziesz w
sytuacji gdy nie jest to konieczne.

Ufać bedę matematyce. Na szczęscie bankowe przygłupy tym razem nie mają za dużo do spieprzenia bo technologia jest już używana.

Że już nie wspomnę tej Twojej
legendarnej "absolutnej pewności".

Legendarnej powiadasz? Nie wiedziałem że będę wygłaszał legendarne opinie. Jak rozumie twoja przesada "legendarna" jest dopuszczalna, ale moja "absolutna" już nie? OK, w koncu to newsy.

W sumie to nawet nie bardzo
zrozumiałem o co właściwie proponujesz bo ten paragraf powyżej o
symetrycznej kryptografii gdzie tylko jedna strona zna klucz to jakieś

Miedzy zdaniem o 1 egzemplarzu klucza a zdaniem o kryptografi symetrycznej była kropka. To dośc istotny element do zauważenia jeśli nie chce się wyjśc na trola internetowego.

pijackie mamrotanie a pisałeś to chyba jeszcze przed końcem meczu.

Nie pije w zasadzie żadnego alkocholu. Proponuje nie bawić się w domoroslego psychologa bo to nigdy nie działa.

On Thu, 24 Mar 2016, Sebastian Biały wrote:

On 2016-03-24 08:42, Rafal Jankowski wrote:

>  On 2016-03-23 19:10, Rafal Jankowski wrote:
> >   Symetryczny klucz niewyjmowalny? Szkoda tylko, że bank nie będzie > >   miał
> >   jak odszyfrować tego co TPM zaszyfruje.
>  Ale te krypotologi głupie głupki. Cale szczęscie dowiedzieli się na
>  newsach że kryptografia symetryczna polega na posiadaniu jednego
>  ezemplarza niewyjmowalnego klucza. A te głupki myslały że klucz
>  posiada rowniez bank! Haha.
 Możesz ten bełkot ubrać ten bełkot w jakąś sensowną logikę?

Ma. Pokazuje że w sposob idiotyczny zakładasz że niejaki Biały miał na mysli istnienie jednego egzemplarza klucza symetrycznego mimo że między zdaniami była kropka i dotyczyły innych rzeczy.Z moich obserwacji wynika że na takie nadęte opinie najlepiej nadaje sie ironia bo luzuje krawat.

Te zdania przedstawiały jeden ciąg myślowy, więc kropka nie miała dla mnie istotnego znaczenia.

>  https://niebezpiecznik.pl/post/karty-kredytowe-z-chipem-podatne-na-atak/
 Ale po co mi to piszesz? Po to, żeby mi udowodnić że może być jeszcze
 gorzej?

Wrażasz już poraz kolejny opinie że nie ufasz programistom, sprzetowi, bankowi i diabli wiedza komu jeszcze. Jednocześnie ufasz (bo uzywasz, czy nie?) gównie zaimplementowanemu na kartach chipowych. Ja rozumiem że mozna mieć wątpliwości, alw twoje tezy zmierzają do pozostania przy przelewach na faks, panience od nazwisk panieńskich z czasów dinozaurów i kasjerów grafologów. To dopiero SZAMBO które kazdy bank nazywa cutting edge bezpieczeństwa.

Nie ufam jak nie muszę i nie uprzykrza mi to życia. Ale nie rozmawiajmy o mnie bo mi się zdarzało robić przelewy z konta hasłem jednorazowym wpisywanym w kafejce internetowej. Tak samo jak zdarzyło mi się po imprezie przelecieć bez gumki nie znaną mi bliżej panienkę. Z tym, że nie twierdzę, że to rozsądne i bezpieczne ani że nie można inaczej.

Czy rozumiesz dlaczego nazywam managerów i dyrektorów bankow idiotami zajętymi wertowaniem katalogow z jachtami?

Nie obrażaj ludzi którzy w miesiąc dymają więcej panienek i wpierdalają więcej kawioru i szampana niż Ty zapewne przez całe zycie.

 Ja po prostu zarzuciłem przedstawionemu modelowi bezpieczeństwa,
 że zakładasz tam zaufanie do banku po którym cały czas jedziesz w
 sytuacji gdy nie jest to konieczne.

Ufać bedę matematyce. Na szczęscie bankowe przygłupy tym razem nie mają za dużo do spieprzenia bo technologia jest już używana.

 Że już nie wspomnę tej Twojej
 legendarnej "absolutnej pewności".

Legendarnej powiadasz? Nie wiedziałem że będę wygłaszał legendarne opinie. Jak rozumie twoja przesada "legendarna" jest dopuszczalna, ale moja "absolutna" już nie? OK, w koncu to newsy.

Różnica między nami m.in. polega na tym, że ja tej Twojej "legendarności" nie zamierzam bronić jak Rejtan jeśli Ci ona nie pasuje.

 W sumie to nawet nie bardzo
 zrozumiałem o co właściwie proponujesz bo ten paragraf powyżej o
 symetrycznej kryptografii gdzie tylko jedna strona zna klucz to jakieś

Miedzy zdaniem o 1 egzemplarzu klucza a zdaniem o kryptografi symetrycznej była kropka. To dośc istotny element do zauważenia jeśli nie chce się wyjśc na trola internetowego.

Może przypomnę co napisałeś:

| Wyśmiałem pomysły rodem ze średniowecza o ktorych w kółko pisaleś jak to | trzeba klucze wymieniać przez internet. NIE TRZEBA. NIE WOLNO. TMP | działa w taki sposób że klucz istnoeje tylko w nim i jest niewyjmowalny. | Jest to na tyle pewne że spokojnie stosuje się klucze symetryczne i nie
| ma w tym nic dziwnego.

Problem polega na tym, że nie opisałeś szczegółowo całego procesu tylko rzuciłeś kilka haseł z których trzeba się domyślać Twojego toku rozumowania. Na razie zrozumiałem z niego tylko tyle, że zakładasz konieczność zaufania bankowi (który przesyła coś co jak należy założyć jest tokenem z już zainstalowanym niewyciągalnym kluczem i napisanym przez bank oprogramowaniem). Ja uważam, że bez specjalnego komplikowania procesu konieczność ufania bankowi można wyeliminować. Tak czy inaczej jednak trzeba jakoś cały ten proces zainicjować stawiając się w biurze banku z dowodem osobistym albo podpisując umowę z kurierem a to sprowadza się do tego, że ktoś to może zrobić w Twoim imieniu i cała Twoja absolutna pewność, matematyka itd. bierze w łeb i sprowadza się do poziomu bezpieczeństwa przy wysyłaniu zlecenia przelewu faxem. Poza tym nigdy nie twierdziłem, że tokeny są złe, bez sensu ani nic w tym stylu. Wręcz przeciwnie.

 pijackie mamrotanie a pisałeś to chyba jeszcze przed końcem meczu.

Nie pije w zasadzie żadnego alkocholu. Proponuje nie bawić się w domoroslego psychologa bo to nigdy nie działa.

Nie wiem co tam pijesz, może jakąś herbatkę ziołową, a jak pisałeś to na trzeźwo to tym gorzej dla Ciebie.

On 2016-03-25 00:01, Rafal Jankowski wrote:

Czy rozumiesz dlaczego nazywam managerów i dyrektorów bankow idiotami
zajętymi wertowaniem katalogow z jachtami?

Nie obrażaj ludzi którzy w miesiąc dymają więcej panienek i wpierdalają
więcej kawioru i szampana niż Ty zapewne przez całe zycie.

No i proszę. Nie przypusczalem że tak łatwo dasz się złapać. Twoje poglądy na to kogo trzeba szanować okazują się najzwyczajniej w świecie gówniane. Na szczęscie internet nie zapomina.

Problem polega na tym, że nie opisałeś szczegółowo całego procesu tylko
rzuciłeś kilka haseł z których trzeba się domyślać Twojego toku
rozumowania.

Jestesmy istotami rozumnymi. Zakładam (błednie zazwyczaj) że jesli podejmuje się dyskusji na jakimś poziomie to nie muszę w szczegółach tłumaczyć dlaczego szyfrowanie takie a takie działa tak i tak. Ale jak widac muszę bo trole czepiają się słówek przez co uzyskują w ich mniemaniu chwilową przewagę. Typowe korposzczurkowe zachowanie.

Na razie zrozumiałem z niego tylko tyle, że zakładasz
konieczność zaufania bankowi

Rzekłbym że to kluczowe, tak.

Ja uważam, że bez specjalnego komplikowania
procesu konieczność ufania bankowi można wyeliminować.

Nie da się. Oni mają twoje pienią^M^M^M wpisy w systemie informatycznym. Ufasz nawe sprzątaczce w banku. Może nieświadomie, ale ufasz. Zawsze pozostają skarpetki albo złoto w Amber Gold. A nie, czekaj ...

Tak czy inaczej
jednak trzeba jakoś cały ten proces zainicjować stawiając się w biurze
banku z dowodem osobistym albo podpisując umowę z kurierem a to
sprowadza się do tego, że ktoś to może zrobić w Twoim imieniu i cała
Twoja absolutna pewność, matematyka itd. bierze w łeb

Czyżbym zapomniał że w administracji publicznej pracują tacy sami idioci i do tej pory nie mamy dowodów z chipem? Problem debilomanagerów, debilodyrektorów i debilonaczelników jest dośc szeroki i obejmuje zarowno administrację jak i korporacje. Co zrobić, w końcu zabraknie łopat do kopania rowów jak by ich pozwalniać.

i sprowadza się do
poziomu bezpieczeństwa przy wysyłaniu zlecenia przelewu faxem.

No. Brawo, nareszcie.

Poza tym
nigdy nie twierdziłem, że tokeny są złe, bez sensu ani nic w tym stylu.
Wręcz przeciwnie.

Oczywiście że nie twierdziłeś. Od kilkunastu postów rozmawiam z ludzimi którym tokeny dają się zlamać kilkoma przylutoeanymi kabelkami a ludzie którzy wiedzą jak je zlamac najzwyczajniej masturbują się krzemem. Tak że faktycznie, nic nie twierdziłeś. Ot, przyjacielska rozmowa dwóch fachowców. Ba, nawet wręcz przeciwnie albo tak samo.

Nie wiem co tam pijesz, może jakąś herbatkę ziołową, a jak pisałeś to na
trzeźwo to tym gorzej dla Ciebie.

Ze mna nie może być już gorzej. Choć mam nadzieje ze weselej.

W dniu piątek, 25 marca 2016 19:19:56 UTC+1 użytkownik Sebastian Biały napisał:

Ze mna nie może być już gorzej. Choć mam nadzieje ze weselej.

Jak ta czytam Twoją radosną twórczość w której większość to obrażanie wszystkich naokoło to mam wrażenie że do jakiejś wymarzonej korporacji się nie dostałeś i teraz Swoje żale wylewasz na lewo i prawo.
Wyluzuj
A może to da się leczyć?

On 2016-03-25 20:10, Kris wrote:

W dniu piątek, 25 marca 2016 19:19:56 UTC+1 użytkownik Sebastian Biały napisał:

Ze mna nie może być już gorzej. Choć mam nadzieje ze weselej.

Jak ta czytam Twoją radosną twórczość w której większość to obrażanie
wszystkich naokoło

Możesz uzasadnić "wszystkich" oraz "większość" w kontekście obrażania? Bo widzisz, zaraz ktoś Cie złapie za slowo i okaże się że natępny flame gotowy i znowu bity zmarnowane.

to mam wrażenie że do jakiejś wymarzonej korporacji się nie dostałeś

Nastepny psychiatra. Next!

PS. Jak na razie nie usłyszałem ani jednego agumentu *technicznego* przeciwko stosowaniu autoryzacji elektronicznej.

Usłyszałem za to:
a) że bankowcy doskonale sie orientują w nowinkach technicznych (doskonale: przynajmniej na poziomie akademickim, technologia: fizyka, matematyka)
b) że chipy łamie się przylutowanymi drutami
c) że klucze lataja w te i wewte
d) że bardzo dobrze że okradli leminga
e) że bezrobotni są bezpieczni
f) że szacunek nalezy mieć do pijaczków z problemem seksualnym śmierdzących kawiorem
g) że smsy są zajebiste bo tak
h) że tokeny są niezajebiste bo tak
i) że technologia touch z Rubina jest aktualna
j) że trojany kerneluja kompile i podmieniają inkludy
k) że w ogóle wszystko jest spoko, tylko troche kasy ubywa

Wybacz. To jakaś porażka. Jestes pewny że to *JA* powinienem się leczyć? Możesz wskazać kogokolwiek kto ma *kontrargument* techniczny? Techniczny potwarzam. Jakikolwiek, że tak w desperacji zapytam.

On Fri, 25 Mar 2016, Sebastian Biały wrote:

PS. Jak na razie nie usłyszałem ani jednego agumentu *technicznego* przeciwko stosowaniu autoryzacji elektronicznej.

PS to Pre Scriptum?
Nie ważne, tak tylko czepiam się słówek :)

Wybacz. To jakaś porażka. Jestes pewny że to *JA* powinienem się leczyć?

Co od razu leczyć, może najpierw przebadać :)

Możesz wskazać kogokolwiek kto ma *kontrargument* techniczny? Techniczny potwarzam. Jakikolwiek, że tak w desperacji zapytam.

Czy dla Pana Technokraty (możesz sobie dopisać do długiej listy odznaczeń którymi Cię wyróżniłem) argumenty Massachusetts Institute of *Technology* są dość techniczne?

http://groups.csail.mit.edu/mac/classes/6.805/student-papers/fall97-papers/fillingham-sig.html

Jak choćby:

- A handwritten signature is biologically linked to a specific
   individual,[...]

- Handwritten signatures are under the direct control of the signer,
   whereas digital signatures must be applied by a computer commanded by
   the signer.

- Handwritten signatures can be witnessed, whereas digital signatures
   cannot be - though they can be notarized.

On 2016-03-25 21:22, Rafal Jankowski wrote:

PS. Jak na razie nie usłyszałem ani jednego agumentu *technicznego*
przeciwko stosowaniu autoryzacji elektronicznej.

PS to Pre Scriptum?
Nie ważne, tak tylko czepiam się słówek :)

Nie. PS dotyczy tych kilkunastu linijak niżej.

Możesz wskazać kogokolwiek kto ma *kontrargument* techniczny?
Techniczny potwarzam. Jakikolwiek, że tak w desperacji zapytam.

Czy dla Pana Technokraty

No i jak widzisz, usilnie starasz sie moralizować i trzymać profesjonalizm a tu okazuje się że garnitur przecieka.

odznaczeń którymi Cię wyróżniłem) argumenty Massachusetts Institute of
*Technology* są dość techniczne?
http://groups.csail.mit.edu/mac/classes/6.805/student-papers/fall97-papers/fillingham-sig.html

Zonk: 1997. To chyba jeszcze przed Jezusem. No no. Ale wiesz co? Ten koleś jednak na koniec napisał:

[...] and over time, handwritten signatures gradually increased in the frequency and scope of their usage. It is likely to be much the same with digital signatures, which are the latest authentication tool in the continuing advancement of communications technology.[...]

Latest ... ta ...

Przyznaje Ci racje, w 1997 roku faktycznie podpisy były dość dobre bo nie bylo telefonów, gniazdek USB i kart chipowych, przynajmniej nie w takiej ilości.

Czy ja dobrze zauważyłem że to konferencja dla studentów na temat Etyki i Prawa? Ani słowa o oddziaływaniach słabych w kryształach domieszkowanego krzemu w kontekście budowy zabezpieczen ukladow scalonych? Może to i lepiej ze te głupie tępaki od fizyki się tam nie dostały.

Jak choćby:
- A handwritten signature is biologically linked to a specific
   individual,[...]

Misiu złoty... A kto je sprawdza? Kasjer-grafolog wspomagany AI w postaci dofinansowanych okularów? To nie jest argument *techniczny* który powoduje że chipy są gorsze niż ręczne podpisy. Przedstaw argument który powoduje że podpis ręczny posiada wyższy poziom bezpieczeństwa niż chip, działa przez internet bez możliwości przechwycenia, jest trywialny w pewnym sprawdzeniu przez inną jednostkę biologiczną, a najlepiej sztuczną. Wiesz dlaczego? Bo cały ten p... wątek jest o kradzieży przez internet.

- Handwritten signatures can be witnessed, whereas digital signatures
   cannot be - though they can be notarized.

Bzdura. Świadek może kłamać z wysokim prawdopodobienstwem. Matematyka nie - też z wysokim prawdopodobieństwem.

On Fri, 25 Mar 2016, Sebastian Biały wrote:

Czy ja dobrze zauważyłem że to konferencja dla studentów na temat Etyki i Prawa? Ani słowa o oddziaływaniach słabych w kryształach domieszkowanego krzemu w kontekście budowy zabezpieczen ukladow scalonych? Może to i lepiej ze te głupie tępaki od fizyki się tam nie dostały.

A na jaką konferencję spodziewałbyś się tego typu materiałów? Z algebry? Chciałeś jakikolwiek techniczny argument na korzyść podpisu ręcznego to dostałeś ich nawet kilka. Zresztą skomentowałeś te które były dla Ciebie wygodne a ten który był mniej wygodny pominąłeś i wszystkie te których nie zacytowałem też pominąłeś. Zresztą to nieważne, nie oczekiwałem że będziesz wszystkie komentować, ale miałem nadzieję, że w swoim zaślepieniu dostrzeżesz ich sens. Odnoszę wrażenie że Ty masz wrażenie, że wszyscy tu są orędownikami dawnej PO czy współczesnego PISu i nie wyobrażają sobie życia bez weryfikacji podpisu na świstku przez urzędnika w okularach (niechby nawet google glass). Pozwól, że powołam się na stanowisko rzecznika tej grupy (jakby komuś taki wybór nie pasował, to zawsze może spadać na drzewo) i parę rzeczy Ci wyjaśnię:

Tak, tokeny/elektroniczne dowody osobiste są dobre i potrzebne

Nie zmienia to jednak faktu, że podpis tradycyjny ma niezaprzeczalne zalety (tzn. takie którym chyba nikt oprócz Ciebie nie przeczy), które od 1997 roku się nie zdewaluowały, a chyba jedyna rzecz która się od tamtego czasu *drastycznie* zmieniła to pewnie bezpieczeństwo klucza prywatnego w chipach, chociaż to zdecydowanie nie moja działka. Coś przeoczyłem?

Tutaj pozwolę sobie na mały wtręt jak to na drzwiach pewnej państwowej instytucji widziałem kartkę żeby nie szarpać klamką dopóki nie usłyszy się dźwięku otwieranego zamka od domofonu bo psuje się mechanizm tego zamka. Pomijając już fakt dziadostwa tego systemu na tej karteczce był podpis z pieczątką dyrektora placówki, bo jeszcze ktoś by sobie mógł pomyśleć że bez podpisu i pieczątki to może być scam, więc może lepiej na wszelki wypadek prewencyjnie szarpnąć klamką.

Problem którego Ty wydajesz się nie dostrzegać (chociaż pewnie dostrzegasz, ale operujesz argumentami jakbyś nie dostrzegał) to otoczenie prawne w jakim się znajdujemy i to, że jeśli w grę nie wchodzi morderstwo albo wyłudzenie na milionową skalę to policja/sądy/prokuratura nie zadają sobie zbytniego trudu weryfikowania podpisu i z automatu przyjmują dowolny bazgroł na kartce za pełnoprawny podpis. Co w przypadku podpisu elektronicznego będzie utrudnione, ale to nie oznacza że eliminuje on wszystkie zalety podpisu tradycyjnego bez wprowadzania wad.

On Sat, 26 Mar 2016, Rafal Jankowski wrote:

Co w przypadku podpisu elektronicznego będzie utrudnione, ale to nie oznacza że eliminuje on wszystkie zalety podpisu tradycyjnego bez wprowadzania wad.

To zdanie jest oczywiście bez sensu miało być:

Co w przypadku podpisu elektronicznego będzie utrudnione, ale to nie oznacza że eliminuje on wszystkie wady podpisu tradycyjnego bez wprowadzania nowych wad.

On 2016-03-26 02:34, Rafal Jankowski wrote:

Czy ja dobrze zauważyłem że to konferencja dla studentów na temat
Etyki i Prawa? Ani słowa o oddziaływaniach słabych w kryształach
domieszkowanego krzemu w kontekście budowy zabezpieczen ukladow
scalonych? Może to i lepiej ze te głupie tępaki od fizyki się tam nie
dostały.

A na jaką konferencję spodziewałbyś się tego typu materiałów? Z algebry?

Nie. Widzisz, ten dokument to typowy tumanistyczny wpierd. Wydaje nam się że cos tam bo mocno wierzymy w cośtam, a tu macie kilka bezuzytecznych punktów i konferencja zaliczona. od razu powiem że bylem na niezliczonej ilości konferencji naukowych - technicznych. Ten materiał został by odrzucony z adnotacja WTF? Bo to nie sa argumenty *TECHNICZNE*.

Chciałeś jakikolwiek techniczny argument na korzyść podpisu ręcznego to
dostałeś ich nawet kilka.

*ANI* jednego technicznego ktory pozwala twierdzić że jest to lepsze w sensie ogólnym. Za to pelno tumanistycznych.

Zresztą skomentowałeś te które były dla Ciebie
wygodne a ten który był mniej wygodny pominąłeś i wszystkie te których
nie zacytowałem też pominąłeś.

Bo to tumanistyczne bzdury nie na temat z przed 20 lat.

Zresztą to nieważne, nie oczekiwałem że
będziesz wszystkie komentować, ale miałem nadzieję, że w swoim
zaślepieniu dostrzeżesz ich sens.

Zaślepieniu :D Dawaj dalej !

Odnoszę wrażenie że Ty masz wrażenie,
że wszyscy tu są orędownikami dawnej PO czy współczesnego PISu i nie
wyobrażają sobie życia bez weryfikacji podpisu

Zakładasz że przeciętny inzynier ma choć sladowe poważanie do polityki i tych tepych debili którzy tam brylują? Skąd Ci u diabła nagle przeskoczyło coś w glowie na politykę?

Tak, tokeny/elektroniczne dowody osobiste są dobre i potrzebne
Nie zmienia to jednak faktu, że podpis tradycyjny ma niezaprzeczalne
zalety (tzn. takie którym chyba nikt oprócz Ciebie nie przeczy), które
od 1997 roku się nie zdewaluowały

Gówno prawda. OD 1997 była niezliczona ilość przekrętow na podpis. Tak, one wszystkie są do kilku tysiaków. Czyli nie ma o co walczyć z punktu widzenia banku, to nawet nie jest jedna rata na jacht. A że jest ich pewno kolo miliona? A kto się przejmuje, implementujmy cutting edge of PHP security.

, a chyba jedyna rzecz która się od

tamtego czasu *drastycznie* zmieniła to pewnie bezpieczeństwo klucza
prywatnego w chipach, chociaż to zdecydowanie nie moja działka. Coś
przeoczyłem?

Tak. Przeoczyleś że klucze elektroniczne sa obecnie nieporownywalnie lepsze od kasjerow-grafologów. Publikacjami z 1997 można palić w piecu. Z powodu że stare i z powodu że tumanistyczne.

Problem którego Ty wydajesz się nie dostrzegać (chociaż pewnie
dostrzegasz, ale operujesz argumentami jakbyś nie dostrzegał) to
otoczenie prawne w jakim się znajdujemy i to, że jeśli w grę nie wchodzi
morderstwo albo wyłudzenie na milionową skalę to
policja/sądy/prokuratura nie zadają sobie zbytniego trudu weryfikowania
podpisu i z automatu przyjmują dowolny bazgroł na kartce za pełnoprawny
podpis.

Tak. Wiec zmieńmy to prawo. Jak powiedziałem całkiem go zmienić się nie da bo łopat dla prawników zabraknie, ale choć troszeczkę?

Co w przypadku podpisu elektronicznego będzie utrudnione, ale to
nie oznacza że eliminuje on wszystkie zalety podpisu tradycyjnego bez
wprowadzania wad.

Fajnie. Ciekawe dlaczego od jakiegoś czasu państwo PL promuje podpisy elektroniczne które mozna sobie uzyskać z urzedu.

On Sat, 26 Mar 2016 14:20:22 +0100, Sebastian Biały<heby@poczta.onet.pl> wrote:

Fajnie. Ciekawe dlaczego od jakiegoś czasu państwo PL promuje

podpisy

elektroniczne które mozna sobie uzyskać z urzedu.

Zapomniałeš dopisać "... i nie mają u nas powszechnego  a i więc praktycznego zastosowania".

Wielokrotnie pogoniłem już paru cwaniaczków, co dokumenty chcieli przysyłać z "cyfrowym podpisem". Na drzewo.

--
Marek

On 2016-03-26 14:39, Marek wrote:

Fajnie. Ciekawe dlaczego od jakiegoś czasu państwo PL promuje

podpisy

elektroniczne które mozna sobie uzyskać z urzedu.

Zapomniałeš dopisać "... i nie mają u nas powszechnego  a i więc
praktycznego zastosowania".

Jakieś tam mają. Problem w tym że ja go nie wnioskowałem bo nie mam śladowego zaufania do procesu jego pozyskiwania z urzędu ("pan se przyniesie pena to sie skopiuje").

On Fri, 25 Mar 2016, Sebastian Biały wrote:

On 2016-03-25 00:01, Rafal Jankowski wrote:

>  Czy rozumiesz dlaczego nazywam managerów i dyrektorów bankow idiotami
>  zajętymi wertowaniem katalogow z jachtami?
 Nie obrażaj ludzi którzy w miesiąc dymają więcej panienek i wpierdalają
 więcej kawioru i szampana niż Ty zapewne przez całe zycie.

No i proszę. Nie przypusczalem że tak łatwo dasz się złapać. Twoje poglądy na to kogo trzeba szanować okazują się najzwyczajniej w świecie gówniane. Na szczęscie internet nie zapomina.

I bardzo dobrze, niech pamięta. W razie jak nasz bank będzie wysyłać kluczowym klientom zaproszenia na biznesowy bankiecik to Pan dyrektor będzie miał na uwadze, kto go wyzywał od debili.

A od moich norm moralnych się czep. Są wyrafinowane, ale rozumiem, że pospólstwo może mieć problem z ich ogarnięciem.

 Problem polega na tym, że nie opisałeś szczegółowo całego procesu tylko
 rzuciłeś kilka haseł z których trzeba się domyślać Twojego toku
 rozumowania.

Jestesmy istotami rozumnymi. Zakładam (błednie zazwyczaj) że jesli podejmuje się dyskusji na jakimś poziomie to nie muszę w szczegółach tłumaczyć dlaczego szyfrowanie takie a takie działa tak i tak.

Słuchaj no ziomuś, tak się jakoś składa, że sedno sprawy tkwi nierzadko w
szczegółach, których Ty podawania unikasz.

 Ale jak widac muszę bo trole czepiają się słówek przez co uzyskują w ich mniemaniu chwilową przewagę. Typowe korposzczurkowe zachowanie.

Nie ma to jak przywalić głupotę, albo niedopowiedzenie a potem zarzucać innym łapanie za słówka. Idź poskarżyć się Pani.

 Na razie zrozumiałem z niego tylko tyle, że zakładasz
 konieczność zaufania bankowi

Rzekłbym że to kluczowe, tak.

Cieszę, się że coś udało nam się ustalić, teraz przynajmniej mogę otwarcie storpedować głupotę tej teorii, a nie zakładać że to właśnie chciałeś powiedzieć, ale nie powiedziałęś.

 Ja uważam, że bez specjalnego komplikowania
 procesu konieczność ufania bankowi można wyeliminować.

Nie da się. Oni mają twoje pienią^M^M^M wpisy w systemie informatycznym. Ufasz nawe sprzątaczce w banku. Może nieświadomie, ale ufasz. Zawsze pozostają skarpetki albo złoto w Amber Gold. A nie, czekaj ...

Jak podpiszesz kluczem prywatnym transakcję to ni huhu nie powiedzą, że tak pokazuje nasz system informatyczny, więc tak musi być. Transakcje muszą być podpisane przez zleceniodawcę i on ma podpis banku o ich odebraniu. Dzięki mnie od tej chwili możesz nazywać dyrektora banku debilem i nie martwić się, że zaksięguje na Twoim koncie 100kPLN wydatków na viagrę. Nie musisz dziękować

 Tak czy inaczej
 jednak trzeba jakoś cały ten proces zainicjować stawiając się w biurze
 banku z dowodem osobistym albo podpisując umowę z kurierem a to
 sprowadza się do tego, że ktoś to może zrobić w Twoim imieniu i cała
 Twoja absolutna pewność, matematyka itd. bierze w łeb

Czyżbym zapomniał że w administracji publicznej pracują tacy sami idioci i do tej pory nie mamy dowodów z chipem? Problem debilomanagerów, debilodyrektorów i debilonaczelników jest dośc szeroki i obejmuje zarowno administrację jak i korporacje. Co zrobić, w końcu zabraknie łopat do kopania rowów jak by ich pozwalniać.

Co do idiotów w administracji to w zasadzie zgoda. Ale obstawiam (choć więcej jak flaszki dobrej siwuchy jednak bym nie postawił), że testamentu podpisanego elektronicznie to żaden z nas nie dożyje.

 i sprowadza się do
 poziomu bezpieczeństwa przy wysyłaniu zlecenia przelewu faxem.

No. Brawo, nareszcie.

Naprawdę w jakimś punkcie się ze mną zgadzasz? Jeszcze możesz to odwołać (żeby potem nie było, że czepiam się słówek).

 Poza tym
 nigdy nie twierdziłem, że tokeny są złe, bez sensu ani nic w tym stylu.
 Wręcz przeciwnie.

Oczywiście że nie twierdziłeś. Od kilkunastu postów rozmawiam z ludzimi którym tokeny dają się zlamać kilkoma przylutoeanymi kabelkami a ludzie którzy wiedzą jak je zlamac najzwyczajniej masturbują się krzemem. Tak że faktycznie, nic nie twierdziłeś. Ot, przyjacielska rozmowa dwóch fachowców. Ba, nawet wręcz przeciwnie albo tak samo.

Wybacz, wiedzę na temat TPMów czerpałem z filmiku jaki mi podesłałeś :)

 Nie wiem co tam pijesz, może jakąś herbatkę ziołową, a jak pisałeś to na
 trzeźwo to tym gorzej dla Ciebie.

Ze mna nie może być już gorzej. Choć mam nadzieje ze weselej.

Nie bądź takim pesymistą. Zawsze może być gorzej!

On 2016-03-25 21:42, Rafal Jankowski wrote:

No i proszę. Nie przypusczalem że tak łatwo dasz się złapać. Twoje
poglądy na to kogo trzeba szanować okazują się najzwyczajniej w
świecie gówniane. Na szczęscie internet nie zapomina.

I bardzo dobrze, niech pamięta. W razie jak nasz bank będzie wysyłać
kluczowym klientom zaproszenia na biznesowy bankiecik to Pan dyrektor
będzie miał na uwadze, kto go wyzywał od debili.

Uuu zmartwie cie, do czytania newsów wymagana jest doskonala orientacja w starynkach technicznych. Bankowcy się nie łapią.

A od moich norm moralnych się czep. Są wyrafinowane, ale rozumiem, że
pospólstwo może mieć problem z ich ogarnięciem.

:D Piękne. Dawaj jeszcze.

Słuchaj no ziomuś

Łomatko, dawaj jeszcze!

, tak się jakoś składa, że sedno sprawy tkwi nierzadko w
szczegółach, których Ty podawania unikasz.

E tam, nie przypominam sobie żebym w tej dyskusji czegos unikał jakoś specjalnie. Możesz wskazać palcem czego *unikam*?

Rzekłbym że to kluczowe, tak.

Cieszę, się że coś udało nam się ustalić, teraz przynajmniej mogę
otwarcie storpedować głupotę tej teorii, a nie zakładać że to właśnie
chciałeś powiedzieć, ale nie powiedziałęś.

Torpeduj. Potem możesz przeprowadzić się do jaskini. We Francyji to nawet jest oznaką hipsterstwa dostępna dla bogatszych (sprawdzić czy jedzą kawior).

Jak podpiszesz kluczem prywatnym transakcję to ni huhu nie powiedzą, że
tak pokazuje nasz system informatyczny, więc tak musi być. Transakcje
muszą być podpisane przez zleceniodawcę i on ma podpis banku o ich
odebraniu. Dzięki mnie od tej chwili możesz nazywać dyrektora banku
debilem i nie martwić się, że zaksięguje na Twoim koncie 100kPLN
wydatków na viagrę. Nie musisz dziękować

To samo mogą powiedzieś teraz. Czyli jakiś misio może sfałszować Twój podpis pod dokumentem. Jeśli wydaje Ci się to trudne do ogarnięcia to zwracam uwagę że całkiem sporo kasjerów na przestrzeni kilkunastu lat to zrobiło. Koledze dostało się po łbie kilkanascie tysięcy rachunków za kilka telefonów, że tak przytocze realny przykład z okolicy choć może nie z bankowości.

Tak, banki zdecydowanie bedą robiły wszystko żeby podrobić niepodrabialny (w praktyce wystarczająco) podpis hardwareowy. Może nawet jakiś kasjer wstawi kilka przypadkowych liczb żeby wyglądało że podpisany! Złe, niedobre banki, nie cofna sie nawet przed złamaniem krzywych eliptycznych z chęci zysku :(

 i sprowadza się do
 poziomu bezpieczeństwa przy wysyłaniu zlecenia przelewu faxem.

No. Brawo, nareszcie.

Naprawdę w jakimś punkcie się ze mną zgadzasz? Jeszcze możesz to odwołać
(żeby potem nie było, że czepiam się słówek).

Narzeksz na poziom bezpieczeństwa przelewów wysłanych faksem? Ja też. Jak widzisz zgoda buduje. Ale poza stwierdzeniem że jest źle trzeba czasem dostrzec alternatywę.

Wybacz, wiedzę na temat TPMów czerpałem z filmiku jaki mi podesłałeś :)

Którego? Tego w którym ktoś lutował do kabelki do scalaka i wymieniał klucze w te i wewte?

Ze mna nie może być już gorzej. Choć mam nadzieje ze weselej.

Nie bądź takim pesymistą. Zawsze może być gorzej!

Nie, moja salowa mówi że nie. I Pan doktór też. A tabletki biorę.

On Fri, 25 Mar 2016, Sebastian Biały wrote:

On 2016-03-25 21:42, Rafal Jankowski wrote:
E tam, nie przypominam sobie żebym w tej dyskusji czegos unikał jakoś specjalnie. Możesz wskazać palcem czego *unikam*?

Prosiłem żebyś opisał pełny model wdrożenia takiego oraz użycia tokena przez bank (co kto komu wysyła, co i w jaki sposób podpisuje itd.). Nie zrobiłeś tego.

 Jak podpiszesz kluczem prywatnym transakcję to ni huhu nie powiedzą, że
 tak pokazuje nasz system informatyczny, więc tak musi być. Transakcje
 muszą być podpisane przez zleceniodawcę i on ma podpis banku o ich
 odebraniu. Dzięki mnie od tej chwili możesz nazywać dyrektora banku
 debilem i nie martwić się, że zaksięguje na Twoim koncie 100kPLN
 wydatków na viagrę. Nie musisz dziękować

To samo mogą powiedzieś teraz. Czyli jakiś misio może sfałszować Twój podpis pod dokumentem. Jeśli wydaje Ci się to trudne do ogarnięcia to zwracam uwagę że całkiem sporo kasjerów na przestrzeni kilkunastu lat to zrobiło. Koledze dostało się po łbie kilkanascie tysięcy rachunków za kilka telefonów, że tak przytocze realny przykład z okolicy choć może nie z bankowości.

No ale nie chodzi o to co mogą teraz tylko co będą mogły jak się wprowadzi sensowne rozwiązanie. Nie wiem po co wymyśliłeś sobie, że klient musi ufać bankowi bo ta kwestia była w tym wątku podnoszona już wcześniej. Możemy po prostu podsumować, że skoro bank nie musi znać klucza klienta to ja miałem rację, a Ty byłeś w błędzie, czy chcesz masz jakąś nową teorię?

On 2016-03-26 02:46, Rafal Jankowski wrote:

Prosiłem żebyś opisał pełny model wdrożenia takiego oraz użycia tokena
przez bank (co kto komu wysyła, co i w jaki sposób podpisuje itd.). Nie
zrobiłeś tego.

Ale nie przedstawiłeś oferty finansowej dla *PEŁNEGO* modelu.

No ale nie chodzi o to co mogą teraz tylko co będą mogły jak się
wprowadzi sensowne rozwiązanie.

Mniej będą mogły.

Nie wiem po co wymyśliłeś sobie, że
klient musi ufać bankowi bo ta kwestia była w tym wątku podnoszona już
wcześniej.

Bo ufa. To czy idiotom mozna ufac to inne kwestia. Czasem nie masz wyjścia.

Możemy po prostu podsumować, że skoro bank nie musi znać
klucza klienta to ja miałem rację, a Ty byłeś w błędzie, czy chcesz masz
jakąś nową teorię?

Podpisywanie dokumentów może odbywać sie na tak wiele sposobów w których bank *NIE* moze sfałszować podpisu że aż nie wiadomo jak zacząć.

W dniu 2016-03-25 o 22:16, Sebastian Biały pisze:

Koledze dostało się po łbie kilkanascie tysięcy rachunków za kilka telefonów

Ściemniasz, to niemożliwe.

--
Liwiusz

Dnia Sat, 26 Mar 2016 07:08:43 +0100, Liwiusz napisał(a):

W dniu 2016-03-25 o 22:16, Sebastian Biały pisze:

Koledze dostało się po łbie kilkanascie tysięcy rachunków za kilka telefonów

Ściemniasz, to niemożliwe.

Obstawiam pośpiech piszącego, kilkanascie tysięcy *złotych z* rachunków
za kilka telefonów.

Co uważam za jak najbardziej możliwe ;/
--
Imka

On 2016-03-26 07:08, Liwiusz wrote:

W dniu 2016-03-25 o 22:16, Sebastian Biały pisze:

Koledze dostało się po łbie kilkanascie tysięcy rachunków za kilka
telefonów

Ściemniasz, to niemożliwe.

Zgubiłem "tysięcy z rachunków". Zastanawiające jest jednak dlaczego tak wielu ludzi tutaj nie jest w stanie się domyslić tego typu błedow. Hmmm....

On Fri, 25 Mar 2016 22:16:29 +0100, Sebastian Biały<heby@poczta.onet.pl> wrote:

Tak, banki zdecydowanie bedą robiły wszystko żeby podrobić niepodrabialny (w praktyce wystarczająco) podpis hardwareowy. Może

nawet

jakiś kasjer wstawi kilka przypadkowych liczb żeby wyglądało że podpisany!

Jestem w stanie sobie wyobrazić u nas sytuację, w której (paradoksalnie) użycie prawidłowego lub nieprawidłowego podpisu el. nie spowoduje odpowiednio oczekiwanych rezultatów. I bank/urząd wtedy odpowie w stylu "bo podpis był nieprawidłowy/prawidłowy i co pan mam zrobisz". Wiara, że działania hardwaru/elektroniki/softu będą miały ostateczny i niepodważalny charakter w sytuacjach spornych jest dość naiwna.

--
Marek

Sebastian Biały <heby@poczta.onet.pl> writes:

Świetnie, czym więc windows zasłużył na wyróżnienie w tym zestawie?

Popularnością malware z powodu popularności OSa. Jest zdecydownie
popularnieszy niż cała reszta w kupie.

Bez znaczenia, ważna jest możliwość uruchamiania softu przez usera, oraz
stopień komplikacji systemu.

A po ch... Zasadą działania TPM jest to że może pracować w kompie z
milionem wirusĂłw, trojanĂłw, malware. I nic. Dalej jest trusted i
pozwala na bezpieczne przeprowadzanie operacji.

Sam TPM jest wtedy moĹźe "trusted" :-), ale to zbyt wiele nie daje.

TPM może jest fajny w warunkach firmowych, gdy chcesz uniemożliwić pani
Kasi grzebanie w Windows.
--
Krzysztof Hałasa

On 2016-03-22 00:10, Krzysztof Halasa wrote:

Świetnie, czym więc windows zasłużył na wyróżnienie w tym zestawie?

Popularnością malware z powodu popularności OSa. Jest zdecydownie
popularnieszy niż cała reszta w kupie.

Bez znaczenia, ważna jest możliwość uruchamiania softu przez usera, oraz
stopień komplikacji systemu.

Ma znaczenie. Pojawienie się jednego malware na Linuxa to sensacja na skale madialna. W miedzyczasie powstaje setka malware dla windowsa w kilkuset tysiącach mutacji. Skala ma znaczenie. Miedzy innymi obecnie bezpieczniej jest wykonywać transakcje na Lin/OS X nie z powodu że są bezpieczne, tylko z powodu że większe powodzenie przestępcy mają na win i nie bedą zajmowali się hakowaniem tych kilku nerdów uwalonych pizzą bo tam nie ma kasy a przede wszystkim jest mało idiotów.

A po ch... Zasadą działania TPM jest to że może pracować w kompie z
milionem wirusów, trojanów, malware. I nic. Dalej jest trusted i
pozwala na bezpieczne przeprowadzanie operacji.

Sam TPM jest wtedy może "trusted" :-), ale to zbyt wiele nie daje.

To daje *wszystko* co potrzebujesz aby zaimplementować bezpieczną bankowość.

TPM może jest fajny w warunkach firmowych, gdy chcesz uniemożliwić pani
Kasi grzebanie w Windows.

Może jednak coś przeoczyłem w dyskusji, więc wyostrzę: rozmawiamy o donglu dostarczanym przez bank, wpinanym w USB/Whatever. Dongle zawiera scalak niekoniecznie TPM, ale o poziomie funkcjonalnym i zabezpieczeniami fizycznymi jak TPM. Ma on dodatkowo klawiaturę i wyswietlacz co pozwala na pozbycie się problemów z malware podmieniającymi widok.

W dniu 2016-03-23 o 18:37, Sebastian Biały pisze:

Może jednak coś przeoczyłem w dyskusji, więc wyostrzę: rozmawiamy o
donglu dostarczanym przez bank, wpinanym w USB/Whatever. Dongle zawiera
scalak niekoniecznie TPM, ale o poziomie funkcjonalnym i
zabezpieczeniami fizycznymi jak TPM. Ma on dodatkowo klawiaturę i
wyswietlacz co pozwala na pozbycie się problemów z malware
podmieniającymi widok.

W przyszłości, a nawet już obecnie to nie ma racji bytu,
użytkownicy przesiadają się na urządzenia przenośne,
a nawet w profesjonalnych zastosowaniach używa się prywatnych
urządzeń.

On 2016-03-26 16:41, MarcinF wrote:

Może jednak coś przeoczyłem w dyskusji, więc wyostrzę: rozmawiamy o
donglu dostarczanym przez bank, wpinanym w USB/Whatever. Dongle zawiera
scalak niekoniecznie TPM, ale o poziomie funkcjonalnym i
zabezpieczeniami fizycznymi jak TPM. Ma on dodatkowo klawiaturę i
wyswietlacz co pozwala na pozbycie się problemów z malware
podmieniającymi widok.

W przyszłości, a nawet już obecnie to nie ma racji bytu,
użytkownicy przesiadają się na urządzenia przenośne,
a nawet w profesjonalnych zastosowaniach używa się prywatnych
urządzeń.

Przeciez przymusu nie ma. Jesli ktoś na dziurawym androidzie chce mieć "bezpieczne" szyfrowanie, to proszę.

No chyba że ... producenci hardware do telefonów stworzą technikę pozwalającą na pewny i bezpiecznyc podpis. Na przykład poprzez zupełnie osobny tryb pracy cpu który potrafi na wyświetlaczu pokazać przelew w sposob pewny i niemozliwy do przerobienia przez malware. Obecnie nie słyszę o takich planach. Wszystkim opłaca się klepać dziadostwo.

Dnia Sat, 26 Mar 2016 19:08:56 +0100, Sebastian Biały napisał(a):

On 2016-03-26 16:41, MarcinF wrote:

Może jednak coś przeoczyłem w dyskusji, więc wyostrzę: rozmawiamy o
donglu dostarczanym przez bank, wpinanym w USB/Whatever. Dongle zawiera
scalak niekoniecznie TPM, ale o poziomie funkcjonalnym i
zabezpieczeniami fizycznymi jak TPM. Ma on dodatkowo klawiaturę i
wyswietlacz co pozwala na pozbycie się problemów z malware
podmieniającymi widok.

W przyszłości, a nawet już obecnie to nie ma racji bytu,
użytkownicy przesiadają się na urządzenia przenośne,
a nawet w profesjonalnych zastosowaniach używa się prywatnych
urządzeń.

Przeciez przymusu nie ma. Jesli ktoś na dziurawym androidzie chce mieć "bezpieczne" szyfrowanie, to proszę.

No chyba że ... producenci hardware do telefonów stworzą technikę pozwalającą na pewny i bezpiecznyc podpis. Na przykład poprzez zupełnie osobny tryb pracy cpu który potrafi na wyświetlaczu pokazać przelew w sposob pewny i niemozliwy do przerobienia przez malware. Obecnie nie słyszę o takich planach. Wszystkim opłaca się klepać dziadostwo.

Producentom telefonu niekoniecznie zalezy.
Ale to w sumie bankom powinno zalezec na bezpieczenstwie.
Szczegolnie, jak sady zaczna uwazac, ze transakcje autoryzowane przez
wirusa haslem sms to z winy banku.

Ale banki cwane - policza straty, ubezpiecza, i przerzuca skladke na
klienta :-)

J.

Sebastian Biały <heby@poczta.onet.pl> writes:

Ma znaczenie. Pojawienie się jednego malware na Linuxa to sensacja na
skale madialna. W miedzyczasie powstaje setka malware dla windowsa w
kilkuset tysiącach mutacji. Skala ma znaczenie. Miedzy innymi obecnie
bezpieczniej jest wykonywać transakcje na Lin/OS X nie z powodu że są
bezpieczne, tylko z powodu że większe powodzenie przestępcy mają na
win i nie bedą zajmowali się hakowaniem tych kilku nerdów uwalonych
pizzą bo tam nie ma kasy a przede wszystkim jest mało idiotów.

Mogę zgodzić się tylko z tym, że Linux jest bezpieczniejszy. Ale tu nie
chodzi o to, by się pastwić nad Windows (które BTW podobno też jest
coraz bezpieczniejsze), tylko o rozwiązanie _bezpieczne_. Nie tylko nie
aż tak bardzo niebezpieczne.

Rozmaitego "softu" na Linuksa jest bardzo dużo. Myślisz że botnety to
tylko na Windows działają?

Weź też takiego Androida.

Jeszcze raz, normalny system ogólnego przeznaczenia nie jest
"wystarczająco bezpieczny" (ani "bezpieczny"). Tzn. poszczególne
egzemplarze mogą być, ale nie można stwierdzić, że wszystkie (lub
znaczna większość) są.

Sam TPM jest wtedy może "trusted" :-), ale to zbyt wiele nie daje.

To daje *wszystko* co potrzebujesz aby zaimplementować bezpieczną
bankowość.

Nic z tego:

TPM może jest fajny w warunkach firmowych, gdy chcesz uniemożliwić pani
Kasi grzebanie w Windows.

Może jednak coś przeoczyłem w dyskusji, więc wyostrzę: rozmawiamy o
donglu dostarczanym przez bank, wpinanym w USB/Whatever.

To może zainteresuj się tym, czym jest TPM ("Trusted Platform Module").
To nie jest dowolne urządzenie kryptograficzne, TPM to jest
ustandaryzowana konkretna implementacja, w szczególności pozbawiona
interfejsu użytkownika. W praktyce główne zastosowanie TPM to jest
zapewnienie (względnie) "bezpiecznego" (podpisanego) startu systemu.
Niektórzy trzymają tam klucze do szyfrowania dysków, ale nie jest to
bezpieczne (klucze służące do szyfrowania blokowego wychodzą z TPMa, bo
ten nie ma wystarczającej wydajności).

Dongle
zawiera scalak niekoniecznie TPM, ale o poziomie funkcjonalnym i
zabezpieczeniami fizycznymi jak TPM. Ma on dodatkowo klawiaturę i
wyswietlacz co pozwala na pozbycie się problemów z malware
podmieniającymi widok.

W tak zmienionych warunkach rzeczywiście można to zrobić bezpiecznie,
co zresztą od początku pisałem. Z tym że proponuję skasować USB
i zastosować małą kamerę - jest to bardzo dobre rozwiązanie, sprawdzone
w praktyce. Oprócz poprawy bezpieczeństwa mamy wtedy dużo większą
funkcjonalność, właściwie nawet korzystanie z icafe byłoby wtedy
względnie bezpieczne (z ryzykiem "tylko" ujawnienia informacji).

No i nie łącz tego z TPM.
--
Krzysztof Hałasa

On 2016-03-29 00:06, Krzysztof Halasa wrote:

Ma znaczenie. Pojawienie się jednego malware na Linuxa to sensacja na
skale madialna. W miedzyczasie powstaje setka malware dla windowsa w
kilkuset tysiącach mutacji. Skala ma znaczenie. Miedzy innymi obecnie
bezpieczniej jest wykonywać transakcje na Lin/OS X nie z powodu że są
bezpieczne, tylko z powodu że większe powodzenie przestępcy mają na
win i nie bedą zajmowali się hakowaniem tych kilku nerdów uwalonych
pizzą bo tam nie ma kasy a przede wszystkim jest mało idiotów.

Mogę zgodzić się tylko z tym, że Linux jest bezpieczniejszy.

Ale ja tego nie powiedziałem, wręcz przeciwnie!

Ale tu nie
chodzi o to, by się pastwić nad Windows (które BTW podobno też jest
coraz bezpieczniejsze), tylko o rozwiązanie _bezpieczne_. Nie tylko nie
aż tak bardzo niebezpieczne.

Nie ma bezpiecznego rozwiązania. Jedynym jakie znam to odpalanie za każdym razem systemu z LiveCD. Przy czym przy odpowiedniej dozie paranoi można wtedy wlaśnie zapytać co z malware w UEFI, myszce i podkładce.

Rozmaitego "softu" na Linuksa jest bardzo dużo. Myślisz że botnety to
tylko na Windows działają?

Tam działają skutecznie. Na linuxa z powodu:
a) kłopotów z ABI
b) kłopotow z architekturami cpu
c) zainteresowaniem znikomym

.... bedzie cięzko dostarczyć malware w wersji binarnej. Za dużo roboty. Mozna natomiast albański malware "skompiluj mnie, ustaw roota i odpal".

Tak, wiem że może się skompilować sam, ale nie kązda distro ma kompilator. Można tez napisać bootnet w bashu zapewne. Mozna. Tylko po ch...

Może jednak coś przeoczyłem w dyskusji, więc wyostrzę: rozmawiamy o
donglu dostarczanym przez bank, wpinanym w USB/Whatever.

To może zainteresuj się tym, czym jest TPM ("Trusted Platform Module").
To nie jest dowolne urządzenie kryptograficzne, TPM to jest
ustandaryzowana konkretna implementacja, w szczególności pozbawiona
interfejsu użytkownika.

TPM jest w tej dyskucji tylko *przykładem* zabezpieczeń w krzemie. Bodaj nalepiej opisanym pod kątem reverse engeneering obok kart sim. Wlasciwe scalaki uzywane w tym urzadzeniu bedą tak zabezpieczone, ale działać beda w sposób ograniczony (nie jest potrzebna wydajnośc obliczeniowa).

W tak zmienionych warunkach rzeczywiście można to zrobić bezpiecznie,
co zresztą od początku pisałem. Z tym że proponuję skasować USB
i zastosować małą kamerę - jest to bardzo dobre rozwiązanie, sprawdzone
w praktyce.

Bardzo dobrze że sefie tak latwo wydrukować. Ja proponuje jeszcze rozpoznawanie głosu póki nie wynaleziono magnetofonów.

http://www.computerworld.com/article/2531298/windows-pcs/laptop-face-recognition-tech-easy-to-hack-- warns-black-hat-researcher.html

Na marginesie: moc obliczeniowa jest zupełnie z innej półki jeśli chcesz sobie detektować twarz w małym chipie. Prawidłowo klasyfikować swój-inny. Bo jesli bedzie to klasyfikować komputer - nie będzie to już bezpieczne.

Oprócz poprawy bezpieczeństwa

W stosunku do panienki od nazwisk rodowych? No tak, w sumie tak.

Sebastian Biały <heby@poczta.onet.pl> writes:

Nie ma bezpiecznego rozwiązania. Jedynym jakie znam to odpalanie za
każdym razem systemu z LiveCD.

No to musisz się zdecydować - jest czy go nie ma :-)

Tak, wiem że może się skompilować sam, ale nie kązda distro ma
kompilator. Można tez napisać bootnet w bashu zapewne. Mozna. Tylko po
ch...

O to musiałbyś zapytać autorów. Bo wiesz, takie rzeczy są spotykane
w naturze (w szczególności na starszych maszynach pozbawionych opieki).

Obserwowałeś kiedyś pakiety TCP SYN na jakiś publiczny port 22?
To chyba nie jest celowane w MS Windows?

TPM jest w tej dyskucji tylko *przykładem* zabezpieczeń w krzemie.

Jest przykładem niepasującym do sytuacji.
Zabezpieczenia w samym krzemie są na tym poziomie całkowicie nieistotne,
wystarczy odpowiednia obudowa. To zupełnie nie ta klasa bezpieczeństwa.

W tak zmienionych warunkach rzeczywiście można to zrobić bezpiecznie,
co zresztą od początku pisałem. Z tym że proponuję skasować USB
i zastosować małą kamerę - jest to bardzo dobre rozwiązanie, sprawdzone
w praktyce.

Bardzo dobrze że sefie tak latwo wydrukować. Ja proponuje jeszcze
rozpoznawanie głosu póki nie wynaleziono magnetofonów.

http://www.computerworld.com/article/2531298/windows-pcs/laptop-face-recognition-tech-easy-to-hack-- warns-black-hat-researcher.html

Mam odpowiedzieć argumentem, że złącze USB da się "podrobić"?
Kamera nie służy przecież do rozpoznawania niczego oprócz kodu QR.
Może być kserokopia.

Żeby udowodnić że trojany na linuxie się problemem w kernelu należy
podać przykłady takich prób bądź ich istnienia.

Przecież był nawet podany przykład. Faktem jest, że zwykle trudno
udowodnić (poza takimi przypadkami), że wprowadzony przez kogoś bug jest
celowym trojanem. Aczkolwiek, jeśli exploit nieznanego publicznie
wcześniej buga systemu napisanego przez Agencję znajdujemy w sofcie
przeznaczonym dla "służb" do włamań, to różnie można to oceniać.

BTW: W bezpieczeństwie to tak nie działa - udowadnia się, że coś jest
bezpieczne, w przeciwnym przypadku nie jest takie. Ten pierwszy dowód
też często życie weryfikuje.

Przecież ipsec to tylko jeden przykład z wielu.

Niereprezentatywny.

Obecnie majstrowanie
przy kryptografii jest o tyle dobre że mało jest na świecie osob ktore
znajdą backdoor w wartwie matematycznej.

Jak nietrudno zauważyć nie jesteś osamotniony w tym poglądzie,
aczkolwiek życie pokazuje, że nie jest to takie proste.

TPM bedzie podpisywał bezpiecznie w każdych warunkach kiedy nie doszło
do kompromitacji fizycznej chipa. Ale my chcemy nie tylko wiedzieć że
chip istniał. Chcemy jeszcze wiedzieć że wlasciciel istniał i wiedział
co podpisuje. Do tego potrzebny jest wyświetlacz (pewnośc że to bank)
+ klawiatura (pewnośc że to user).

Sam widzisz: TPM ma się do tego dokładnie nijak.
--
Krzysztof Hałasa

On 2016-03-31 21:08, Krzysztof Halasa wrote:

Nie ma bezpiecznego rozwiązania. Jedynym jakie znam to odpalanie za
każdym razem systemu z LiveCD.

No to musisz się zdecydować - jest czy go nie ma :-)

Bo on jest chwilowo bezpieczny z powodu braku UEFI w BIOSie na *moim* kompie.

Obserwowałeś kiedyś pakiety TCP SYN na jakiś publiczny port 22?
To chyba nie jest celowane w MS Windows?

Ojej, pakiety na 22? Straszne. Pamiętam jak adminowałem siecią osiedlową swego czasu. Co kilkanaście minut miałem telefon że ktoś kogoś hakuje pingiem. No, co prawda to prawda, Win98 potrafił ładnie się wycypać od ping of death. Pakiety na 22, strasze. Lepieuj zapytaj ile było pakietów w sieci z Blastera. Średni czas przeżycia WinXP na modemie to było 30 sekund.

TPM jest w tej dyskucji tylko *przykładem* zabezpieczeń w krzemie.

Jest przykładem niepasującym do sytuacji.
Zabezpieczenia w samym krzemie są na tym poziomie całkowicie nieistotne,
wystarczy odpowiednia obudowa. To zupełnie nie ta klasa bezpieczeństwa.

ROTFL. No i widzisz, sensu istnienia TPM nie rozumiesz. One istnieją dlatego że są *zabezpieczone* w krzemie na ogromną ilośc sposobów powodując że wydłubanie sekretów jest nieosiągalne za normalne pieniądze. To jest *sedno*. Jak widze wolisz wyrzucić sedno i gadać o bzdurach typu podrabianie gniazdek USB. Super.

Bardzo dobrze że sefie tak latwo wydrukować. Ja proponuje jeszcze
rozpoznawanie głosu póki nie wynaleziono magnetofonów.
http://www.computerworld.com/article/2531298/windows-pcs/laptop-face-recognition-tech-easy-to-hack-- warns-black-hat-researcher.html

Mam odpowiedzieć argumentem, że złącze USB da się "podrobić"?

Podrabiaj. Nic to nie da. Mając do dyzpozycji układ podpisujący zawierający wewnątrz klucz ktorego nie można odczytać mogę sobie podpisywać wiarygodnie na dowolnie zawirusowanym komputerze i dowolnej ilości przelotek usb wstawianych pomiedzy scalak a komputer. Tak działają wszelakie "bezpieczne enklawy". Stan środowiska zewnętrznego nie wpływa na wiarygodność czegokolwiek wewnatrz. jedyne co możesz zsrobić to obstrukcję danych, która w sposob trywialny jest wykrywana po drugiej stronie (bank) albo DoS.

Kamera nie służy przecież do rozpoznawania niczego oprócz kodu QR.
Może być kserokopia.

O to jeszcze ciekawiej. Kod można cyknąć byle iPhone z odległości kilku metrów. I znowu security na poziomie dziadostwa, jak to zazwyczaj w bankowości. No i jak wiadomo nie istnoeja na świecie zlośliwe aplikacje ktore pozwalają przejąć na chwile kamerę która właśnie cyknąłeś zdjęcie. Uff...

Żeby udowodnić że trojany na linuxie się problemem w kernelu należy
podać przykłady takich prób bądź ich istnienia.

Przecież był nawet podany przykład. Faktem jest, że zwykle trudno
udowodnić (poza takimi przypadkami), że wprowadzony przez kogoś bug jest
celowym trojanem. Aczkolwiek, jeśli exploit nieznanego publicznie
wcześniej buga systemu napisanego przez Agencję znajdujemy w sofcie
przeznaczonym dla "służb" do włamań, to różnie można to oceniać.

Gdzie te trojany do manipulowania danymi przelewu w kernelspace się pytam? Można sobie dowolnie bajać o tajnych słuzbach Kamboży wciskających złośliwe trojany, ale GDZIE one są?

BTW: W bezpieczeństwie to tak nie działa - udowadnia się, że coś jest
bezpieczne

To niemożliwe. Podobnie jak nie da się udowodnić że OTW działa zawsze.

, w przeciwnym przypadku nie jest takie.

Nikt tu nie mówi o 100% bezpieczeństwie, raczej o absolutnie nieoplacalnym łamaniu zabezpieczeń.

TPM bedzie podpisywał bezpiecznie w każdych warunkach kiedy nie doszło
do kompromitacji fizycznej chipa. Ale my chcemy nie tylko wiedzieć że
chip istniał. Chcemy jeszcze wiedzieć że wlasciciel istniał i wiedział
co podpisuje. Do tego potrzebny jest wyświetlacz (pewnośc że to bank)
+ klawiatura (pewnośc że to user).

Sam widzisz: TPM ma się do tego dokładnie nijak.

Bo, co powtorze po raz Nty, TPM to tylko *przykład* technologii, a najwazniejszą częscią tej technologi są zabezpieczenia w krzemie które są *krytyczne* aby mówić o bezpieczeństwie tokenow bo czynia ich klonowanie/oszukiwanie nieopłacalnym.

Sebastian Biały <heby@poczta.onet.pl> writes:

Ojej, pakiety na 22? Straszne. Pamiętam jak adminowałem siecią
osiedlową swego czasu.

Baaardzo istotne. Faktem jest, że takie ataki dotyczą (domyślam się)
zarówno Windows jak i (wiem) Linuksa.

ROTFL. No i widzisz, sensu istnienia TPM nie rozumiesz.

Mylisz się, ja rozumiem zarówno ogólny sens, jak i działanie TPM. I nie
tylko jako "abstrakcyjny przykład technologii". Tym się różnimy.
Jest to łatwe do stwierdzenia - każdy, kto proponuje użycie TPM jako
zabezpieczenie kontaktu z bankiem, nie wie co pisze.

O to jeszcze ciekawiej. Kod można cyknąć byle iPhone z odległości
kilku metrów. I znowu security na poziomie dziadostwa, jak to
zazwyczaj w bankowości.

??? Nie ma związku. Nie myślisz chyba że przechwycenie kodu QR mogłoby
do czegoś służyć? To tylko niezabezpieczony kanał komunikacyjny.

No i jak wiadomo nie istnoeja na świecie
zlośliwe aplikacje ktore pozwalają przejąć na chwile kamerę która
właśnie cyknąłeś zdjęcie. Uff...

W specjalizowanym tokenie? Nawet jeśli je tam ktoś umieścił... (co jest
raczej bardzo mało prawdopodobne, za to dość łatwo byłoby znaleźć
winnego).
To co takiego zrobią te "aplikacje"? Wyświetlą brzydki rysunek?

Gdzie te trojany do manipulowania danymi przelewu w kernelspace się
pytam? Można sobie dowolnie bajać o tajnych słuzbach Kamboży
wciskających złośliwe trojany, ale GDZIE one są?

Mało śmieszne.

BTW: W bezpieczeństwie to tak nie działa - udowadnia się, że coś jest
bezpieczne

To niemożliwe. Podobnie jak nie da się udowodnić że OTW działa zawsze.

, w przeciwnym przypadku nie jest takie.

Nikt tu nie mówi o 100% bezpieczeństwie, raczej o absolutnie
nieoplacalnym łamaniu zabezpieczeń.

Znów musisz się zdecydować.
BTW takie dowody jednak przeprowadza się. Opierają się na pewnych
założeniach (np. na takim, że nie da się skutecznie rozłożyć odpowiednio
dużej liczby na czynniki). Opłacalność to masz w odporności karty
kablówki.

Bo, co powtorze po raz Nty, TPM to tylko *przykład* technologii, a
najwazniejszą częscią tej technologi są zabezpieczenia w krzemie które
są *krytyczne* aby mówić o bezpieczeństwie tokenow bo czynia ich
klonowanie/oszukiwanie nieopłacalnym.

Nie. Ale nie chce mi się już powtarzać tego samego, możesz sobie trwać
w tych swoich teoriach.
--
Krzysztof Hałasa

On Sun, 20 Mar 2016 20:56:47 +0100, Sebastian Biały<heby@poczta.onet.pl> wrote:

Przecież to samo można powiedzieć o każdym systemie OpenSource!

Wiesz co

robi twoje Ubuntu kiedy instaluje setkę aktualizacji? Myslisz że

miliny

oczu sledzą? Milony ludzi sprawdza każdą linie kodu nastepnego

programu

do ściągania pornoli? Serio?

Nie chodzi o to, Ĺźe OS jest "najlepsze" w ogĂłle, ale "lepsze niĹź ..." pod względem security  (w miejsce  ... wpisz dowolne CS).
To nie chodzi teĹź wcale o te mityczne miliony oczu wpatrujące się w kod i wyłapujące  bugi czy prĂłby kompromitacji.
Jak dotąd wszystkie próby wstaawienia backdorów np. do jądra linuxa zostały wyłapane, niekoniecznie dzięki milionom oczu.

--
Marek

W dniu niedziela, 20 marca 2016 21:43:39 UTC+1 użytkownik Marek napisał:

On Sun, 20 Mar 2016 20:56:47 +0100, Sebastian Biały<heby@poczta.onet.pl> wrote:
> Przecież to samo można powiedzieć o każdym systemie OpenSource! Wiesz co > robi twoje Ubuntu kiedy instaluje setkę aktualizacji? Myslisz że miliny > oczu sledzą? Milony ludzi sprawdza każdą linie kodu nastepnego programu > do ściągania pornoli? Serio?

Nie chodzi o to, że OS jest "najlepsze" w ogóle, ale "lepsze niż ...." pod względem security  (w miejsce  ... wpisz dowolne CS).
To nie chodzi też wcale o te mityczne miliony oczu wpatrujące się w kod i wyłapujące  bugi czy próby kompromitacji.
Jak dotąd wszystkie próby wstaawienia backdorów np. do jądra linuxa zostały wyłapane, niekoniecznie dzięki milionom oczu.

A o tych niewyłapanych kto wie?

On 2016-03-20 21:43, Marek wrote:

Jak dotąd wszystkie próby wstaawienia backdorów np. do jądra linuxa
zostały wyłapane, niekoniecznie dzięki milionom oczu.

A po co komu malware w jądrze? Zdecydowanie najwięcej atakow przeprowadza się przez byle jak naklepane aplikacje z gatunku albańskich (uruchom mnie, jestem waznym wir^M^M^Mfakturą).

On Sun, 20 Mar 2016 22:11:48 +0100, Sebastian Biały<heby@poczta.onet.pl> wrote:

A po co komu malware w jądrze?

Nie wiem, nie to było clue tej odpowiedzi.

--
Marek

On Sun, 20 Mar 2016, Sebastian Biały wrote:

On 2016-03-20 21:43, Marek wrote:

 Jak dotąd wszystkie prĂłby wstaawienia backdorĂłw np. do jądra linuxa
 zostały wyłapane, niekoniecznie dzięki milionom oczu.

A po co komu malware w jądrze? Zdecydowanie najwięcej atakow przeprowadza się przez byle jak naklepane aplikacje z gatunku albańskich (uruchom mnie, jestem waznym wir^M^M^Mfakturą).

Po co komu malware w jądrze? Np. po to, żeby nie było konieczności wysyłania mailem takich albańskich aplikacji i czekania aż ktoś kliknie.

On 2016-03-21 00:20, Rafal Jankowski wrote:

A po co komu malware w jądrze? Zdecydowanie najwięcej atakow
przeprowadza się przez byle jak naklepane aplikacje z gatunku
albańskich (uruchom mnie, jestem waznym wir^M^M^Mfakturą).

Po co komu malware w jądrze? Np. po to, żeby nie było konieczności
wysyłania mailem takich albańskich aplikacji i czekania aż ktoś kliknie.

A jak sie niby ten malware ma dostać do jądra? Telepatycznie? Akuratnie w remote exploit przodował kiedyś Win (Blaster). Obecnie cieżko mówić o dziurach remote z systemu OOtB.

On Wed, 23 Mar 2016, Sebastian Biały wrote:

On 2016-03-21 00:20, Rafal Jankowski wrote:

>  A po co komu malware w jądrze? Zdecydowanie najwięcej atakow
>  przeprowadza się przez byle jak naklepane aplikacje z gatunku
>  albańskich (uruchom mnie, jestem waznym wir^M^M^Mfakturą).
 Po co komu malware w jądrze? Np. po to, żeby nie było konieczności
 wysyłania mailem takich albańskich aplikacji i czekania aż ktoś kliknie.

A jak sie niby ten malware ma dostać do jądra? Telepatycznie?

OMG, Ty pamiętasz wogóle na co odpisujesz? Przecież byłą mowa o "próbach wstawienia backdorów do jądra". Czyli jak rozumiem przemycenia ich w kodzie pomimo wszelkich code review jakie muszą przejść zanim zostaną zaakceptowane.
A nawet jeśli zrozumiałeś to inaczej to co ma Twoje pytanie "jak ma się ten malware do tego jądra dostać" do mojej odpowiedzi na Twoje pytanie "po co malware w jądrze". Po co i jak to chyba dwie różne sprawy.

Użytkownik "Rafal Jankowski"  napisał w wiadomości grup dyskusyjnych:alpine.LFD.2.20.1603240842410.169031@oceanic.wsisiz.edu.pl...
On Wed, 23 Mar 2016, Sebastian Biały wrote:

A jak sie niby ten malware ma dostać do jądra? Telepatycznie?

OMG, Ty pamiętasz wogóle na co odpisujesz? Przecież byłą mowa o "próbach wstawienia backdorów do jądra". Czyli jak rozumiem przemycenia ich w kodzie pomimo wszelkich code review jakie muszą przejść zanim zostaną zaakceptowane.

a) kto robi review ? i ile zarabia :-)
b) po review - kto wstawia do dystrybucji/jadra ?
c) a jak sie jakis hacker zakradnie po review ?
d) drobna literowka i pojdzie inny include niz sie czytajacym wydaje,
e) mozna nie w jadrze, ale kompilatorze. Albo w biliotekach.
f) mozna w sprzecie - dysk, USB pen, procesor nawet - choc to oczywiscie zadanie dla Intela czy AMD.


J.

On Thu, 24 Mar 2016, J.F. wrote:

Użytkownik "Rafal Jankowski"  napisał w wiadomości grup dyskusyjnych:alpine.LFD.2.20.1603240842410.169031@oceanic.wsisiz.edu.pl...
On Wed, 23 Mar 2016, Sebastian Biały wrote:

>  A jak sie niby ten malware ma dostać do jądra? Telepatycznie?

OMG, Ty pamiętasz wogóle na co odpisujesz? Przecież byłą mowa o "próbach wstawienia backdorów do jądra". Czyli jak rozumiem przemycenia ich w kodzie pomimo wszelkich code review jakie muszą przejść zanim zostaną zaakceptowane.

a) kto robi review ? i ile zarabia :-)
b) po review - kto wstawia do dystrybucji/jadra ?
c) a jak sie jakis hacker zakradnie po review ?
d) drobna literowka i pojdzie inny include niz sie czytajacym wydaje,
e) mozna nie w jadrze, ale kompilatorze. Albo w biliotekach.
f) mozna w sprzecie - dysk, USB pen, procesor nawet - choc to oczywiscie zadanie dla Intela czy AMD.

Jak chcecie sobie dyskutować na temat absurdalnych literówek w includach to sobie dyskutujcie. Ja odpowiedziałem tylko na pytanie "po co malware w jądrze".

On 2016-03-24 09:35, Rafal Jankowski wrote:

Jak chcecie sobie dyskutować na temat absurdalnych literówek w includach
to sobie dyskutujcie. Ja odpowiedziałem tylko na pytanie "po co malware
w jądrze".

Po nic.

On 2016-03-24 08:47, Rafal Jankowski wrote:

OMG, Ty pamiętasz wogóle na co odpisujesz? Przecież byłą mowa o "próbach
wstawienia backdorów do jądra".

Wstawić backdor do jadra można kompilując sterownik z roota, grzebiąc po /dev/proc, podpinając firewire z mapowaniem ram itd. Nie dotyczy tylko kodu źrodolowego, jest cała masa innych metod. Z najnowszych to przezywanie kodu w pamięci karty gfx między restartami lub chowanie się w UEFI.

Czyli jak rozumiem przemycenia ich w
kodzie pomimo wszelkich code review jakie muszą przejść zanim zostaną
zaakceptowane.

Robie code review *ogromnej* aplikacji od wielu lat jako normalna czynność związaną z wykonywanym zawodem. Daje Ci gwarancje że jesli chce mieć zle zamiary to przejdę i code review bo milion oczu nie oznacza milikon razy dokładniej. Co prawda zdarzają się przykłady pozytywne (i przypadkowo odkryte):

https://freedom-to-tinker.com/blog/felten/the-linux-backdoor-attempt-of-2003/

Ale od tamtego czasu kernel jest znacznie większy a część kodu wychodzi poza kontrolę (sterowniki kart graficznych). Przeoczenie takiej linijki obecnie jest trywialne. I niepotrzebne. Niekt nie potrzebuje trojanów w trybie kernela. Do okradzenia usera z kasy wystarczy dowolna dziura na poziomie usera i czasami dodatkowa eskalacja do roota jeśli chcesz zrobić jakieś porządne ransomware. Masz roota, masz pamięć pod kontrolą -> trojany w jądrze są zbędne.

A nawet jeśli zrozumiałeś to inaczej to co ma Twoje pytanie "jak ma się
ten malware do tego jądra dostać" do mojej odpowiedzi na Twoje pytanie
"po co malware w jądrze". Po co i jak to chyba dwie różne sprawy.

Być może. Niestety zmartwie Cie: żadko ktore malware zajmuje się pierdołami typu lamanie roota. Do wykradzenia pieniędzy wystarczy byle gówno napisane przez imbecyla w VisualBasicu w postaci exe w mailu. W temacie problemów z tego watku kernel mode jest nieistotny.

On 2016-03-24 19:00, Sebastian Biały wrote:

żadko

Łomatko. Idę odmówić 10 zdrowasiek na pokutę.

On Thu, 24 Mar 2016 19:00:10 +0100, Sebastian Biały<heby@poczta.onet.pl> wrote:

Wstawić backdor do jadra można kompilując sterownik z roota

Rotfl, a już kompilując z usera to nie? A ja Cię za specjalistę miałem...

--
Marek

On 3/24/2016 4:17 PM, Marek wrote:

On Thu, 24 Mar 2016 19:00:10 +0100, Sebastian Biały<heby@poczta.onet.pl>
wrote:

Wstawić backdor do jadra można kompilując sterownik z roota

Rotfl, a już kompilując z usera to nie? A ja Cię za specjalistę miałem...

a co? z roota sie nie da?
jakbym już miał coś robić to machnąłbym to za jednym posiedzeniem.

On 2016-03-24 22:17, Marek wrote:

Wstawić backdor do jadra można kompilując sterownik z roota

Rotfl, a już kompilując z usera to nie? A ja Cię za specjalistę miałem...

Masz racje. Skompilowac można z usera. Wstawić nie.

PS. Czy to juz ten etap że lapiemy za słowa? Jeszcze chwila i ktos powie Hitler? On wait...

On Thu, 24 Mar 2016 22:18:27 +0100, Sebastian Biały<heby@poczta.onet.pl> wrote:

Masz racje. Skompilowac można z usera. Wstawić nie.
PS. Czy to juz ten etap że lapiemy za słowa? Jeszcze chwila i ktos

powie

Hitler? On wait...

Z mojej strony jeszcze nie, ale sygnał ostrzegawczy się odezwał. Jak dotąd często pozwalałem sobie czasami nie czytać dokładnie tego co piszesz z góry zakładając, że jak zwykłe "dobrze prawisz" a bardziej mnie interesowały uwagi Twoich adwersarzy. Teraz będę bardziej uważny.

--
Marek

On 2016-03-24 22:30, Marek wrote:

Z mojej strony jeszcze nie, ale sygnał ostrzegawczy się odezwał. Jak
dotąd często pozwalałem sobie czasami nie czytać dokładnie tego co
piszesz z góry zakładając, że jak zwykłe "dobrze prawisz" a bardziej
mnie interesowały uwagi Twoich adwersarzy. Teraz będę bardziej uważny.

Ale że po co masz być bardziej uważny na wypociny starego trola newsowego? Ja tu jestem żeby troche napsuć nerwów kilku nadętym misiaczkom głównie przez spuszczanie potwietrza z ich wyobrażenia swiata gdzie sa ważni i mówią mądre rzeczy podparte argumentem garniturowym i ignoranctwem. Na razie to jest jak zabieranie cukierka prezesowi banku. Taki sport. Nie przejmuj się tym i nie czytaj uważnie. To tylko trolling, ale jak widać całkiem zgrabny (tu skromności mi juz nie ostało, alem wszak cham jak już dowiedziono). Przynajmniej grupa się troche rozruszała.

On Thu, 24 Mar 2016, Sebastian Biały wrote:

On 2016-03-24 08:47, Rafal Jankowski wrote:

 OMG, Ty pamiętasz wogóle na co odpisujesz? Przecież byłą mowa o "próbach
 wstawienia backdorów do jądra".

Wstawić backdor do jadra można kompilując sterownik z roota, grzebiąc po /dev/proc, podpinając firewire z mapowaniem ram itd. Nie dotyczy tylko kodu źrodolowego, jest cała masa innych metod. Z najnowszych to przezywanie kodu w pamięci karty gfx między restartami lub chowanie się w UEFI.

Chyba Cię jednak pamięć zawodzi bo mowa była o próbach wstawienia backdora do jądra z których żadna nie odniosła skutku (według ogólnej wiedzy, której prawdziwość czy raczej pewność parę osób kwestionowało). Czyli jest raczej oczywiste, że chodziło o kod źródłowy.  To o czym piszesz to zupełnie co innego, ale jak chcesz sobie dryfować na takie tematy to sobie dryfuj.

 Czyli jak rozumiem przemycenia ich w
 kodzie pomimo wszelkich code review jakie muszą przejść zanim zostaną
 zaakceptowane.

Robie code review *ogromnej* aplikacji od wielu lat jako normalna czynność związaną z wykonywanym zawodem. Daje Ci gwarancje że jesli chce mieć zle zamiary to przejdę i code review bo milion oczu nie oznacza milikon razy dokładniej. Co prawda zdarzają się przykłady pozytywne (i przypadkowo odkryte):

https://freedom-to-tinker.com/blog/felten/the-linux-backdoor-attempt-of-2003/

Ale od tamtego czasu kernel jest znacznie większy a część kodu wychodzi poza kontrolę (sterowniki kart graficznych). Przeoczenie takiej linijki obecnie jest trywialne. I niepotrzebne. Niekt nie potrzebuje trojanów w trybie kernela. Do okradzenia usera z kasy wystarczy dowolna dziura na poziomie usera i czasami dodatkowa eskalacja do roota jeśli chcesz zrobić jakieś porządne ransomware. Masz roota, masz pamięć pod kontrolą ->  trojany w jądrze są zbędne.

Jest pewna grupa osób, którym były one potrzebne dlatego próbowali je tam umieścić. Zresztą nie tylko w jądrze w SSLu i paru innych powszechnie stosowanych kawałkach softu również.

 A nawet jeśli zrozumiałeś to inaczej to co ma Twoje pytanie "jak ma się
 ten malware do tego jądra dostać" do mojej odpowiedzi na Twoje pytanie
 "po co malware w jądrze". Po co i jak to chyba dwie różne sprawy.

Być może. Niestety zmartwie Cie: żadko ktore malware zajmuje się pierdołami typu lamanie roota. Do wykradzenia pieniędzy wystarczy byle gówno napisane przez imbecyla w VisualBasicu w postaci exe w mailu. W temacie problemów z tego watku kernel mode jest nieistotny.

Specjalnie mnie nie zmartwiłeś. Malware w jądrze to taki remote desktop. Możesz go użyć do wykonania przelewu albo czytania nieswojej poczty. Zależy co kto lubi.

On 2016-03-24 23:24, Rafal Jankowski wrote:

Chyba Cię jednak pamięć zawodzi bo mowa była o próbach wstawienia
backdora do jądra z których żadna nie odniosła skutku (według ogólnej
wiedzy, której prawdziwość czy raczej pewność parę osób kwestionowało).
Czyli jest raczej oczywiste, że chodziło o kod źródłowy.

Ale dlaczego oczywiste?

 To o czym
piszesz to zupełnie co innego, ale jak chcesz sobie dryfować na takie
tematy to sobie dryfuj.

Piszę o realnych problemach współczesnych monolitycznych kerneli i współczesnego hardware. Kod źrodłowy kernela jest bez znaczenia jako źrodlo trojanów. Możesz sobie dryfować w kierunku oceny jakosci kernela pod katem widoczności bądź nie kodu. Niestety główne i realne problemy bezpieczeństwa znajdują się gdzie indziej i wynikają choćby z monlityczności współczesnych kerneli.

Jest pewna grupa osób, którym były one potrzebne dlatego próbowali je
tam umieścić. Zresztą nie tylko w jądrze w SSLu i paru innych
powszechnie stosowanych kawałkach softu również.

No i? niedawno jakas dystrybucja została zarażona trojanem i udostępniona jako iso na stronie oficjalnej. No i? Zauważ że nie tak dawno wymyślono sobie ze zarazi się środowisko programistyczne na maka co wygenerowało masę aplikacji z trojanami bez wiedzy programistów. No i? Czy już wspomniałem że *WSZYSTKIE* współczesne OSy sa gówno warte?

Specjalnie mnie nie zmartwiłeś. Malware w jądrze to taki remote desktop.
Możesz go użyć do wykonania przelewu albo czytania nieswojej poczty.
Zależy co kto lubi.

No patrz, zupełnie jak zwykły kawalek kodu w userspace. Na co komu kernelować kompila skoro wirusy albańskie są znacznie bardziej skuteczne?

On Fri, 25 Mar 2016, Sebastian Biały wrote:

On 2016-03-24 23:24, Rafal Jankowski wrote:

 Chyba Cię jednak pamięć zawodzi bo mowa była o próbach wstawienia
 backdora do jądra z których żadna nie odniosła skutku (według ogólnej
 wiedzy, której prawdziwość czy raczej pewność parę osób kwestionowało).
 Czyli jest raczej oczywiste, że chodziło o kod źródłowy.

Ale dlaczego oczywiste?

Chociażby dlatego, że mowa była o *nieudanych* próbach wprowadzenia do kernela backdorów, a z przytoczonych przez Ciebie pewnie coś ok 100% było udanych?

 To o czym
 piszesz to zupełnie co innego, ale jak chcesz sobie dryfować na takie
 tematy to sobie dryfuj.

Piszę o realnych problemach współczesnych monolitycznych kerneli i współczesnego hardware. Kod źrodłowy kernela jest bez znaczenia jako źrodlo trojanów. Możesz sobie dryfować w kierunku oceny jakosci kernela pod katem widoczności bądź nie kodu. Niestety główne i realne problemy bezpieczeństwa znajdują się gdzie indziej i wynikają choćby z monlityczności współczesnych kerneli.

Hm, tutaj to dyskutujesz sam ze sobą, nie będę przeszkadzać.

 Jest pewna grupa osób, którym były one potrzebne dlatego próbowali je
 tam umieścić. Zresztą nie tylko w jądrze w SSLu i paru innych
 powszechnie stosowanych kawałkach softu również.

No i? niedawno jakas dystrybucja została zarażona trojanem i udostępniona jako iso na stronie oficjalnej. No i? Zauważ że nie tak dawno wymyślono sobie ze zarazi się środowisko programistyczne na maka co wygenerowało masę aplikacji z trojanami bez wiedzy programistów. No i? Czy już wspomniałem że *WSZYSTKIE* współczesne OSy sa gówno warte?

Wiesz, jakiś czas temu było skompromitowane repozytorium nagiosa. Tylko ile procent komputerów ma zainstalowanego nagiosa? A kernel Linuksa? Chyba trochę więcej co nie? Więc sens wprowadzania backdora do kernala jest taki, że zaafektuje to ogromną liczbę komputerów.

 Specjalnie mnie nie zmartwiłeś. Malware w jądrze to taki remote desktop.
 Możesz go użyć do wykonania przelewu albo czytania nieswojej poczty.
 Zależy co kto lubi.

No patrz, zupełnie jak zwykły kawalek kodu w userspace. Na co komu kernelować kompila skoro wirusy albańskie są znacznie bardziej skuteczne?

Oczywiście backdor w userspace tym badziej działający na prawach roota/administratora jest równie dobry jak backdor w kernelu.

Ale Twoje albańskie wirusy są 8====0 warte, bo do uruchomienia wymagają jeszcze interfejsu białkowego.

On 2016-03-25 21:29, Rafal Jankowski wrote:

 Chyba Cię jednak pamięć zawodzi bo mowa była o próbach wstawienia
 backdora do jądra z których żadna nie odniosła skutku (według ogólnej
 wiedzy, której prawdziwość czy raczej pewność parę osób kwestionowało).
 Czyli jest raczej oczywiste, że chodziło o kod źródłowy.

Ale dlaczego oczywiste?

Chociażby dlatego, że mowa była o *nieudanych* próbach wprowadzenia do
kernela backdorów, a z przytoczonych przez Ciebie pewnie coś ok 100%
było udanych?

Ja przytoczylem nieudaną, acz znaleziona przypadkiem. Problem jest w czyms innym: nikt nie wprowadza backdoorów i trojanów od *lat* do jadra linuxa, bsd. natomiast pociesze cie: istnieje spore prawdopodobieństwo że niektóre elementy związane z kryptofrafią w OSach (okolice ipv6) zostały dyskretnie skompromitowane w sposób matematyczny (np. poprzez oslabienie generatora liczb losowych lub samych algorytmów). Najbardziej zabawne jest nie to że ktoś to odkrył na code review. Najbardziej zabawne jest to że nawet jesli wiesz ze to może tam być - nie potrafimy tego znaleźć:

http://www.ipv6security.nl/?p=1238

Daj sobie spokój z trojanami w kodzie kernela. Komu to potrzebne.

Wiesz, jakiś czas temu było skompromitowane repozytorium nagiosa. Tylko
ile procent komputerów ma zainstalowanego nagiosa? A kernel Linuksa?
Chyba trochę więcej co nie?

Niewiele. Chyba że dodamy androida. Ale w androidzie jest tak wiele dziur w user space że nie ma to sensu.

Więc sens wprowadzania backdora do kernala
jest taki, że zaafektuje to ogromną liczbę komputerów.

Nie. Możesz co prawda wstawić trywialne = zamiast == i liczyć ze ktoś nie zauważy ,ale problem infekcji tego systemu czymś *użytecznym* już trywialny nie jest. Wsadzenie czegoś uzytecznego do kernela zostanie natychmiast wykryte.

Wychodzi na to że zamiast wprowadzać dziury w kernel lepiej szukać dziur już tam istniejących. Ryzyko wpadki mniejsze.

No patrz, zupełnie jak zwykły kawalek kodu w userspace. Na co komu
kernelować kompila skoro wirusy albańskie są znacznie bardziej skuteczne?

Oczywiście backdor w userspace tym badziej działający na prawach
roota/administratora jest równie dobry jak backdor w kernelu.
Ale Twoje albańskie wirusy są 8====0 warte, bo do uruchomienia wymagają
jeszcze interfejsu białkowego.

Intefejsy białkowe siedzace przy złomach od jakiś 15 lat mają średnie IQ w okolicy 100. Czyli to tylko kwestia napisania maila. Ostatnie kampanie mailowe sa bardzo interesujące. Sądząc po ilościach - zapewne przynoszą spore zyski.

On Fri, 25 Mar 2016, Sebastian Biały wrote:

On 2016-03-25 21:29, Rafal Jankowski wrote:

> >   Chyba Cię jednak pamięć zawodzi bo mowa była o próbach wstawienia
> >   backdora do jądra z których żadna nie odniosła skutku (według ogólnej
> >   wiedzy, której prawdziwość czy raczej pewność parę osób > >   kwestionowało).
> >   Czyli jest raczej oczywiste, że chodziło o kod źródłowy.
>  Ale dlaczego oczywiste?
 Chociażby dlatego, że mowa była o *nieudanych* próbach wprowadzenia do
 kernela backdorów, a z przytoczonych przez Ciebie pewnie coś ok 100%
 było udanych?

Ja przytoczylem nieudaną, acz znaleziona przypadkiem.

Ty na pewno wziąłeś te tabletki na schizę? Możemy wprowadzić jakąś logikę do tych rozważań?

- Twój przedpiśca pisze o nieudanych próbach wstawienia backdoora do
   jądra.
- Ty (jako kontrargument) odpisujesz coś o skutecznym wstawianiu backdorów
   przy pomocy urządzeń firewire i dalej faktycznie o próbie wstawienia
   kawałka kodu w CVS, ale wyłapanej co tylko potwierdza postawioną tezę.
- Ja na to, że piszesz od czapki że (o tym firewire, UEFI i kartach gfx).
- A Ty że przecież pisałeś o zmianach w kodzie.

 Wiesz, jakiś czas temu było skompromitowane repozytorium nagiosa. Tylko
 ile procent komputerów ma zainstalowanego nagiosa? A kernel Linuksa?
 Chyba trochę więcej co nie?

Niewiele. Chyba że dodamy androida. Ale w androidzie jest tak wiele dziur w user space że nie ma to sensu.

Nie liczę androida, ale liczę że spora część użytkowników androida przechowuje gdzieś swoje dane (bankowe czy jakiekolwiek inne) na serwerach gdzie jest kernel linuksa.

 Więc sens wprowadzania backdora do kernala
 jest taki, że zaafektuje to ogromną liczbę komputerów.

Nie. Możesz co prawda wstawić trywialne = zamiast == i liczyć ze ktoś nie zauważy ,ale problem infekcji tego systemu czymś *użytecznym* już trywialny nie jest. Wsadzenie czegoś uzytecznego do kernela zostanie natychmiast wykryte.

Użycie podstawowej funkcji systemowej do zmiany UID faktycznie zostanie wykrytę w nanosekundę, ale to tylko dowód na to, że tamten konkretny backdor był niezbyt wyrafinowany. Zresztą nie znamy nawet zamierzeń autora. Przypuszczalnie nie chciał nawet w rzeczywistości umieścić tego backdora a przetestować reakcję środowiska na tą sytuację.

Intefejsy białkowe siedzace przy złomach od jakiś 15 lat mają średnie IQ w okolicy 100. Czyli to tylko kwestia napisania maila. Ostatnie kampanie mailowe sa bardzo interesujące. Sądząc po ilościach - zapewne przynoszą spore zyski.

OK, do wyłudzania kasy z konta tym bardziej jak cel nie jest jasno określony tylko dowolny to faktycznie łatwiej jest wysłać milion maili z wygaszaczem ekranu. Ale w zastosowaniach bardziej uniwersalnych ta metoda albańskiego wirusa może nie spełnić oczekiwań.

On 2016-03-26 03:12, Rafal Jankowski wrote:

 Chociażby dlatego, że mowa była o *nieudanych* próbach wprowadzenia do
 kernela backdorów, a z przytoczonych przez Ciebie pewnie coś ok 100%
 było udanych?

Ja przytoczylem nieudaną, acz znaleziona przypadkiem.

Ty na pewno wziąłeś te tabletki na schizę? Możemy wprowadzić jakąś
logikę do tych rozważań?

Nie ma biznesowej logiki. Prawdopodobnie jestes oszołomiony faktem że dyskutant może wprowadzać argumenty za tezą przeciwnika jako częściowe potwierdzenie jego słów. Trudno. Podzwigniesz się.

- Twój przedpiśca pisze o nieudanych próbach wstawienia backdoora do
   jądra.
- Ty (jako kontrargument) odpisujesz coś o skutecznym wstawianiu backdorów
   przy pomocy urządzeń firewire i dalej faktycznie o próbie wstawienia
   kawałka kodu w CVS, ale wyłapanej co tylko potwierdza postawioną tezę.

Tak. Po pierwsze znam jedną nieudana próbe zbackdorowania linuxa która zostala przypadkiem odkryta. Po drugie problem z firewire jest *poważny* ponieważ urzadzenia tego typu mają zmapowany cały ram. Co oznacza że o ile istnieje tylko jedna nieudana próba wsadzenia backdoora w kernel to istniejerównież milion innych urządzeń in the wild co do których nie masz zaufania. Patrząc w ten sposób robi się próby infekowania sterowników klawiatury, myszek, biosów uważam że wsadzanie trojanów w kernel jest bez sensu skoro go można ukryć poza dostępem kernela.

Niewiele. Chyba że dodamy androida. Ale w androidzie jest tak wiele
dziur w user space że nie ma to sensu.

Nie liczę androida

Szkoda, bo to linux.

, ale liczę że spora część użytkowników androida
przechowuje gdzieś swoje dane (bankowe czy jakiekolwiek inne) na
serwerach gdzie jest kernel linuksa.

Na serwerach nie zmienia się kernela na codzień. Zawsze możesz przedstawić backdora w kodzie przylapanego gdzieś na serwerze. Nie ma go bo nie ma po co. Natomiats jak chcesz troche większy hardcore to co powiedz na algorytmy które za pomoca pomiarów latency cache (z user space) potrafią wykradać sekrety z pracującej rownolegle maszyny wirtualnej?

Intefejsy białkowe siedzace przy złomach od jakiś 15 lat mają średnie
IQ w okolicy 100. Czyli to tylko kwestia napisania maila. Ostatnie
kampanie mailowe sa bardzo interesujące. Sądząc po ilościach - zapewne
przynoszą spore zyski.

OK, do wyłudzania kasy z konta tym bardziej jak cel nie jest jasno
określony tylko dowolny to faktycznie łatwiej jest wysłać milion maili z
wygaszaczem ekranu. Ale w zastosowaniach bardziej uniwersalnych ta
metoda albańskiego wirusa może nie spełnić oczekiwań.

Masz przykłady bardziej uniwersalnych?

Dnia Sat, 26 Mar 2016 19:58:45 +0100, Sebastian Biały napisał(a):

On 2016-03-26 03:12, Rafal Jankowski wrote:

- Twój przedpiśca pisze o nieudanych próbach wstawienia backdoora do
   jądra.
- Ty (jako kontrargument) odpisujesz coś o skutecznym wstawianiu backdorów
   przy pomocy urządzeń firewire i dalej faktycznie o próbie wstawienia
   kawałka kodu w CVS, ale wyłapanej co tylko potwierdza postawioną tezę.

Tak. Po pierwsze znam jedną nieudana próbe zbackdorowania linuxa która zostala przypadkiem odkryta. Po drugie problem z firewire jest *poważny* ponieważ urzadzenia tego typu mają zmapowany cały ram. Co oznacza że o ile istnieje tylko jedna nieudana próba wsadzenia backdoora w kernel to istniejerównież milion innych urządzeń in the wild co do których nie masz zaufania. Patrząc w ten sposób robi się próby infekowania sterowników klawiatury, myszek, biosów uważam że wsadzanie trojanów w kernel jest bez sensu skoro go można ukryć poza dostępem kernela.

Ale wiesz - myszka ma niewielkie mozliwosci. Kernel olbrzymie.
No chyba, zeby tak zgrabnie myszke oprogramowac, ze gdzies w nocy
zacznie sama tak klikac, ze kernela zmieni :-)

A propos, o czlowieku ktory "almost broke the Internet" http://www.businessinsider.co.id/npm-left-pad-controversy-explained-2016-3/#.VvbkQebIh1g

Pokazuje, jak to dzis wyglada, choc na szczescie - chyba nie w
bankach.

J.

On 2016-03-26 20:40, J.F. wrote:

Ale wiesz - myszka ma niewielkie mozliwosci. Kernel olbrzymie.
No chyba, zeby tak zgrabnie myszke oprogramowac, ze gdzies w nocy
zacznie sama tak klikac, ze kernela zmieni :-)

M.in o to chodzi w najprostszej wersji:

http://www.tripwire.com/state-of-security/security-data-protection/danger-usb/
http://www.scmp.com/news/world/article/1563822/keyboards-mice-and-thumb-drives-used-hide-malware-and-computers-powerless
http://www.extremetech.com/computing/187279-undetectable-indefensible-security-flaw-found-in-usb-its-time-to-get-your-ps2-keyboard-out-of-the-cupboard

Co do uefi to jest to o tyle wygodne że w pewnym sensie kernel jest slave biosu:

http://www.pcworld.com/article/2948092/security/hacking-teams-malware-uses-uefi-rootkit-to-survive-os-reinstalls.html

Dochodzi do takiego poziomu absurdu że producenci sprzętu w ich mniemaniu legalnie instalują malware be design:

https://zaufanatrzeciastrona.pl/post/tylna-furtka-w-laptopach-lenovo-tym-razem-w-uefi/

I teraz sprobuj mając do czynienia z takim typem malware dyskutować sobie w sądzie na tematy techniczne z misiem który z trudem przeczytal by ksiązkę z zakresu techniki dla podstawówki.

Sebastian Biały <heby@poczta.onet.pl> writes:

Po drugie problem z firewire jest
*poważny* ponieważ urzadzenia tego typu mają zmapowany cały ram.

Domyślnie, dostępne jest pierwsze 4 GB przestrzeni adresowej (modulo
sztuczki z IOMMU). W praktyce nie jest to obecnie żaden problem,
a w ogóle nowe komputery prawie nie mają FireWire.

BTW to bardzo fajne narzędzie.
--
Krzysztof Hałasa

Sebastian Biały <heby@poczta.onet.pl> writes:

Problem jest w
czyms innym: nikt nie wprowadza backdoorów i trojanów od *lat* do
jadra linuxa, bsd.

Poważnie? A skąd ta wiedza?
Bo jeśli takiej nie masz (a wiemy że nie masz - bo nikt nie ma) to
jedyne bezpieczne założenie jest przeciwne.

natomiast pociesze cie: istnieje spore
prawdopodobieństwo że niektóre elementy związane z kryptofrafią w
OSach (okolice ipv6) zostały dyskretnie skompromitowane w sposób
matematyczny (np. poprzez oslabienie generatora liczb losowych lub
samych algorytmów).

IPv6 to drobiazg. Czytasz niewłaściwe fragmenty. Zainteresuj się
np. FIPS, a nie jakimś superniszowym IPSEC w IPv6.
--
Krzysztof Hałasa

On 2016-03-29 00:39, Krzysztof Halasa wrote:

Problem jest w
czyms innym: nikt nie wprowadza backdoorów i trojanów od *lat* do
jadra linuxa, bsd.

Poważnie? A skąd ta wiedza?
Bo jeśli takiej nie masz (a wiemy że nie masz - bo nikt nie ma) to
jedyne bezpieczne założenie jest przeciwne.

Żeby udowodnić że trojany na linuxie się problemem w kernelu należy podać przykłady takich prób bądź ich istnienia. Jesli nie ma takich przykładów to hipoteza odrzucana jest z automatu. Jak napisałem istnieje niewielka szansa że nsa/whatever majstrowała przy kryptografii ipsec. Ale to nie jest dziura w kernelu tylko w specyfikacji protokołu.

Nie rozumiem dlaczego mialym udowaniać że nie ma czegoś czego nie stwierdzono. Mam *udowadniać* że nie bylo wybuchów w wiadomym samolocie czy też raczej mam *udowadniać* że były?

IPv6 to drobiazg. Czytasz niewłaściwe fragmenty. Zainteresuj się
np. FIPS, a nie jakimś superniszowym IPSEC w IPv6.

Przecież ipsec to tylko jeden przykład z wielu. Obecnie majstrowanie przy kryptografii jest o tyle dobre że mało jest na świecie osob ktore znajdą backdoor w wartwie matematycznej.

Sebastian Biały <heby@poczta.onet.pl> writes:

Robie code review *ogromnej* aplikacji od wielu lat jako normalna
czynność związaną z wykonywanym zawodem. Daje Ci gwarancje że jesli
chce mieć zle zamiary to przejdę i code review bo milion oczu nie
oznacza milikon razy dokładniej. Co prawda zdarzają się przykłady
pozytywne (i przypadkowo odkryte):

https://freedom-to-tinker.com/blog/felten/the-linux-backdoor-attempt-of-200/3

To akurat nie miało żadnego związku z code review, w tamtych czasach
Linus i sp. używali takiego narzędzia "BitKeeper", a dla osób, które nie
chciały tego używać (np. ze względu na brak źródeł, albo na
12-miesięczny zakaz pracy przy "konkurencyjnych projektach"), był
automatyczny mirror w CVSie. I do tego ostatniego ktoś się włamał.
Nikt, kto nie korzystał z tego serwera CVS, nie dostał tego backdoora.

Zostało to odkryte przez przypuszczalnie LMcV przez proste porównanie
zawartości bitmovera i cvsa.

Duuużo bardziej niebezpieczne było późniejsze włamanie do *.kernel.org,
w którym atakujący mieli dostęp do całego archiwum, a także chyba do
kluczy używanych do generowania podpisów .sig. Na szczęście to były
czasy gita i żadne numery z wstawieniem czegoś do repozytorium już nie
przechodziły.


Tak czy owak, code review taki jak tu daje szansę wykrycia backdoora,
ale jaka to jest szansa - taka sobie.

Ale od tamtego czasu kernel jest znacznie większy a część kodu
wychodzi poza kontrolę (sterowniki kart graficznych).

Binarne sterowniki kart graficznych do Linuksa były dużo wcześniej,
jeszcze w ubiegłym wieku. Sam się na nie nadziałem, więc pamiętam im to
aż za dobrze.

Być może. Niestety zmartwie Cie: żadko ktore malware zajmuje się
pierdołami typu lamanie roota. Do wykradzenia pieniędzy wystarczy byle
gówno napisane przez imbecyla w VisualBasicu w postaci exe w mailu. W
temacie problemów z tego watku kernel mode jest nieistotny.

To jest akurat prawda.
--
Krzysztof Hałasa

W dniu 2016-03-20 o 21:43, Marek pisze:

Jak dotąd wszystkie próby wstaawienia backdorów np. do jądra linuxa
zostały wyłapane, niekoniecznie dzięki milionom oczu.

Dlaczego uważasz że to wiesz?

Rafal Jankowski <jankowsr@oceanic.wsisiz.edu.pl> writes:

Jesteś fanatykiem. Nie znam TPMów, nie będę się wypowiadał. Jest to
jednak zwykły kawałek krzemu realizujący jakieś funkcje
kryptograficzne pewnie podobne do np. HSMĂłw albo SGXa i owszem,
zwiększają one bezpieczeństwo ale o ile ich model matematyczny może
wyglądać bardzo fajnie to zawsze są pewne słabości albo od takich
trywialnych że wpinasz się kabelkami pomiędzy scalak a ściezki na
płycie i wyciągasz wrażliwe informacje.

To inna klasa ataku, wymaga dostępu fizycznego, a na to w praktyce nie
ma żadnej rady, przynajmniej w kontekście dostępu do banków przez
Internet.

Ale TPM to nie jest Ĺźadne panaceum, to tylko jeden z elementĂłw
układanki, i nic on nie da, jeśli w systemie ogólnego przeznaczenia
będzie wiele dziur (a tak właśnie jest i będzie).

Dlatego potrzebne jest oddzielne, bezpieczne urządzenie. Pecet, telefon,
tablet - nie są w tym sensie bezpieczne.

Takie urządzenia są zresztą wykorzystywane (np. do innych zastosowań),
tyle że cena dla end usera (z cłami, VATami, i pocałowaniem w d) to
np. $100 albo inne E500.
--
Krzysztof Hałasa

On Tue, 22 Mar 2016, Krzysztof Halasa wrote:

Rafal Jankowski <jankowsr@oceanic.wsisiz.edu.pl> writes:

Jesteś fanatykiem. Nie znam TPMów, nie będę się wypowiadał. Jest to
jednak zwykły kawałek krzemu realizujący jakieś funkcje
kryptograficzne pewnie podobne do np. HSMĂłw albo SGXa i owszem,
zwiększają one bezpieczeństwo ale o ile ich model matematyczny może
wyglądać bardzo fajnie to zawsze są pewne słabości albo od takich
trywialnych że wpinasz się kabelkami pomiędzy scalak a ściezki na
płycie i wyciągasz wrażliwe informacje.

To inna klasa ataku, wymaga dostępu fizycznego, a na to w praktyce nie
ma żadnej rady, przynajmniej w kontekście dostępu do banków przez
Internet.

Ale TPM to nie jest Ĺźadne panaceum, to tylko jeden z elementĂłw
układanki, i nic on nie da, jeśli w systemie ogólnego przeznaczenia
będzie wiele dziur (a tak właśnie jest i będzie).

Wydaje mi się, że bezpieczna eklawa Intel SGX czy ewentualnie jakaś trustzone'a ARMa mogłaby pełnić rolę takiego urządzenia. Tylko taka bezpiecznie sprovisionowana aplikacja miałaby możliwość łączenia się z bankiem, a dodatkowo transakcja musiałaby być podpisana tokenem. Ale przyznam, że jakoś szczególnie nie myślałem nad tym, więc mogę być w błędzie.

On 2016-03-22 00:01, Krzysztof Halasa wrote:

Ale TPM to nie jest żadne panaceum, to tylko jeden z elementów
układanki, i nic on nie da, jeśli w systemie ogólnego przeznaczenia
będzie wiele dziur (a tak właśnie jest i będzie).

Nie jest to prawda. Możesz mieć dowolna ilość dziur. Do momentu ataku fizycznie na chip bedzie on podpisywał w sposób bezpieczny i pewny (od początku zakładam wyświetlacz i pin). Jedyną forma ataku jest wtedy DoS czyli nic.

Sebastian Biały <heby@poczta.onet.pl> writes:

Ale TPM to nie jest żadne panaceum, to tylko jeden z elementów
układanki, i nic on nie da, jeśli w systemie ogólnego przeznaczenia
będzie wiele dziur (a tak właśnie jest i będzie).

Nie jest to prawda. Możesz mieć dowolna ilość dziur. Do momentu ataku
fizycznie na chip bedzie on podpisywał w sposób bezpieczny i pewny (od
początku zakładam wyświetlacz i pin). Jedyną forma ataku jest wtedy
DoS czyli nic.

Niestety TPM nie ma wyświetlacza - a więc to co napisałem jest prawdą.
--
Krzysztof Hałasa

On 2016-03-29 00:45, Krzysztof Halasa wrote:

Ale TPM to nie jest żadne panaceum, to tylko jeden z elementów
układanki, i nic on nie da, jeśli w systemie ogólnego przeznaczenia
będzie wiele dziur (a tak właśnie jest i będzie).

Nie jest to prawda. Możesz mieć dowolna ilość dziur. Do momentu ataku
fizycznie na chip bedzie on podpisywał w sposób bezpieczny i pewny (od
początku zakładam wyświetlacz i pin). Jedyną forma ataku jest wtedy
DoS czyli nic.

Niestety TPM nie ma wyświetlacza - a więc to co napisałem jest prawdą.

TPM bedzie podpisywał bezpiecznie w każdych warunkach kiedy nie doszło do kompromitacji fizycznej chipa. Ale my chcemy nie tylko wiedzieć że chip istniał. Chcemy jeszcze wiedzieć że wlasciciel istniał i wiedział co podpisuje. Do tego potrzebny jest wyświetlacz (pewnośc że to bank) + klawiatura (pewnośc że to user).

On Sun, 20 Mar 2016 14:15:32 +0100, Sebastian Biały<heby@poczta.onet.pl> wrote:

To nie jest takie trywialne, token w powiązaniu z unikatową cechą komputera (numer seryjny cpu etc) uniemożliwia tego typu przekręt w sposób wystarczająco skuteczny. Ba, kto mówi do tokenie z ktorego

się

cos przepisuje, dlaczego nie wtykany w USB?. Niech zgadne, bankowy debilomanager właśnie obcina koszty, bo komu potrzebne są jakieś

numery

seryjne cpu.

Ale po co bijecie pianę? Zasady są bardzo proste, transakcja autoryzowana jest tylko wtedy, gdy dokonuje ją upoważniony umową (autoryzowany) użytkownik. W przypadkach spornych to problem stron sporu aby wykazać/udowdnić czy transakcja była autoryzowana czy nie.

--
Marek

On 2016-03-20 15:12, Marek wrote:

(autoryzowany) uĹźytkownik. W przypadkach spornych to problem stron sporu
aby wykazać/udowdnić czy transakcja była autoryzowana czy nie.

No właśnie. Po zastosowaniu prostackich środkow technicznych problem udowaniania nie istnieje. Bo problem malware, złodziei, wyłudzania nie istnieje. Tadaaaam!

Bicie piany w tym wypadku jest zasadniczo istotne: ludzie nie mają pojęcia że ich banki wcale nie stosują zaawansowanych srodkow technicznych a jedynie kupe gówna nazywaną security a tak naprawdę przerzucają co moga ze swojej odpowiedzialności na klienta w posob często ordynarny. Być może ta świadomość wygeneruje kiedyś zwrot w kierunku prawdziwego security. Ale nie, nie jestem aż tak głupi żeby zakładać że kiedyś debilomanagerzy zostaną zwolnienie z pracy, więc to utopia.

On Sun, 20 Mar 2016 15:29:54 +0100, Sebastian Biały<heby@poczta.onet.pl> wrote:

No właśnie. Po zastosowaniu prostackich środkow technicznych

problem

udowaniania nie istnieje. Bo problem malware, złodziei, wyłudzania

nie

istnieje. Tadaaaam!

Kraje cywilizowane dawno z tym sobie poradziły stosując chargeback dla transakcji nieautoryzowanych. I żadnych wyrafinowanych środków technicznych do tego nie trzeba.

Bicie piany w tym wypadku jest zasadniczo istotne: ludzie nie mają pojęcia że ich banki wcale nie stosują zaawansowanych srodkow technicznych a jedynie kupe gówna nazywaną security a tak naprawdę przerzucają co moga ze swojej odpowiedzialności na klienta w posob często ordynarny. Być może ta świadomość wygeneruje kiedyś zwrot w kierunku prawdziwego security. Ale nie, nie jestem aż tak głupi

Ĺźeby

zakładać że kiedyś debilomanagerzy zostaną zwolnienie z pracy, więc

to

utopia.

Więc jaki sens jest wyraĹźanie  konkluzji utopijnych, co ostatnio się Ci dość często zdarza :)? Nie, nie zostaną zwolnieni z pracy i będą za wszelką cenę prĂłbować przy kaĹźdej okazji przerzucać odpowiedzialność na klienta.
Dlatego prawo powinno chronić obywateli przed banksterami, bez względu jak wyrafinowane technicznie metody stosują.

--
Marek

On 2016-03-20 16:06, Marek wrote:

No właśnie. Po zastosowaniu prostackich środkow technicznych

problem

udowaniania nie istnieje. Bo problem malware, złodziei, wyłudzania

nie

istnieje. Tadaaaam!

Kraje cywilizowane dawno z tym sobie poradziły stosując chargeback dla
transakcji nieautoryzowanych. I żadnych wyrafinowanych środków
technicznych do tego nie trzeba.

One nie są *wyrafinowane*. To kawałek krzemu za $0.1 i kawałek wyświetlacza z klawiaturą za $0.5 + opakowanie za $1. Sprzedawane oczywiście za $100 ale to kwesia dania właściwej osobie po mordzie i rozkręcenia produkcji w chinach.

Więc jaki sens jest wyraĹźanie  konkluzji utopijnych, co ostatnio się Ci
dość często zdarza :)?

Zabawne. Dwa zdania wczesniej wyjasniłem że czasem warto budować świadomość. Natomiast ja jestem niepoprawnym pesymistą. Jedno drugiemu nie przeszkadza.

Dlatego prawo powinno chronić obywateli przed banksterami, bez względu
jak wyrafinowane technicznie metody stosują.

Ale dlaczego nie powinna robić tego technologia? Kiedyś mój znajmy powiedział że jak by uszczelnić prawo to te dziesiątki tysięcy prawników musialo by kopać rowy bo nic innego nie potrafią. Dlatego prawo nigdy nie zostanie uszczelnione, nawet jesli istnieje oczywista możliwość techniczna. I to jest pesymizm ktory prezentuje. Ale jednocześnie niose kaganek oświaty mówiąc: da się inaczej. Nie dziw sie, pesymizm też buduje.

W dniu niedziela, 20 marca 2016 16:20:36 UTC+1 użytkownik Sebastian Biały napisał:

On 2016-03-20 16:06, Marek wrote:
>> No właśnie. Po zastosowaniu prostackich środkow technicznych
> problem
>> udowaniania nie istnieje. Bo problem malw
>> istnieje. Tadaaaam!
> Kraje cywilizowane dawno z tym sobie poradziły stosując chargeback dla
> transakcji nieautoryzowanych. I żadnych wyrafinowanych środków
> technicznych do tego nie trzeba.

One nie są *wyrafinowane*. To kawałek krzemu za $0.1 i kawałek wyświetlacza z klawiaturą za $0.5 + opakowanie za $1. Sprzedawane oczywiście za $100 ale to kwestia dania właściwej osobie po mordzie i rozkręcenia produkcji w chinach.

Jest jeszcze klient. Ja nie chcę żadnego tokena itp- zbyteczny wg mnie gadżet który potrzebny mi byłby żeby zapłacić za zakupy na Allegro. Banki z tokenami omijam łukiem. Hasła sms idealnie mi pasują.

On 2016-03-20 19:40, Kris wrote:
> Hasła sms idealnie mi pasują.

Bardzo dobrze. Polecam jednak uwadze:

https://zaufanatrzeciastrona.pl/post/jak-zlodzieje-okradali-konta-bankowe-klientow-sieci-play/

W dniu niedziela, 20 marca 2016 19:47:55 UTC+1 użytkownik Sebastian Biały napisał:

On 2016-03-20 19:40, Kris wrote:
 > Hasła sms idealnie mi pasują.

Bardzo dobrze. Polecam jednak uwadze:

https://zaufanatrzeciastrona.pl/post/jak-zlodzieje-okradali-konta-bankowe-klientow-sieci-play/

Jeśli ktoś ma jak "Pan Łukasz" na bieżącym rachunku 160tys i do tego jakieś tele play to troche nireprezentatywny przykład.
U mnie co miesiąc jest to ok 3tys na biezące opłaty i zakupy via net i token to tyko dodatkowy  kłopot dla mnie.  Szukać  trzeba, zgubić można;)

On 2016-03-20 21:02, Kris wrote:

Bardzo dobrze. Polecam jednak uwadze:
https://zaufanatrzeciastrona.pl/post/jak-zlodzieje-okradali-konta-bankowe-klientow-sieci-play/

Jeśli ktoś ma jak "Pan Łukasz" na bieżącym rachunku
160tys i do tego jakieś tele play to troche nireprezentatywny przykład.

Pan Łukasz ma taże możliwośc otworzenia lini kredytowej. Zapewne bez możliwosci zablokowania, lub z możliwością odblokowania "kanałem teleinformatycznym". Panów Łukaszów w PL jest od groma. Byc może masz rację, po co przejmować się frajerami mającymi pieniądze na koncie. Co innego mała przerwa w managerskiej pracy w celu przeglądniecia katalogu z jachtami.

token to tyko dodatkowy  kłopot dla mnie.  Szukać  trzeba, zgubić można;)

Super. Nikt nie zmusza do używania tokenów. Kupa banków w PL dalej potrafi zautoryzować duże przelewy za pomocą podpisu rodem ze średniowiecza wspomaganym przypadkową facjatą z masą tapety i zielonym kapeluszem (bo czerwone sa zawsze podejrzane!).

W dniu niedziela, 20 marca 2016 21:13:46 UTC+1 użytkownik Sebastian Biały napisał:

On 2016-03-20 21:02, Kris wrote:
>> Bardzo dobrze. Polecam jednak uwadze:
>> https://zaufanatrzeciastrona.pl/post/jak-zlodzieje-okradali-konta-bankowe-klientow-sieci-play/
> Jeśli ktoś ma jak "Pan Łukasz" na bieżącym rachunku
> 160tys i do tego jakieś tele play to troche nireprezentatywny przykład.

Pan Łukasz ma taże możliwośc otworzenia lini kredytowej. Zapewne bez możliwosci zablokowania, lub z możliwością odblokowania "kanałem teleinformatycznym". Panów Łukaszów w PL jest od groma. Byc może masz rację, po co przejmować się frajerami mającymi pieniądze na koncie. Co innego mała przerwa w managerskiej pracy w celu przeglądniecia katalogu z jachtami.

> token to tyko dodatkowy  kłopot dla mnie.  Szukać  trzeba, zgubić można;)

Super. Nikt nie zmusza do używania tokenów. Kupa banków w PL dalej potrafi zautoryzować duże przelewy za pomocą podpisu rodem ze średniowiecza wspomaganym przypadkową facjatą z masą tapety i zielonym kapeluszem (bo czerwone sa zawsze podejrzane!).

Idiotyczne piszesz o bankowych menagerach idiotach w garniturach- dla mnie idiotami oni by byli gdyby uszczęśliwiali mnie tokenem czy innym tego typu gadżetem da potwierdzenia płatności za zakup worków do odkurzacza za 20zl na alegro.

On 2016-03-20 21:39, Kris wrote:

dla mnie idiotami oni by byli gdyby uszczęśliwiali mnie tokenem

Nie chcę żeby Ciebie uszczęśliwiali. Już jesteś szczęśliwy. Chcę zeby mnie uszczęśliwili. Ale niestety im ze slupków wyszło że szczęśliwy Kris jest tańszy niż nieszczęśliwy Biały. Ot, takie cutting edge of security.

Przełknął bym to gdyby nie stada debili w mediach pieprzyli o tym jak ich bank jest bezpieczniejszy niż sąsiedni, prowadzony przez identycznych debili wprowadzających identyczny poziom security który z powodu mułu jest dobrze ukryty i przestępcy nic o nim nie wiedzą! Ale sprytne!

W dniu niedziela, 20 marca 2016 22:16:09 UTC+1 użytkownik Sebastian Biały napisał:

Ale niestety im ze slupków wyszło że szczęśliwy Kris jest tańszy niż nieszczęśliwy Biały. Ot, takie cutting edge of security.

Wiesz co? może i dobrze że oprócz inżynierów są tam również ludzie potrafiący liczyć. Bo jak zlecisz taka robotę inżynierom to jest duża szansa że zrobią zabezpieczenie ale może to się okazac armata na muchę. I to droga armata.
Trzeba wypośrodkować trochę. Ktoś już Tobie pisał ze banksterzy liczyć potrafią.
Ja np. automatycznie rezygnuje z konta jeśli mi jakieś gowno sprzętowe wcisną. Do moich zastosowań kody sms są idealne i nie widzę potrzeby posiadania tokena. Oczywiście gdybym na rachunku miał poł miliona to może i inaczej bym myślał. Póki co na rachunek podpięty do neta wlewam co miesiąc ok 3tys do płatności internetowych(bo nie korzystam z kart kredytowych) I zabezpieczenie login+haslo + kody sms idealnie mi pasują.
A tak na marginesie dodam ze np. hasła dostępu do mbanku nie zmieniałem od początku(czyli naście lat już chyba)i złotówka z konta mi nie zginęła). Nie korzystam z aplikacji mobilnych, nie robię przelewowo w hotelach restauracjach czy kawiarenkach internetowych.
Na domofonie jest moje imie i nazwisko, mój nr konta jest podany np. na allegro, tym ze w księgach wieczystych moich nieruchomości sa pewnme dane tez się nie martwię;)

Użytkownik "Kris" <kszysztofc@gmail.com> napisał w wiadomości news:c38e6181-2d5a-46c0-812c-8c599a07dc4dgooglegroups.com...

Oczywiście gdybym na rachunku miał poł miliona to może i inaczej bym myślał.

Do innego myślenia skłania też to, że jak się słyszy to włamywacze potrafią (nawet jak na koncie 0) w parę sekund wziąć kredyt i go zutylizować.
P.G.

W dniu wtorek, 22 marca 2016 14:41:34 UTC+1 użytkownik Piotr Gałka napisał:

Użytkownik "Kris" <kszysztofc@gmail.com> napisał w wiadomości news:c38e6181-2d5a-46c0-812c-8c599a07dc4dgooglegroups.com...

> Oczywiście gdybym na rachunku miał poł miliona to może i inaczej bym > myślał.

Do innego myślenia skłania też to, że jak się słyszy to włamywacze potrafią (nawet jak na koncie 0) w parę sekund wziąć kredyt i go zutylizować.
P.G.

Jakieś prasowe bzdury zapewne
Który bank daje możliwość wzięcia kredytu w parę sekund?

Kris <kszysztofc@gmail.com> writes:

W dniu wtorek, 22 marca 2016 14:41:34 UTC+1 użytkownik Piotr Gałka napisał:

Użytkownik "Kris" <kszysztofc@gmail.com> napisał w wiadomości news:c38e6181-2d5a-46c0-812c-8c599a07dc4dgooglegroups.com...

> Oczywiście gdybym na rachunku miał poł miliona to może i inaczej bym > myślał.

Do innego myślenia skłania też to, że jak się słyszy to włamywacze potrafią (nawet jak na koncie 0) w parę sekund wziąć kredyt i go zutylizować.
P.G.

Jakieś prasowe bzdury zapewne
Który bank daje możliwość wzięcia kredytu w parę sekund?

Parę sekund to może nie, ale poniżej 5 min to spokojnie się w mBanku
wyrobisz. Been there, done that.
KJ

--
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
Littering is dumb.
-- Ronald Macdonald

W dniu 2016-03-22 o 17:46, Kamil Jońca pisze:

Kris <kszysztofc@gmail.com> writes:

W dniu wtorek, 22 marca 2016 14:41:34 UTC+1 użytkownik Piotr Gałka napisał:

Użytkownik "Kris" <kszysztofc@gmail.com> napisał w wiadomości
news:c38e6181-2d5a-46c0-812c-8c599a07dc4dgooglegroups.com...

Oczywiście gdybym na rachunku miał poł miliona to może i inaczej bym
myślał.

Do innego myślenia skłania też to, że jak się słyszy to włamywacze potrafią
(nawet jak na koncie 0) w parę sekund wziąć kredyt i go zutylizować.
P.G.

Jakieś prasowe bzdury zapewne
Który bank daje możliwość wzięcia kredytu w parę sekund?

Parę sekund to może nie, ale poniżej 5 min to spokojnie się w mBanku
wyrobisz. Been there, done that.

Co więcej - już takie przypadki pirackiego zakredytowania się zdarzały.

--
Liwiusz

Dnia Tue, 22 Mar 2016 17:46:40 +0100, Kamil Jońca napisał(a):

Do innego myślenia skłania też to, że jak się słyszy to włamywacze potrafią (nawet jak na koncie 0) w parę sekund wziąć kredyt i go zutylizować.
P.G.

Jakieś prasowe bzdury zapewne
Który bank daje możliwość wzięcia kredytu w parę sekund?

Parę sekund to może nie, ale poniżej 5 min to spokojnie się w mBanku
wyrobisz. Been there, done that.

ZTCP to kiedyś w mBanku najpierw trzeba było podpisać specjalną "umowę
ramową", a dopiero potem była możliwość wzięcia "kredytu w 15 minut".

Czy teraz taka umowa nadal jest wymagana, czy naprawdę każdy kto
dysponuje  loginem, hasłem i ewentualnie kodem jednorazowym, jest w
stanie pociągnąć kredyt? (jaki by on nie był, gotówkowy, odnawialny, na
samochĂłd...)

--
Imka

Imka <spamtrapimki@gazeta.pl> writes:

Dnia Tue, 22 Mar 2016 17:46:40 +0100, Kamil Jońca napisał(a):

Do innego myślenia skłania też to, że jak się słyszy to włamywacze potrafią (nawet jak na koncie 0) w parę sekund wziąć kredyt i go zutylizować.
P.G.

Jakieś prasowe bzdury zapewne
Który bank daje możliwość wzięcia kredytu w parę sekund?

Parę sekund to może nie, ale poniżej 5 min to spokojnie się w mBanku
wyrobisz. Been there, done that.

ZTCP to kiedyś w mBanku najpierw trzeba było podpisać specjalną "umowę

1. Mam wrażenie, że teraz jest ona domyślna. Nawet jeśli nie, to masz
może kolejne 5 min. Razem 10.

[...]czy naprawdę każdy kto
dysponuje  loginem, hasłem i ewentualnie kodem jednorazowym, jest w
stanie pociągnąć kredyt? (jaki by on nie był, gotówkowy, odnawialny, na
samochód...)

Tak.
KJ

--
http://wolnelektury.pl/wesprzyj/teraz/
The bomb will never go off.  I speak as an expert in explosives.
-- Admiral William Leahy, U.S. Atomic Bomb Project

W dniu 2016-03-23 o 09:47, Kamil Jońca pisze:

Imka <spamtrapimki@gazeta.pl> writes:

Dnia Tue, 22 Mar 2016 17:46:40 +0100, Kamil Jońca napisał(a):

Do innego myślenia skłania też to, że jak się słyszy to włamywacze potrafią
(nawet jak na koncie 0) w parę sekund wziąć kredyt i go zutylizować.
P.G.

Jakieś prasowe bzdury zapewne
Który bank daje możliwość wzięcia kredytu w parę sekund?

Parę sekund to może nie, ale poniżej 5 min to spokojnie się w mBanku
wyrobisz. Been there, done that.

ZTCP to kiedyś w mBanku najpierw trzeba było podpisać specjalną "umowę

1. Mam wrażenie, że teraz jest ona domyślna. Nawet jeśli nie, to masz
moĹźe kolejne 5 min. Razem 10.

Domyślna zdaje się nie jest, ale mbankowcy dużo zrobili, aby wielu klientów taką umowę ramową podpisało, nawet jak na chwilę obecną kredytu nie potrzebowali.

--
Liwiusz

Użytkownik "Imka" <spamtrapimki@gazeta.pl> napisał w wiadomości news:1eea67x3cmh2e$.10al8w2ul8ruh$.dlg40tude.net...

ZTCP to kiedyś w mBanku najpierw trzeba było podpisać specjalną "umowę
ramową", a dopiero potem była możliwość wzięcia "kredytu w 15 minut".

Umowę ramową podpisałem przy okazji karty kredytowej.
OIDP potem kredyt w rachunku chyba po prostu wyklikałem - zaakceptowałem wiadomość p.t. promocja (specjalnie dla mnie ! :) ) kredyt w rachunku bez prowizji za uruchomienie.
P.G.

On 2016-03-22 14:17, Kris wrote:

W dniu niedziela, 20 marca 2016 22:16:09 UTC+1 użytkownik Sebastian Biały napisał:

Ale niestety im ze slupków wyszło że szczęśliwy Kris
jest tańszy niż nieszczęśliwy Biały. Ot, takie cutting edge of security.

Wiesz co? może i dobrze że oprócz inżynierów są tam również ludzie potrafiący liczyć.

Inzynierowie całkiem sprawnie liczą. Zaryzykuje że znacznie lepiej niż ludzie po bankowości. Są tylko znacznie mniej skurwysyńscy dlatego nie nadają się do bankmowosci.

Bo jak zlecisz taka robotę inżynierom to jest duża szansa
że zrobią zabezpieczenie ale może to się okazac armata na muchę. I to droga armata.

Zamiast tego debilomanagerzy wpadli na pomysł zabezpiecznia konta smsami na dziurawych systemach android. Wiec wyszedł pistolet na wodę.

Trzeba wypośrodkować trochę.

Ale to nie jest wyposrodkowane. To jest tylko tanie. Sam napisaleś że potrafią liczyć. Potrafią *TYLKO* liczyć.

Ja np. automatycznie rezygnuje z konta jeśli mi jakieś gowno
sprzętowe wcisną.

To rezygnuj. Ja potrzebuje token na wniosek. Jestem przekonany że większość społeczeństwa nie będzie w stanie pojąć co to jest i do czego jest. I co mnie to obchodzi że reszta ludzi nie ma pojęcia o czymkolwiek? Dlaczego muszę cierpieć równanie do mułu?

Do moich zastosowań kody sms są idealne

Były by do moich równiez idealne gdyby nie fakt że trzeba ich uzywać na Nokii 3310 bo to niezbędny warunek odporności na malware.

Oczywiście gdybym na rachunku miał poł miliona to może i inaczej bym myślał.

No widzisz. A jak masz 20mln to też dostaniesz smsa. Bo, panie, komu te tokeny potrzebne?

A tak na marginesie dodam ze np. hasła dostępu do mbanku nie zmieniałem
od początku(czyli naście lat już chyba)i złotówka z konta mi nie zginęła).

Ja zaś od kilkudziesięciu lat chodzę w półbutach i jeszcze noga mi się nie zwichneła. Przepraszam za tą dygresję, ale skoro pozwoliłeś sobie na argument od rzeczy to czemu ja nie miałbym.

Nie korzystam z aplikacji mobilnych, nie robię przelewowo w hotelach
restauracjach czy kawiarenkach internetowych.

Czyli ... jesteś BEZPIECZNY. Brawo. Nikt nigdy nie da rady zainstalować Ci malware na kompie, w końcu nie ściągasz pornoli. Tylko kupne. Pełna higiena. Tak trzymać. Jeszcze trzeba czapeczkę z folii aluminiowej na głowę wsadzić, bo ONI mają metody.

Na domofonie jest moje imie i nazwisko, mój nr konta jest
podany np. na allegro, tym ze w księgach wieczystych moich nieruchomości
sa pewnme dane tez się nie martwię;)

No ba. Ja podałem kiedyś na grupie numer buta. Tez sie nie martwie.

W dniu 23.03.2016 o 22:08, Sebastian Biały pisze:

Inzynierowie całkiem sprawnie liczą. Zaryzykuje że znacznie lepiej niż
ludzie po bankowości. Są tylko znacznie mniej skurwysyńscy dlatego nie
nadają się do bankmowosci.

Nie przeczę, że jesteś świetnym inżynierem, ale nie sądzę, byś odniósł sukcesy w zarządzaniu bankiem ;)

Ale nie o tym chciałem dyskutować. Chciałem tylko wspomnieć o zabezpieczeniu, które nie występuje na rynku polskim, a które jest oferowane przez AIB w Irlandii - jako jedyna opcja:

https://www.aib.ie/servlet/Satellite?c=SC_Content&cid=1291806113056&pagename=SecurityCentre%2Fsc_main&section=S003

Coś jak token, a dodatkowo zabezpieczony koniecznością... wsadzenia do niego karty i użycia jej pinu.

Dla jednym bezpieczne, dla drugich upierdliwe jak cholera (nosić to przy sobie by zrobić przelew?) - cóż, albo coś jest wygodne albo bezpieczne. Albo godzimy się na kompromis. I godzimy się na związane z nim straty.

I wcale nie zdziwię się, gdy wyrok zostanie utrzymany w apelacji. Jest naprawdę solidnie uzasadniony, a że tu niektórzy zdążyli już zwyzywać sędzię? Cóż, w Polsce wszyscy znają się na prawie...
i na zarządzaniu bankiem ;)

On 2016-03-23 22:30, gral wrote:

Dla jednym bezpieczne, dla drugich upierdliwe jak cholera (nosić to przy
sobie by zrobić przelew?)

Nikt tutaj nie napisał o tym że przelewy za 200zł można robić bez tokena? Przeciez to oczywiste. Robisz przelew na 5tyś - autoryzuj. Robisz za 50zł - a zrób se ze 4 dziennie bez i już.

Problemem nie jest uzywanie tego codziennie. Problemem jest fakt że banki sa na tyle tępe że nie wychwytuja anomalii typu kredycik na 50k i wylanie go na cypr.

i na zarządzaniu bankiem ;)

Na tym sie nikt nie zna. To po prostu dryfowanie i omijanie anomalii w celu utrzymania zdolnosci kredytowej na jachty.

Sebastian Biały <heby@poczta.onet.pl> writes:

One nie są *wyrafinowane*. To kawałek krzemu za $0.1 i kawałek
wyświetlacza z klawiaturą za $0.5 + opakowanie za $1. Sprzedawane
oczywiście za $100 ale to kwesia dania właściwej osobie po mordzie i
rozkręcenia produkcji w chinach.

Bez przesady, tak "na oko" koszt produkcji urządzenia z kamerą
i klawiaturą ekranową to przynajmniej z $15, przy seryjnej produkcji.
--
Krzysztof Hałasa

On 2016-03-20 16:35, Krzysztof Halasa wrote:

One nie są *wyrafinowane*. To kawałek krzemu za $0.1 i kawałek
wyświetlacza z klawiaturą za $0.5 + opakowanie za $1. Sprzedawane
oczywiście za $100 ale to kwesia dania właściwej osobie po mordzie i
rozkręcenia produkcji w chinach.

Bez przesady, tak "na oko" koszt produkcji urządzenia z kamerą
i klawiaturą ekranową to przynajmniej z $15, przy seryjnej produkcji.

Mamy inne i raczej wirtualne doswiadczenia. Ale token nie przekracza poziomem komplikacji zabawkę chińską grającą melodyjki za $0.5. Nie bardzo widzę powód dla którego mialo by to być specjalnie lepiej wykonane niż chiński szit. Ostatecznie dla jakiś debili w garniturach przygotuje się wersję pakowaną w szczotkowane aluminium z identycznym wsadem.

Kto mówi o klawiaturze ekranowej? To zwykła pojemnosciowa już nie wystarczy? Kosz produkcji oscyluje w okolicy $0 bo jest częścią obudowy. Jest wieczna bo nie zawiera mechaniki. Skąd się wzieło $15 przy produkcji idacej w milionach sztuk?

Sebastian Biały <heby@poczta.onet.pl> writes:

Mamy inne i raczej wirtualne doswiadczenia.

Elektroniką zajmuję się od kilkudziesięciu lat (śmiesznie to brzmi ale
formalnie jest prawdą) więc możesz traktować to, co napisałem, jako
niewirtualne.

Ale token nie przekracza
poziomem komplikacji zabawkę chińską grającą melodyjki za $0.5. Nie
bardzo widzę powód dla którego mialo by to być specjalnie lepiej
wykonane niż chiński szit. Ostatecznie dla jakiś debili w garniturach
przygotuje się wersję pakowaną w szczotkowane aluminium z identycznym
wsadem.

Kto mówi o klawiaturze ekranowej? To zwykła pojemnosciowa już nie
wystarczy? Kosz produkcji oscyluje w okolicy $0 bo jest częścią
obudowy. Jest wieczna bo nie zawiera mechaniki.

W sensie "sensora" z jakimś FETem (zabezpieczonym diodami) na wejściu,
tak jak to kiedyś było robione w sprzęcie np. RTV?
Niepopularne i mało pewne rozwiązanie. Gumowa klawiatura rezystancyjna
kosztuje poniĹźej dolara i (dobrze zrobiona, z uszczelnieniami) jest duĹźo
lepsza (chociaĹź nie idealna).

Ale klawiatura to drobiazg. Potrzebny jest ekran, który wyświetli
informacje nt. zlecanego właśnie np. przelewu, oraz kanał, którym token
dowie się co ma wyświetlić. To ostatnie można zrobić np. przez USB -
taniej, ale wprowadzając poważne ograniczenia w funkcjonalności (np.
nie będzie działać tam, gdzie nie ma dostępu do USB, albo gdzie nie ma
właściwego sterownika itp). Lepszym rozwiązaniem jest kamera, która
obserwuje obraz wyświetlony na ekranie (typowo kod QR).

Nie można tego pominąć, jeśli chcemy, by to było bezpieczne.

W sumie, potrzebujesz:
- ekranu do wyświetlenia informacji, w dzisiejszych czas pewnie jakiegoś
  IPS 320x200 3" MIPI (moĹźe SPI?)
- kamery, pewnie jakieś 640x480, MIPI albo USB, cała kamera wielkości
  np. 3mm x 3mm.
- w celu zmniejszenia wielkości użyłbym jednak ekranu dotykowego, może
  być rezystancyjny
- no i musi tym sterować procesor, do którego podepniesz te peryferia.
- bateria itd.

Skąd się wzieło $15
przy produkcji idacej w milionach sztuk?

Taka skala produkcji (w kontekście konkretnej serii konkretnego
producenta) jest mało realna, ale też niepotrzebna, bo przy o rząd
wielkości mniejszych seriach koszty są praktycznie identyczne.

Opowieści jak to można zrobić za $0.5 można między banki włożyć.

Przy czym akurat dla mnie cena $15 nie jest Ĺźadnym problemem. Ale
domyślam się, że dla banku to zbyt drogo (pomijając klientów firmowych
itp).
--
Krzysztof Hałasa

Użytkownik "Krzysztof Halasa" <khc@pm.waw.pl> napisał w wiadomości news:m31t73cunv.fsfpm.waw.pl...

To zwykła pojemnosciowa już nie
wystarczy? Kosz produkcji oscyluje w okolicy $0 bo jest częścią
obudowy. Jest wieczna bo nie zawiera mechaniki.

W sensie "sensora" z jakimś FETem (zabezpieczonym diodami) na wejściu,
tak jak to kiedyś było robione w sprzęcie np. RTV?

Nie jesteś na bieżąco.
P.G.

Piotr Gałka <piotr.galka@cutthismicromade.pl> writes:

W sensie "sensora" z jakimś FETem (zabezpieczonym diodami) na wejściu,
tak jak to kiedyś było robione w sprzęcie np. RTV?

Nie jesteś na bieżąco.

Możliwe, nie można zresztą być na bieżąco ze wszystkim. Niestety "zwykła
pojemnościowa" nie określa żadnego konkretnego sprzętu w sposób
jednoznaczny.

Np. ja używam "zwykłych pojemnościowych" :-) klawiatur ekranowych,
ale ich koszt jest nieco inny niĹź < $0.5.
--
Krzysztof Hałasa

On 2016-03-22 17:32, Krzysztof Halasa wrote:

Np. ja używam "zwykłych pojemnościowych" :-) klawiatur ekranowych,
ale ich koszt jest nieco inny niż < $0.5.

Więc zainteresuj sie faktem że od groma mikrokontrolerów implementuje różnego rodzaju TouchWhatever za friko. Innymi słowy dotarliśmy do momentu kiedy klawiatura kosztuje tyle co napylenie grafitu na plastik i jest niezniszczalna.

Sebastian Biały <heby@poczta.onet.pl> writes:

Więc zainteresuj sie faktem że od groma mikrokontrolerów implementuje
różnego rodzaju TouchWhatever za friko. Innymi słowy dotarliśmy do
momentu kiedy klawiatura kosztuje tyle co napylenie grafitu na plastik
i jest niezniszczalna.

Kiedyś takie rzeczy kosztowały tyle, co dodatkowy mały scalaczek.

Tak czy owak za $0.5 takiego tokena nie da się obecnie wykonać. Za ok.
$0.5 to obecnie banki kupują "zepsute" pendrivy 8GB, takie z chińskim
kontrolerem i pamięcią NAND flash z wy-XXX-wanym logo producenta
("zepsute" w sensie: potrzebne jest zapuszczenie programu
inicjalizującego pendrive, a to zbyt długo trwa).

Tak czy owak, gdyby banki na poważnie brały kwestie bezpieczeństwa, to
koszt tokena nie byłby problemem. Możliwe jednak, że jeśli banki nie
będą mogły przerzucać na klientów odpowiedzialności za takie fraudy, to
takie tokeny zaczną być używane (trzeba też zauważyć, że to przerzucanie
odpowiedzialności nie jest uczciwe, gdyż to banki wybierają mechanizm
autoryzacji, klient nie ma tu wiele do powiedzenia).

Zobaczymy.
--
Krzysztof Hałasa

Marek <fake@fakeemail.com> writes:

Kraje cywilizowane dawno z tym sobie poradziły stosując chargeback dla
transakcji nieautoryzowanych. I żadnych wyrafinowanych środków
technicznych do tego nie trzeba.

Chargeback nie rozwiązuje żadnego problemu, przerzuca go tylko w inne
miejsce.
--
Krzysztof Hałasa

On Sun, 20 Mar 2016 16:33:31 +0100, Krzysztof Halasa <khc@pm.waw.pl> wrote:

Chargeback nie rozwiązuje żadnego problemu, przerzuca go tylko w

inne

miejsce.

ZaleĹźy z jakiego punktu widzenia  ropatrujemy problem. Zakres tej konkretnej dyskusji dotyczy wyłącznie z pkt. widzenia klienta i to mi wystarcza..

--
Marek

W dniu 2016-03-20 o 17:01, Marek pisze:

On Sun, 20 Mar 2016 16:33:31 +0100, Krzysztof Halasa <khc@pm.waw.pl> wrote:

Chargeback nie rozwiązuje żadnego problemu, przerzuca go tylko w

inne

miejsce.

ZaleĹźy z jakiego punktu widzenia  ropatrujemy problem. Zakres tej
konkretnej dyskusji dotyczy wyłącznie z pkt. widzenia klienta i to mi
wystarcza..

No, rzeczywiście to byłby pomysł godzien Nobla, jeśli wymyślono by sposób zwrotu kasy z pustego konta.

--
Liwiusz

W dniu 2016-03-20 o 16:33, Krzysztof Halasa pisze:

Marek <fake@fakeemail.com> writes:

Kraje cywilizowane dawno z tym sobie poradziły stosując chargeback dla
transakcji nieautoryzowanych. I żadnych wyrafinowanych środków
technicznych do tego nie trzeba.

Chargeback nie rozwiązuje żadnego problemu, przerzuca go tylko w inne
miejsce.

Pomijając już fakt, że chargeback działa, bo "na bogatego trafiło i ma z czego zwracać". Pieniądze przelane na słupa i wypłacone - do chargebacku się już nie nadają, bo nie ma czego stornować.

--
Liwiusz

On Mon, 21 Mar 2016 11:51:24 +0100, Liwiusz <lmalin@bez.tego.poczta.onet.pl> wrote:

Pomijając już fakt, że chargeback działa, bo "na bogatego trafiło i

ma z

czego zwracać". Pieniądze przelane na słupa i wypłacone - do

chargebacku

się już nie nadają, bo nie ma czego stornować.

Zwrot transakcji nieautoryzwanych wg aktualnych przepisĂłw  nie jest z Ĺźadnego konta t.j. one tego nie precyzują bo nie ma takiej potrzeby, działa tu analogia jak w naprawie szkody. Zwrot ma dokonać bank, to jego problem z jakich środkĂłw to pokryje.

--
Marek

W dniu 2016-03-21 o 14:32, Marek pisze:

On Mon, 21 Mar 2016 11:51:24 +0100, Liwiusz
<lmalin@bez.tego.poczta.onet.pl> wrote:

Pomijając już fakt, że chargeback działa, bo "na bogatego trafiło i

ma z

czego zwracać". Pieniądze przelane na słupa i wypłacone - do

chargebacku

się już nie nadają, bo nie ma czego stornować.

Zwrot transakcji nieautoryzwanych wg aktualnych przepisĂłw  nie jest z
żadnego konta t.j. one tego nie precyzują bo nie ma takiej potrzeby,
działa tu analogia jak w naprawie szkody. Zwrot ma dokonać bank, to jego
problem z jakich środków to pokryje.

To nie jest analogiczne.
W karcianych chargebackach bank potrąca sobie zwracaną sumę od sprzedawcy, więc można uznać, że to nie bank, tylko sprzedawca zwraca za transakcję, którą dokonał złodziej, albo która była przez niego źle zrealizowana - w obu przypadkach jest to wiadome ryzyko sprzedawcy.

--
Liwiusz

On Mon, 21 Mar 2016 14:44:40 +0100, Liwiusz <lmalin@bez.tego.poczta.onet.pl> wrote:

To nie jest analogiczne.
W karcianych chargebackach bank potrąca sobie zwracaną sumę od sprzedawcy, więc można uznać, że to nie bank, tylko sprzedawca

zwraca za

transakcję, którą dokonał złodziej, albo która była przez niego źle zrealizowana - w obu przypadkach jest to wiadome ryzyko sprzedawcy.

Ale tematyczne orzeczenie nie dotyczy kartowego chargebacka, w tym przypadku ( zakładając, że sprawa nie potoczy się inaczej) bank będzie musiał zwrócić kasę poszkodowanej i założę się, że nie gdzie to kasa odzyskana od złodzieja.

--
Marek

Marek <fake@fakeemail.com> writes:

Zwrot transakcji nieautoryzwanych wg aktualnych przepisĂłw  nie jest z
żadnego konta t.j. one tego nie precyzują bo nie ma takiej potrzeby,
działa tu analogia jak w naprawie szkody. Zwrot ma dokonać bank, to
jego problem z jakich środków to pokryje.

Rozumowanie na podobnym poziomie co "wydrukujmy sobie tyle pieniędzy, by
każdy miał ich do woli" :-(
--
Krzysztof Hałasa

On Mon, 21 Mar 2016 23:05:22 +0100, Krzysztof Halasa <khc@pm.waw.pl> wrote:

Rozumowanie na podobnym poziomie co "wydrukujmy sobie tyle

pieniędzy, by

każdy miał ich do woli" :-(

Taa proponuję zatem pĂłjść Twoim tokiem rozumowania u anulować kary, mandaty, nakazy wyrĂłwnania szkody a moĹźe nawet i podatki tym, ktĂłrych na to nie  stać bo nie mają z czego zapłacić.

--
Marek

Marek <fake@fakeemail.com> writes:

Taa proponuję zatem pójść Twoim tokiem rozumowania u anulować kary,
mandaty, nakazy wyrĂłwnania szkody a moĹźe nawet i podatki tym, ktĂłrych
na to nie  stać bo nie mają z czego zapłacić.

Przyznaję że mnie to nie zaskoczyło.
--
Krzysztof Hałasa

Krzysztof Halasa napisał(a) w wiadomości: ...

Marek <fake@fakeemail.com> writes:

Taa proponuję zatem pójść Twoim tokiem rozumowania u anulować kary,
mandaty, nakazy wyrównania szkody a może nawet i podatki tym, których
na to nie  stać bo nie mają z czego zapłacić.

Przyznaję że mnie to nie zaskoczyło.

Coraz więcej ludzi nie może zrozumieć, że za kradzież ma odpowiadać
złodziej a nie przypadkowy frajer, którego akurat wymieniono w jakimś
skleconym po pijaku przepisie prawa (chyba "lewa" raczej).
Oczywiście frajer jeżeli będzie miał możliwości będzie się bronił -
bank zapłaci pieniędzmi np. niejakiego Marka w taki czy inny sposób
ściągniętymi.

Arek

Marek napisał(a) w wiadomości: ...

On Sun, 20 Mar 2016 15:29:54 +0100, Sebastian
Biały<heby@poczta.onet.pl> wrote:

No właśnie. Po zastosowaniu prostackich środkow technicznych

problem

udowaniania nie istnieje. Bo problem malware, złodziei, wyłudzania

nie

istnieje. Tadaaaam!

Kraje cywilizowane dawno z tym sobie poradziły stosując chargeback
dla transakcji nieautoryzowanych. I żadnych wyrafinowanych środków
technicznych do tego nie trzeba.

Płacą za złodziei, "Cywilizacja". Jakież to budujące moralnie...
Tzn. płacą w efekcie inni klienci banków - ci bardziej rozgarnięci.

Bicie piany w tym wypadku jest zasadniczo istotne: ludzie nie mają
pojęcia że ich banki wcale nie stosują zaawansowanych srodkow
technicznych a jedynie kupe gówna nazywaną security a tak naprawdę
przerzucają co moga ze swojej odpowiedzialności na klienta w posob
często ordynarny. Być może ta świadomość wygeneruje kiedyś zwrot w
kierunku prawdziwego security. Ale nie, nie jestem aż tak głupi

żeby

zakładać że kiedyś debilomanagerzy zostaną zwolnienie z pracy, więc

to

utopia.

Co to jest "prawdziwe security"? Jakiś absolut?
Tak, można teoretycznie zaprojektować system dość bezpieczny, ale
drogi i niewygodny (jak na dzisiejsze czasy wygodnictwa).

Więc jaki sens jest wyrażanie  konkluzji utopijnych, co ostatnio się
Ci dość często zdarza :)? Nie, nie zostaną zwolnieni z pracy i będą
za wszelką cenę próbować przy każdej okazji przerzucać
odpowiedzialność na klienta.

Dlatego prawo powinno chronić obywateli przed banksterami, bez
względu jak wyrafinowane technicznie metody stosują.

1. Nie ma znaczenia jak "zaawansowane" bedą techniki zabezpieczania.
Na końcu jest klient i jak go jakiś Kevin Mitnick przekona żeby podał
co trzeba to poda (zgodnie z tytułem ksiązki: "Łamałem ludzi, nie hasła").
2. O ile klient może jakoś przekonać sąd, że to nie on, to bank nie ma
żadnej możliwości udowodnić, ze to klient. Kwestia niskiej asertywności
klientów.
3. To państwo zachęca, a czasem już zmusza do korzystania z usług
bankowych. Zmusza do ryzyka, więc niech odpowiada... Oczywiście
po złodzieju, który w przypadku złapania powinien w kazamatach
zasuwać aż spłaci z odsetkami.

W skrócie: sąd, być może  postraszony atmosferą obecnej władzy
uznał, że banki można okradać. Podac znajomemu co trzeba a samemu
twierdzić, że to nie ja autoryzowałem.
Podobne przypadki z kartami już były. To ma być "cywilizacja"?

Jeżeli przegram w trzy karty to kto ma oddawać kasę? Bank z którego
te akurat banknoty wypłaciłem? A może pracodawca, który tego dnia
nimi zapłacił?

Arek

On 2016-03-23 21:35, Arek wrote:

Co to jest "prawdziwe security"? Jakiś absolut?

Coś so korzysta ze zdobyczy techniki która nie dośc że jest odporna na naciski polityczne to jeszcze odporna na debili. To nie oznacza że jest to perfekcyjna metoda. Ona jest tylko o rzędy wielkości bardziej skuteczna niż tępe panienki na infolini.

Tak, można teoretycznie zaprojektować system dość bezpieczny, ale
drogi i niewygodny (jak na dzisiejsze czasy wygodnictwa).

Nie jest to prawda. System chargeback jest bardzo drogi bo wymaga utrzymywania masy ludzi. Jedyną jego zaletą jest fakt że placa frajerzy a nie banki bo banki opłaty sobie zrzucą na ludzi. Jaka to obiektywnie zaleta sam widzisz. Kiedys w TV była wypowiedź jednego debilomanagera który powiedział "bank nie może być stratny" tlumacząc dlaczego bank pozwał wlaściciela konta o to żeby zwrócił to co złodziej ukradł bankowi.

1. Nie ma znaczenia jak "zaawansowane" bedą techniki zabezpieczania.
Na końcu jest klient i jak go jakiś Kevin Mitnick przekona żeby podał
co trzeba to poda (zgodnie z tytułem ksiązki: "Łamałem ludzi, nie hasła").

Mozna te przypadki eliminować. Token kryptograficzny skutecznie uniemożliwia dostęp do konta bez fizycznej obecności dongla i właściciela. Czyli eliminuje praktycznie wszystkie spółczesne ataki informatyczne na moja kasę.

2. O ile klient może jakoś przekonać sąd, że to nie on, to bank nie ma
żadnej możliwości udowodnić, ze to klient. Kwestia niskiej asertywności
klientów.

Juz napisałem: są osoby których czas jest gówno wart i mogą go sobie spędzać w sądach do woli udowadniając co tylko chcą, być może skutecznie.

3. To państwo zachęca, a czasem już zmusza do korzystania z usług
bankowych. Zmusza do ryzyka, więc niech odpowiada... Oczywiście
po złodzieju, który w przypadku złapania powinien w kazamatach
zasuwać aż spłaci z odsetkami.

No ba, a Państwo posiada pieniądze z plantacji drzew gotowkowych. Tak, niech państwo płaci wszystko, za gówno robione przez banki i za 500 plus. To kwestia posadzenia gęściej drzewek z dwustekami.

Jeżeli przegram w trzy karty to kto ma oddawać kasę? Bank z którego
te akurat banknoty wypłaciłem? A może pracodawca, który tego dnia
nimi zapłacił?

Cos mi sie wydaje że to wcale nie jest odlegle od idei chargeback.

W dniu 20-03-16 o 13:42, Sebastian Biały pisze:

Okiem informatyka: to wynik dziadostwa robionego przez banki. Zwóroc
uwagę że banki robią wszystko aby "ułatwić" korzystanie z bankowości. Od
zakładania kont przelewem za grosz przez używanie absurdalnie łatwych do
złamania zabezpieczeń informatycznych.

Od wielu oszustw internetowych uchroniłoby stosowanie prostych środków przez banki. Po pierwsze identyfikacji osoby zakładającej rachunek na podstawie osobistej ich obecności w banku i zbadania dokumentów. Po drugie weryfikacja nazw na które są robione przelewy z nazwą właściciela rachunku.

Oczywiście matematyka i informatyka mają skuteczne metody zabezpieczanie
transakcji (np. tokeny sprzętowe). Problem w tym że znaczna częśc
społeczeństwa to idioci a znaczna część managerów w bankach to debile.
Efektem czego systemy zabezpieczeń banków bazują na poziomie mułu czyli
zakładają że system operacyjny usera jest bezpieczny oraz że imie
panieńskie babki jest absolutnie nie do podsłuchania podane 40 razy
przez telefon.

Dodatkowym problemem jest to, że proste telefony zostały teraz wyparte przez różne smartfony podatne tak samo, jak komputery na złośliwe oprogramowanie.

, a obydwie omawiane sytuacje (dziura w

bezpieczeństwie i zainstalowanie złośliwego oprogramowania) to przypadki
bardzo proste do przewidzenia

Nie da się w sposób oczywisty stwierdzić czy twoj komputer posiada
malware. Nawet zaawansowany informatyk nie jest w stanie tego
stwierdzić.

Te Malware są wymyślane co chwilę jest coś nowego. Programy antywirusowe działają zawsze z pewnym opóźnieniem.

Natomiast są banki - nie będę tu ich reklamował - które mają odpowiednie procedury powodujące reakcję na nietypowe działania klienta.

On Sun, 20 Mar 2016 11:03:35 +0100, Rafal Jankowski <jankowsr@oceanic.wsisiz.edu.pl> wrote:

-po pierwsze taka sytuacja nie miała miejsca (przynajmniej żadna ze

stron

tego nawet nie próbowała sugerować)
-po drugie nikt nie powiedział , że bank ponosi odpowiedzialność za dziury w sofcie po stronie użytkownika

Ale jest wyraźnie powiedziane w ustawie: transakcje autoryzowane to te, które robi użytkownik-strona umowy a nie ktoś inny.
Proste. Skoro fizycznie transakcji dokonuje osoba trzecia nieuprawniona mimo, Ĺźe narzędziami uĹźytkownika (tutaj hasłem czy tanem.wykradniętymi podstępnie) to nie jest to transakcja autoryzowana. Logiczne, prawda? Oczywiście to jest problem dla banku, ktĂłry nie jest w stanie odróşnic fizycznego uĹźytkownika dokonującego transakcji, albo gorzej: inaczej rozumie  "autoryzację" niĹź  zakłada to ustawa. Ale to niestety jest juĹź ryzyko działalności banku. Dlatego  w krajach bardziej rozwiniętych  juĹź kilkadziesiąt lat temu przy wprowadzaniu takich instrumentĂłw płatniczych jak karty kredytowe od razu wprowadzono chargeback. I jest w tych krajach świętością honorowaną bez zbędnej dyskusji z klientem.
Ale oczywiście to dotyczy krajów cywilizacyjne rozwiniętych, gdzie ryzyko nadużyć możliwych z tego tytułu jest (lub było) marginalne.

--
Marek

On Sun, 20 Mar 2016, Marek wrote:

On Sun, 20 Mar 2016 11:03:35 +0100, Rafal Jankowski <jankowsr@oceanic.wsisiz.edu.pl> wrote:

 -po pierwsze taka sytuacja nie miała miejsca (przynajmniej Ĺźadna ze

stron

 tego nawet nie prĂłbowała sugerować)
 -po drugie nikt nie powiedział , Ĺźe bank ponosi odpowiedzialność za dziury
 w sofcie po stronie uĹźytkownika

Ale jest wyraźnie powiedziane w ustawie: transakcje autoryzowane to te, które robi użytkownik-strona umowy a nie ktoś inny.
Proste. Skoro fizycznie transakcji dokonuje osoba trzecia nieuprawniona mimo, że narzędziami użytkownika (tutaj hasłem czy tanem.wykradniętymi podstępnie) to nie jest to transakcja autoryzowana. Logiczne, prawda?

Ani proste ani nie logiczne, bo wtedy zbędny byłby art 42 ustawy na którą się powołujesz.

On Sun, 20 Mar 2016 13:49:33 +0100, Rafal Jankowski <jankowsr@oceanic.wsisiz.edu.pl> wrote:

Ani proste ani nie logiczne, bo wtedy zbędny byłby art 42 ustawy na

którą

się powołujesz.

Dlaczego? On jest jasny i precyzyjny.

--
Marek

On Sun, 20 Mar 2016, Marek wrote:

On Sun, 20 Mar 2016 13:49:33 +0100, Rafal Jankowski <jankowsr@oceanic.wsisiz.edu.pl> wrote:

 Ani proste ani nie logiczne, bo wtedy zbędny byłby art 42 ustawy na

którą

 się powołujesz.

Dlaczego? On jest jasny i precyzyjny.

A art. 42 nie jest?

On Sun, 20 Mar 2016 14:43:52 +0100, Rafal Jankowski <jankowsr@oceanic.wsisiz.edu.pl> wrote:

A art. 42 nie jest?

Oczywiście, że jest. Nie rozumiem do czego pijesz.

--
Marek

On Sun, 20 Mar 2016, Marek wrote:

On Sun, 20 Mar 2016 14:43:52 +0100, Rafal Jankowski <jankowsr@oceanic.wsisiz.edu.pl> wrote:

 A art. 42 nie jest?

Oczywiście, że jest. Nie rozumiem do czego pijesz.

Jak rozumiem to do czego się odnosisz to definicja tego kto to jest płatnik i co to jest zlecenie (art 2 pkt 22 i 36). Tylko po pierwsze to nie zdejmuje z klienta obowiązku nieudostępniania danych autoryzacyjnych, bo po co wogóle byłby ten artykuł 42? Po drugie gdyby nawet było to takie "proste i logiczne" jak piszesz to użytkownik nie miałby dokładnie żadnego interesu w pilnowaniu dostępu do swojego konta, bo zawsze można zgłosić chargeback i wtedy całe to uzasadnienie wyroku powinno zawierać max. trzy zdania odnosząc się do tej właśnie części ustawy. Podobnie w sumie działają karty kredytowe, które z technicznego punktu widzenia nie mają właściwie żadnych zabezpieczeń tylko weź pod uwagę jakie są prowizje za ich korzystanie. To chyba coś ok 1-2% za transakcję karcianą. Nie wiem czy byśmy chcieli tyle płacić za przelewy.

On Sun, 20 Mar 2016 19:37:04 +0100, Rafal Jankowski <jankowsr@oceanic.wsisiz.edu.pl> wrote:

Jak rozumiem to do czego się odnosisz to definicja tego kto to jest płatnik i co to jest zlecenie (art 2 pkt 22 i 36). Tylko po

pierwsze to

nie zdejmuje z klienta obowiązku nieudostępniania danych

autoryzacyjnych, Zgoda, ale udostępnienie (świadome) byłoby już złamaniem umowy bank-klient, pewnie trudne do obrony ale zapewne z pkt. widzenia sądu nadal nie spełniające definicji autoryzacji na jaką powołuje się sąd w omawianym orzeczeniu.

"proste i logiczne" jak piszesz to użytkownik nie miałby dokładnie

Ĺźadnego

interesu w pilnowaniu dostępu do swojego konta,

Ależ to już by można spokojnie podciągnąć pod rażące niedbalstwo, brudzo trudne do obrony.

Podobnie w sumie działają karty kredytowe, które z technicznego punktu widzenia nie

mają

właściwie żadnych zabezpieczeń tylko weź pod uwagę jakie są

prowizje za

ich korzystanie. To chyba coś ok 1-2% za transakcję karcianą. Nie

wiem czy

byśmy chcieli tyle płacić za przelewy.

Co wcale nie oznacza, że nie nastąpi. W bardziej rozwiniętych krajach nie ma takiej swobody w dystępności i różnorodnošci narzędzi płatniczych jak to jest u nas.

--
Marek

On Sun, 20 Mar 2016, Marek wrote:

 "proste i logiczne" jak piszesz to uĹźytkownik nie miałby dokładnie

Ĺźadnego

 interesu w pilnowaniu dostępu do swojego konta,

Ależ to już by można spokojnie podciągnąć pod rażące niedbalstwo, brudzo trudne do obrony.

I tu właśnie wracamy do początku dyskusji. Czy zainstalowanie na swoim komputerze malware (nie polegające tak jak pisze sąd w uzasadnieniu na żadne zdjęcie tylko na zignorowaniu serii komunikatów ostrzegających co się robi) jest rażące czy nie. Sąd stwierdził, że nie, ale to jest na tyle typowy przypadek że powinien być jasno określony w prawie a nie podlegać ocenie sądu.

Marek <fake@fakeemail.com> writes:

Oczywiście to jest problem dla banku, który nie jest w stanie odróżnic
fizycznego użytkownika dokonującego transakcji, albo gorzej: inaczej
rozumie  "autoryzację" niĹź  zakłada to ustawa. Ale to niestety jest
już ryzyko działalności banku.

Bank autoryzację rozumie tak samo, ale nie jest w stanie na 100%
stwierdzić, czy rzeczywiście taką uzyskał. To jest ryzyko, które
z bankami jest związane "od zawsze". Natomiast faktycznie a) to bank
jest profesjonalistą, oraz b) to bank decyduje to sposobie weryfikacji
i autoryzacji. Jeśli metody stosowane przez bank nie są wystarczająco
bezpieczne (bo że nie są całkowie bezpieczne to chyba jasne), to bank
może je zmienić, np. (niewielkim kosztem) dając każdemu klientowi
np. sprytny token (taki weryfikujący w prosty sposób tożsamość klienta,
pobierający treść zlecenia płatniczego itd).

(Chwilowo) nie opłaca się, ale to nie wina klienta.
--
Krzysztof Hałasa

W dniu 2016-03-20 o 00:22, Marek pisze:

http://orzeczenia.lodz.sr.gov.pl/content/$N/152510100000603_II_C_000383_2015_Uz_2015-09-28_001


W skrócie, poszkodowana straciła kasę (19k) z konta podając swoje dane
autoryzacyjne na podstawionej stronie udającej oryginalną stronę banku.

Właściwy kierunek, klient banku jest praktycznie bezbronny wobec
zaawansowanych ataków, za to bank ma potencjalne możliwości
by je udaremniać. Oczywiście utrzymanie odpowiednich systemów
zabezpieczeń kosztuje, ale jeśli podobne orzeczenia staną się regułą
to w końcu banki zaczną ich używać.

Użytkownik "MarcinF"  napisał w wiadomości grup dyskusyjnych:ncnapg$i7b$1@node1.news.atman.pl...

W dniu 2016-03-20 o 00:22, Marek pisze:

http://orzeczenia.lodz.sr.gov.pl/content/$N/152510100000603_II_C_000383_2015_Uz_2015-09-28_001

W skrócie, poszkodowana straciła kasę (19k) z konta podając swoje dane
autoryzacyjne na podstawionej stronie udającej oryginalną stronę banku.

Właściwy kierunek, klient banku jest praktycznie bezbronny wobec
zaawansowanych ataków, za to bank ma potencjalne możliwości
by je udaremniać.

Jakie?

Oczywiście utrzymanie odpowiednich systemów
zabezpieczeń kosztuje, ale jeśli podobne orzeczenia staną się regułą
to w końcu banki zaczną ich używać.

Jesteś gotów zapłacić stówkę więcej rocznie?

W dniu 2016-03-21 o 08:50, Ghost pisze:

Jakie?

Systemy pozwalające wykrywać symptomy podszycia się pod klienta
i usługi ograniczające skutki ataków phishingowych.

Jesteś gotów zapłacić stówkę więcej rocznie?

Więcej tego typu wyroków spowoduje, że zainwestowanie w bezpieczeństwo
klientów zacznie się zbliżać do progu opłacalności.
To kto i ile ma zapłacić to już zweryfikuje rynek.

MarcinF pisze:

W dniu 2016-03-20 o 00:22, Marek pisze:

W skrócie, poszkodowana straciła kasę (19k) z konta podając swoje dane
autoryzacyjne na podstawionej stronie udającej oryginalną stronę banku.

Właściwy kierunek, klient banku jest praktycznie bezbronny wobec
zaawansowanych ataków, za to bank ma potencjalne możliwości
by je udaremniać. Oczywiście utrzymanie odpowiednich systemów
zabezpieczeń kosztuje, ale jeśli podobne orzeczenia staną się regułą
to w końcu banki zaczną ich używać.

Poszkodowana była setki razy informowana przez media , internet oraz swój bank, że należy sprawdzić, czy jest się zalogowany na stronie banku ( https) a ona mimo to podała swoje dane autoryzacyjne oszustom. A bank ma odpowiadać, mimo że nie ma żadnej możliwości sprawdzenia, kto używa prawdziwe dane autoryzacyjne.

IMHO ten wyrok niedouczonego sędziego się nie utrzyma przy rewizji.

--
  aha

On Mon, 21 Mar 2016 10:33:06 +0100, Aha <adresniejasnyi@pusty.pl> wrote:

Poszkodowana była setki razy informowana przez media , internet

oraz swĂłj bank, Ĺźe naleĹźy

sprawdzić, czy jest się zalogowany na stronie banku ( https) a ona

mimo to podała swoje

dane autoryzacyjne oszustom.

Poszkodowana nie ma obowiązku wiedzieć co to jest http(s) i na czym polega logowanie.

A bank ma odpowiadać, mimo że nie ma żadnej możliwości

Tak, jeśli transakcja nie była autoryzowana

--
Marek

W dniu 2016-03-21 o 10:33, Aha pisze:

MarcinF pisze:

W dniu 2016-03-20 o 00:22, Marek pisze:

W skrócie, poszkodowana straciła kasę (19k) z konta podając swoje dane
autoryzacyjne na podstawionej stronie udającej oryginalną stronę banku.

Właściwy kierunek, klient banku jest praktycznie bezbronny wobec
zaawansowanych ataków, za to bank ma potencjalne możliwości
by je udaremniać. Oczywiście utrzymanie odpowiednich systemów
zabezpieczeń kosztuje, ale jeśli podobne orzeczenia staną się regułą
to w końcu banki zaczną ich używać.

Poszkodowana była setki razy informowana przez media , internet oraz
swój bank, że należy sprawdzić, czy jest się zalogowany na stronie banku
( https) a ona mimo to podała swoje dane autoryzacyjne oszustom. A bank
ma odpowiadać, mimo że nie ma żadnej możliwości sprawdzenia, kto używa
prawdziwe dane autoryzacyjne.

IMHO ten wyrok niedouczonego sędziego się nie utrzyma

Obserwując wyroki dochodzę do wniosku, że bardzo mało mądrości jest używanej do ich wydawania, niestety. Zatem nie byłbym tego taki pewien.

przy rewizji.

Byłeś zahibernowany przez kilkadziesiąt lat?:)

--
Liwiusz

W dniu 2016-03-21 o 10:33, Aha pisze:

Poszkodowana była setki razy informowana przez media , internet oraz
swój bank, że należy sprawdzić, czy jest się zalogowany na stronie banku
( https) a ona mimo to podała swoje dane autoryzacyjne oszustom.

Przy obecnym stopniu zaawansowania ataków, przeciętny klient banku
nie jest w stanie zweryfikować bezpieczeństwa swojego komputera.

A bank ma odpowiadać, mimo że nie ma żadnej możliwości sprawdzenia, kto używa
prawdziwe dane autoryzacyjne.

Ma możliwości, ale prościej i taniej jest zwalać odpowiedzialność
na klientów, a od czasu do czasu zwracać kasę.

Na dodatek w tym konkretnym przypadku bank pozwolił przelać kasę
na konta które 2 tygodnie wcześniej otworzył, a następnie pozwolił
złodziejom wypłacić gotówkę w swoich własnych placówkach.

IMHO ten wyrok niedouczonego sędziego się nie utrzyma przy rewizji.

A może po prostu sędzia skorzystał z pomocy kompetentnego biegłego.