eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plFinanseGrupypl.biznes.bankimBank - zablokowany dostęp › Re: mBank - zablokowany dostęp
  • Path: news-archive.icm.edu.pl!news.icm.edu.pl!news.chmurka.net!.POSTED.213.192.88.68!
    not-for-mail
    From: Piotr Gałka <p...@c...pl>
    Newsgroups: pl.biznes.banki
    Subject: Re: mBank - zablokowany dostęp
    Date: Sat, 13 Jun 2020 17:05:00 +0200
    Organization: news.chmurka.net
    Message-ID: <rc2pum$189$1$PiotrGalka@news.chmurka.net>
    References: <rb2jmu$gsi$1$PiotrGalka@news.chmurka.net>
    <a...@g...com>
    <rb2s3g$lqr$1$PiotrGalka@news.chmurka.net> <m...@p...waw.pl>
    <rbb2n0$8os$1$PiotrGalka@news.chmurka.net>
    <5ed91c37$0$17363$65785112@news.neostrada.pl>
    <rbbbv3$dpp$1$PiotrGalka@news.chmurka.net> <rbbkam$ha5$1@gioia.aioe.org>
    <rbd72j$jke$1$PiotrGalka@news.chmurka.net> <m...@p...waw.pl>
    <1wgzmwc2p2rb2.1w4yqapb3eqlv$.dlg@40tude.net> <m...@p...waw.pl>
    <rbleqn$r2f$1$PiotrGalka@news.chmurka.net> <m...@p...waw.pl>
    <rblkij$ug5$1$PiotrGalka@news.chmurka.net> <m...@p...waw.pl>
    <rbnlha$6o1$1$PiotrGalka@news.chmurka.net> <m...@p...waw.pl>
    <rbocsu$kra$1$PiotrGalka@news.chmurka.net> <m...@p...waw.pl>
    <rbvi1k$vn6$1$PiotrGalka@news.chmurka.net> <m...@p...waw.pl>
    NNTP-Posting-Host: 213.192.88.68
    Mime-Version: 1.0
    Content-Type: text/plain; charset=utf-8; format=flowed
    Content-Transfer-Encoding: 8bit
    Injection-Date: Sat, 13 Jun 2020 15:04:54 +0000 (UTC)
    Injection-Info: news.chmurka.net; posting-account="PiotrGalka";
    posting-host="213.192.88.68"; logging-data="1289";
    mail-complaints-to="abuse-news.(at).chmurka.net"
    User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101
    Thunderbird/68.9.0
    In-Reply-To: <m...@p...waw.pl>
    Content-Language: pl
    Xref: news-archive.icm.edu.pl pl.biznes.banki:651868
    [ ukryj nagłówki ]

    W dniu 2020-06-13 o 15:06, Krzysztof Halasa pisze:
    > Piotr Gałka <p...@c...pl> writes:
    >
    >> Mówimy o logowaniu się użytkowników (ludzi) a nie użytkowników
    >> (komputerów), bo w tym drugim przypadku nie ma problemu, aby hasło
    >> było dowolnie długie i bez naleciałości językowych.
    >
    > Ależ oczywiście że ludzi. Komputery nie logują się raczej hasłami.

    Jak napisałeś o logowaniu co sekundę to potrafiłem sobie jedynie
    wyobrazić, że komputer mógłby chcieć co sekundę utworzyć nową sesję, bo
    człowiek raczej nie.

    > Tyle że mówimy o różnych sytuacjach. O logowaniu się do serwerów.
    > Z wieloma userami.

    Ale ta kwestia straconej sekundy w czasie logowania dotyczy każdego
    usera indywidualnie i czasu obliczeniowego na jego komputerze a nie
    czasu serwera.

    > Powtórzę jeszcze raz - w domowych zastosowaniach
    > takie algorytmy jak najbardziej powinny być stosowane, bo tam jest to
    > sensowna możliwość zapewnienia względnego bezpieczeństwa takich haseł.

    Im więcej userów tym większa szansa, że się ktoś zainteresuje atakiem na
    taki system.

    >> Nigdy nie byłem właścicielem serwera, ale wyobrażam sobie, że ktoś
    >> (jakieś służby) zupełnie inaczej ocenią wyciek danych w obu
    >> przypadkach.
    >
    > Dane adresowe, numery kart kredytowych, numery telefonów, PESELe, dane
    > rodziców - to są dane problematyczne. Hasła - zapomnij.

    To jest logiczne.
    Wychodziło by, że wydłużanie haseł cokolwiek da tylko wtedy, gdy
    rozważamy, sytuację, że baza danych wyciekła i o tym nie wiemy, a celem
    atakującego jest uzyskanie dostępu do kont klientów.
    Nie może robić wielu prób logowania bo system zareaguje blokadą kont,
    ale jakby poznał hasła....

    Nie mam pojęcia jak to wygląda od strony serwera. Skoro zdarzają się
    włamania to znaczy, że hakerzy potrafią obejść zabezpieczenia. Skąd
    wiadomo, że ktoś się włamał i uzyskał dostęp do bazy danych. Może jest
    tak dobry, że zatarł za sobą ślady i my nawet nie wiemy, że należy
    piorunem zmieniać hasła, a on właśnie atakuje hasła aby mieć normalny
    dostęp do kont użytkowników. W takiej sytuacji lepiej aby było mu milion
    razy trudniej.

    > Dane w bazie klientów muszą być chroniono, ich wyciek jest rodzajem
    > katastrofy. Hasła to sprawa drugorzędna - można je zmienić. Inne dane
    > zmienia się znacznie trudniej.

    Ale zazwyczaj klient ma dostęp do swoich danych. Więc jak ktoś pozna
    hasło to też ma dostęp do tych danych.

    > Np. ostatnio były wycieki danych osobowych z (przynajmniej dwóch)
    > uczelni. Myślisz że jakieś hasła, albo sposób ich szyfrowania, kogoś
    > zainteresowały?

    Nie mam pojęcia.
    Ale czy takie wycieki nie zdarzają się przez to, że ktoś uzyskał dostęp
    jako jeden z ważnych userów - w sensie poznał jego hasło (zakładając, że
    login jest jawny).
    Jeżeli system umożliwiał wykonanie tylko kilku prób (dziennie)
    domniemanych haseł to faktycznie wydłużanie nic nie daje.

    >> Może ująłem to zbyt skrótowo, ale za tą książką pamiętam coś w stylu,
    >> że każdy fragment systemu ma się bronić sam nie licząc na obronę przez
    >> pozostałe fragmenty.
    >
    > Owszem. Zwykle jest to nazywane "defense in depth" ("defence"). Tyle że
    > to nie ma większego związku ze sprawą. Nie mówię że zupełnie - ale
    > większego.

    Możliwe.

    > Natomiast jak najbardziej możesz zainteresować się "notatnikami haseł".
    > Tam możesz mieć wspólne "główne hasło" (albo PIN), generowane losowo
    > (mam nadzieję) hasła dla każdego serwisu, OTP, ECC itd. Może to służyć
    > jako klawiatura USB, nie trzeba przepisywać długich ciągów znaków,
    > niektóre programy (np. przeglądarki) mogą tego używać automagicznie
    > (notatnik prosi o potwierdzenie np. PINem).

    Domyślam się co to są notatniki haseł - miałem zamiar sobie samemu coś
    takiego napisać.
    Co do wpisywania długich ciągów znaków - robimy USB czytniki kart, które
    udają klawiaturę i po zbliżeniu karty wyrzucają jej numer jakby ktoś
    klepał w klawisze. Co jakiś czas się zdarza kolejny klient który wymyśla
    sobie jakieś nowe potrzeby (gwiazdka na początku, TAB na końcu zamiast
    ENTER itp.). Ostatnio zrobiliśmy konfigurowanie - 0 do 3 znaków z
    przodu, 0 do 2 znaków na końcu (+ Enter lub nie). Zobaczymy, kiedy to
    nie wystarczy.
    Można by wypisywać nie numer karty a jakieś dane zapisane na karcie
    krypto, ale na razie nie było takich pytań. Chyba słusznie, bo to raczej
    nie ma sensu, aby tajne dane dobrze ukryte na karcie wyrzucać jawnie jak
    klawiatura :)
    P.G.





Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1