Witam ponownie

> > w tym przykładzie nie chodziło o http, tylko https i długość
> > klucza ...
> >
> Ale JA pisalem o czym innym, wiec polemizujesz, ale nie ze mna :-)
>

Napisałeś o tym w kontekście przykładu z multibankiem, a tamten dotyczył
właśnie długości klucza , wiec pewnie stąd nieporozumienie.


> I dalej twierdze, ze, albo sie w ogole nie reaguje na odwolanie po
> http
> (i tak powinno sie robic, zeby utrudnic phishing,
> >> albo daje automatyczne przekierowanie. Jak jest

Faktycznie w niektórych sytuacjach reagowanie lub udostępnianie jednocześnie po
http może ułatwić phishing, ale to też wymaga dodatkowych błędów w tym co sie
po http udostępnia (pomijam różnego rodzaju próby z rejestrowaniem podobnie
wyglądających domen, bo to zupełnie inna kwestia). Czy autorzy wskazali takie
błędy? Czy powiedzieli że w ogóle istnieją? Oczywiście nie. Zresztą nie
phishing był tam tematem przewodnim. Za to pojawiło się stwierdzenie o tym, że
udostępnianie po http i http niesie ze sobą zagrożenia związane z wysłaniem
zawartości cookie transakcyjnego po http. A napisali czy i jak banki się
zabezpieczyły przd taką możliwością??? Czy próbowali ocenić te zabezpieczenia?
Oczywiście znowu temat przemilczany. Nie pasował do marketingowego kontekstu.


>
> I dalej podtrzymuje powyzsza moja obrone tego - zgoda, nie bardzo
> profesjonalnie od strony "redaktorsko-publikacyjnej" napisanego
> - artykulu, glownie ze wzgledu na oddzwiek, jaki wywolal.
> Jezeli mBank (gdzie totalne informatyczne bzdury wypisuja tacy
> decydenci jak mWB, mącąc niezorientowanym w glowach) podjal
> dzialania w ciagu *kilku dni*, to jest to naprawde wielka
> sprawa :-)

Piszesz nieprofesjonalnie od strony "redaktorsko-publikacyjnej" - powiedziałbym
że bardzo dyplomatycznie się wyraziłeś;). Może więc podsumujmy dlaczego
dokument jest moim zdaniem nierzetelny - jego główne wątki to:

1) Udostępnianie po HTTP i HTTPS - gdyby opisano same potencjalne problemy, to
trudno by z nimi polemizować, ale przecież nie tak to wygląda. Najpierw podano
przykład banku w którym po http i https można wypełnić formularz i wysłać dane,
a potem mamy tabelkę w której jest długa lista banków, które udostępniają
domenę po http i https. Jakie wnioski wyciągnie laik? Chyba się zgodzisz że
dokłądnie takie, że w tych bankach wypełnianie formularzy elektronicznych jest
niebezpieczne bo są puszczane po http i https. A czy tak jest? To pytanie jest
retoryczne...

2) Problem SSL2. Tak jak już pisałem - jest troche przestarzały, ma swoje
niedoskonałości, ale pisałem też że niech ktoś spróbuje go złąmać przy długim
kluczu ... Odpisałeś że nie powinni tego robić by nie łamać zabezpieczeń banku.
Ok, nie powinni, ale to przecież nie problem. Postawienie Apache z SSLem to pół
godziny roboty max. - niech postawią środowisko testowe i pokażą jak się łamie
SSL2 z AESem i jak słabe jest to zabezpieczenie. Wtedy nikt nie będzie miał
wątpliwości że protokół jest niebezpieczny i nie wolno zwlekać z jego
zastąpieniem. Ale przestańmy bujać w chmurach ... ;) O czym my w ogóle piszemy -
nawet Ty się uśmiechnąłeś gdy pisałeś że może mogliby to zrobić ... ;)

3) Problem błędu w mod_ssl - wskazali chyba 2 banki o ile się nie mylę. Tutaj
nie mam uwag, poza taką że błąd rodzi największe problemy wówczas gdy wspiera
się krótkie klucze, a to chyba też pominęli ... ;)

4) Możliwość połączenia z krótkim kluczem. To co w tym dokumencie wypisali, to
było mistrzostwo świata i bynajmniej nie jest to komplement ... Wiele banków (i
nie tylko - innych organizacji też) rozwiązuje problem w ten sposób, że próba
nawiązania połączenia z krótkim kluczem powoduje wyświetlenie w przeglądarce
komunikatu że nie można nawiązać połączenia bo przeglądarka klienta nie wspiera
silnego szyfrowania. Jest to eleganckie rozwiązanie "pod klienta". No i tutaj
autorzy się "popisali" - najpierw mamy ten nieszczęsny przykład z błędem w
mod_ssl i połączeniem z wybranym bankiem po krótkim kluczu, a potem listę
banków, które pozwalają "nawiązać połączenie z krótkim kluczem". Jak laik ma
rozumieć możliwość nawiązania takiego połączenia - dla niego oznacza to
możliwość zalogowania się i wykonywania operacji na rachunkach. Czy można coś
takiego zrobić w tych bankach? Znowu pytanie retoryczne! Ściema i manipulacja.



> Co prawda tez uwazam (co napisalem we wczesniejszym poscie), ze
> powinni
> skomentowac, ale dalej juz sie roznimy - podchodzisz do tego
> myslac jak
> profi, ale w bankach decyduja marketingowcy (rozni mWB itp.).
> A jak pewnie wiesz, marketingowcom podczas szkolen dokonuje sie
> mentalnej
> amputacji 80% mozgu, zeby mysleli tak, jak mysli przecietny
> potencjalny
> klient, ktorego maja zlowic :-))
> Wiec niezaleznie od wartosci merytorycznej zestawien, porownan
> itp. z tego
> artykulu bankowcy-decydenci wyczytali tylko "moj bank wypadl
> gorzej od ..."
> i to jest podstawa do wypracowania reakcji.


Z pewnością zareagowali, tylko że z takim podejściem co miesiąc należałoby
publikować jakiś złowieszczy SPAM żeby postraszyć kadrę kierowniczą w
bankach ...

Mi się takie podejście nie podoba, uważam że wartość merytoryczną raportu
(zresztą umówmy się - nie była to jakaś wirtuozeria - raczej wykorzystanie
exploita do wykazania obecności dziury) można było zmieścić na kartce A4 (2
stronach), a reszta to manipulacja i próba sprzedaży swoich usług. Mogę mieć
tylko nadzieję że jednak się nie udało, taki rodzaj "marketingu" wybitnie mi
się nie podoba.


Przepraszam że tak przydługo przynudzam i pozdrawiam
prz3c1nak

--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl