eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plFinanseGrupypl.biznes.bankimBank - zablokowany dostęp
Ilość wypowiedzi w tym wątku: 122

  • 61. Data: 2020-06-05 19:43:45
    Temat: Re: mBank - zablokowany dostęp
    Od: Piotr Gałka <p...@c...pl>

    W dniu 2020-06-05 o 18:24, Kamil Jońca pisze:

    > Ale Ty cały czas nie chcesz zrozumieć jednej rzeczy: w momencie
    > opracowyawania i wdrażania tych algorytmów one BYŁY uważane za
    > bezpieczne. Na owe 20 lat, tak jak chciałeś. Tylko, przed upływem owych
    > 20 lat stwierdzono luki. Tego nie chcesz zrozumieć, że nie wszystko da
    > się przewidzieć/oszacować.

    OK.
    Nie wiem kiedy MD5 było wdrażane.
    Dziwi mnie, że ktoś przewidywał, bezpieczeństwo tego na więcej jak 10
    lat (przewidzieć 10 lat wydaje mi się bardzo trudno, a 20 to już chyba
    niemożliwe).
    Nie wiem kiedy (po ilu latach od wdrożenia) odkryto te słabości.

    Do tej pory rozumiałem, że odkryto po ładnych paru latach używania -
    czyli, że odkryto jak i tak w sumie wypadało zmienić.

    Po prostu - mam za mało danych/wiedzy.
    P.G.


  • 62. Data: 2020-06-07 16:02:10
    Temat: Re: mBank - zablokowany dostęp
    Od: Krzysztof Halasa <k...@p...waw.pl>

    Piotr Gałka <p...@c...pl> writes:

    > Nie wiem co to 1FA, czy 2FA, ale nie rozumiem dlaczego klient nie może
    > stosować tego samego hasła (moje założenie - hasło nigdy nie wychodzi
    > poza komputer klienta).

    To założenie wymaga odpowiedniego mechanizmu challenge - response.
    Normalne strony WWW nie przewidują czegoś takiego - hasło musi im być
    wysłane w całości (lub np. tylko niektóre znaki). Dopiero na serwerze
    ew. liczone są jakieś tam skróty itp.

    Teoretycznie dałoby się to robić po stronie klienta (np. w JS). Pewnie
    nawet dałoby się to zrobić dobrze (tak, by nie użyć np. skrótu, który
    pozwala na wielokrotne logowanie itp). Ale to w dalszym ciągu
    pozostawałoby pod kontrolą strony WWW, wystarczyłaby modyfikacja kodu
    strony.
    --
    Krzysztof Hałasa


  • 63. Data: 2020-06-07 16:11:38
    Temat: Re: mBank - zablokowany dostęp
    Od: Krzysztof Halasa <k...@p...waw.pl>

    Dominik Ałaszewski <D...@g...pl.invalid> writes:

    >> - czy po prostu przechowują całe hasło.
    >
    > Nie muszą.
    > https://zaufanatrzeciastrona.pl/post/kryptografia-ha
    sel-maskowanych-czyli-magia-matematyki/

    Podobne zabawy niczego nie dadzą, ponieważ liczba możliwych kombinacji
    takich liter jest na tyle mała, że można je złamać brutalną siłą
    w mgnieniu oka.
    Trzeba pamiętać, że posiadacza takiej bazy danych nie obowiązują
    ograniczenia w rodzaju "max 3 próby" itp.
    --
    Krzysztof Hałasa


  • 64. Data: 2020-06-07 16:20:20
    Temat: Re: mBank - zablokowany dostęp
    Od: Krzysztof Halasa <k...@p...waw.pl>

    "J.F." <j...@p...onet.pl> writes:

    >>A klient właśnie wsiada do samolotu, albo się Windows zawiesił itp.
    >>I co dalej?
    >
    > Nic, haslo nie zostalo zmienione, to za kolejnym logowaniem obowiazuje
    > stare.
    > Ale nadal na poczatku bedzie wymagana zmiana hasla :-)
    > Poza tym mozna przypominac tydzien wczesniej ...

    Userzy doskonale sobie radzą z obejściem takich systemów, bez żadnego
    pożytku dla bezpieczeństwa.
    Np. z automatycznymi zmianami radzą sobie tak, że doklejają cyfrę "1" na
    końcu. Przy kolejnej zmianie usuwają tę cyfrę. Jeśli system pamięta X
    ostatnich haseł, to doklejają kolejne cyfry. Jeśli system wymaga
    przynajmniej 1 wielkiej litery, to pierwszą - lub ostatnią - literę
    robią wielką. Itd. itd.

    Zapisują hasła na monitorze, noszą je w portfelach itd. Można pamiętać
    1 dobre hasło, ale nie takie, które się zmienia co 2 tygodnie.

    A teraz user, który ma hasła w postaci np. 256-bitowych losowych liczb
    z generatora (szestnastkowych, ale mogą być także np. dziesiętne, bez
    znaczenia) - czyli z dużo większą entropią od "typowych" akceptowanych
    haseł, ma problemy, bo użył tylko 16 (albo nawet 10) różnych znaków.
    --
    Krzysztof Hałasa


  • 65. Data: 2020-06-07 16:24:04
    Temat: Re: mBank - zablokowany dostęp
    Od: Krzysztof Halasa <k...@p...waw.pl>

    "J.F." <j...@p...onet.pl> writes:

    > Dlaczego bez sensu ?
    > Stwierdzasz w banku np rosnaca ilosc kradziezy gdzie klient twierdzi,
    > ze to nie on,
    > i chcesz sprawdzic, czy klienci nie maja ich zbyt prostych.
    > A masz hasla tylko hashowane.

    Ale raczej nie spodziewasz się, że komuś udało się trafić te hasła na
    chybił-trafił? To po co to w ogóle sprawdzać?
    Jeśli jednak spodziewasz się, to obawiam się, że słabe hasła nie są
    głównym problemem.

    > Teraz to raczej niewiele. Ba - nawet sie nie zalogujesz.
    > Ale .. np poznanie danych klienta - grozne czy nie ?

    Wystarczy, że nieakceptowalne.

    >>Może identyfikator nie jest prostą liczbą i może jest traktowany jako
    >>tajny - ale tak się nie powinno robić.
    >
    > mozna podejrzec, mozna wyciagnac z klienta, a 8 cyfr przy milionach
    > klientach to nie jest duze zabezpieczenie ..

    "Nie jest prostą liczbą" = nie jest to 8 cyfr, ale oczywiście
    identyfikator nie jest tajny i bazowanie na jego tajności jest bez
    sensu.
    --
    Krzysztof Hałasa


  • 66. Data: 2020-06-07 16:30:16
    Temat: Re: mBank - zablokowany dostęp
    Od: Krzysztof Halasa <k...@p...waw.pl>

    "J.F." <j...@p...onet.pl> writes:

    > No widzisz - DES z Unixa wydawal sie bezpieczny, a juz od dawna nie
    > jest.

    Masz na myśli crypt()? Jasne że jest wystarczająco bezpieczny - i zawsze
    będzie. W typowym zastosowaniu przynajmniej. Po prostu inne metody są
    znacznie łatwiejsze, łamanie DES to ostateczność.

    Przykład: łatwiej podmienić procedurę sprawdzającą hasło na taką, która
    je sobie także gdzieś zapisuje.

    Słabość DES może się ujawnić tylko wtedy, gdy mamy dostęp RO do hasha
    - ew. klient musiałby się nie logować itp. W typowym przypadku - bez
    znaczenia.

    > Ale nie bede probowal 3 razy. Sprawdze raz i odloze na miesiac.
    > A w miedzyczasie sprawdze milion innych uzytkownikow.
    > I gdzies trafie ..

    Owszem. Pewnie nawet ileś razy.
    --
    Krzysztof Hałasa


  • 67. Data: 2020-06-07 16:32:55
    Temat: Re: mBank - zablokowany dostęp
    Od: Krzysztof Halasa <k...@p...waw.pl>

    Piotr Gałka <p...@c...pl> writes:

    > Z lektury "Kryptografii w praktyce" Ferguson, Schneier utkwiła mi
    > informacja, że asymetryczna jest potrzebna tylko wtedy, gdy strony nie
    > mogą się wcześniej spotkać no i odbywa się to kosztem konieczności
    > zaufania trzeciej stronie.

    Są różne scenariusze, ale generalnie nie ma takiego ograniczenia - to by
    było bez sensu.
    --
    Krzysztof Hałasa


  • 68. Data: 2020-06-07 17:02:51
    Temat: Re: mBank - zablokowany dostęp
    Od: Krzysztof Halasa <k...@p...waw.pl>

    Piotr Gałka <p...@c...pl> writes:

    > Poza tym moje założenie (nie znam się na internecie) było takie, że to
    > przeglądarki jak są w trybie z kłódeczką to wymuszają logowanie w taki
    > sposób, że hasło jest hashowane (z loginem i solą) na miejscu i hasło
    > nie wychodzi poza mój komputer. Tak między innymi rozumiałem znaczenie
    > tej kłódeczki - że jestem w bezpiecznym połączeniu i przeglądarka tego
    > pilnuje, że jest ono bezpieczne między innymi nie dopuszczając do
    > wycieku mojego hasła.
    > Zakładałem, że jak ktoś definiował protokół dla bezpiecznego
    > połączenia dającego prawo wyświetlenia kłódeczki to o to zadbał.

    Nie zadbał. SSL (obecnie TLS) dba wyłącznie o to, by niedobry Mallory
    nie mógł uzyskać dostępu do danych transmitowanych między Alicją
    i Bobem.

    A tak w ogóle, to TLS jest tylko częścią techniczną, zaś całą reszta
    infrastruktury (PKI) jest podatna na takie ataki, że z kłódeczką nie
    wiązałbym zbyt wielkich gwarancji.

    >> by ten
    >> mógł je zweryfikować. Np. policzyć hash i porównać z przechowywanym
    >> w bazie.
    >
    > Hash powinien być liczony w komputerze użytkownika.

    I co dalej? Wystarczyłoby uzyskać ten hash (np. z jakiegoś serwera),
    i następnie używać go zamiast hasła. Przecież nie trzeba liczyć hasha,
    można użyć znanego - to się dzieje pod kontrolą atakującego, na jego
    własnym komputerze.

    > Hash powinien być liczony w komputerze użytkownika. Hasło nigdy nie
    > powinno być przesyłane do serwera.

    Niestety tak się nie da dobrze zrobić. Jeśli idziemy w tym kierunku, to
    racjonalne jest użycie kryptografii asymetrycznej, nie tylko tak jak to
    jest robione w TLS, ale także do autoryzacji wszelkich operacji. Z tym,
    że jeśli "typowy klient" (a nawet nietypowy) nie jest w stanie opanować
    bezpieczeństwa przeglądarki i w ogóle swojego komputera, to nie wiem jak
    miałby panować nad certyfikatami, kluczami itd.
    --
    Krzysztof Hałasa


  • 69. Data: 2020-06-07 17:07:36
    Temat: Re: mBank - zablokowany dostęp
    Od: Krzysztof Halasa <k...@p...waw.pl>

    Piotr Gałka <p...@c...pl> writes:

    > System wysyła do komputera użytkownika swoją sól. Komputer użytkownika
    > hashuje jego login+hasło+sól i to odsyła do systemu I tylko to system
    > zna (czy zna login, czy nie - nie wnikam - ważne, że hasła nigdy nie
    > widzi).

    Czyli w gruncie rzeczy ten hash jest hasłem, które wystarcza do
    zalogowania. Innymi słowy, znów przechowujesz niezaszyfrowane hasło
    w bazie serwera, każdy kto je przejmie itd.
    --
    Krzysztof Hałasa


  • 70. Data: 2020-06-07 19:29:45
    Temat: Re: mBank - zablokowany dostęp
    Od: "J.F." <j...@p...onet.pl>

    Dnia Sun, 07 Jun 2020 17:07:36 +0200, Krzysztof Halasa napisał(a):
    > Piotr Gałka <p...@c...pl> writes:
    >> System wysyła do komputera użytkownika swoją sól. Komputer użytkownika
    >> hashuje jego login+hasło+sól i to odsyła do systemu I tylko to system
    >> zna (czy zna login, czy nie - nie wnikam - ważne, że hasła nigdy nie
    >> widzi).
    >
    > Czyli w gruncie rzeczy ten hash jest hasłem, które wystarcza do
    > zalogowania. Innymi słowy, znów przechowujesz niezaszyfrowane hasło
    > w bazie serwera, każdy kto je przejmie itd.

    Ale - oryginalne haslo jest nieznane.
    Czyli inne konta pozostaja bezpieczne ...

    J.

strony : 1 ... 6 . [ 7 ] . 8 ... 13


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1