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: Tue, 9 Jun 2020 18:20:45 +0200
    Organization: news.chmurka.net
    Message-ID: <rbocsu$kra$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>
    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: Tue, 9 Jun 2020 16:20:46 +0000 (UTC)
    Injection-Info: news.chmurka.net; posting-account="PiotrGalka";
    posting-host="213.192.88.68"; logging-data="21354";
    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:651838
    [ ukryj nagłówki ]

    W dniu 2020-06-09 o 16:49, Krzysztof Halasa pisze:
    >> Jeśli to jest po prostu wydłużanie hasła to według autorów tej książki
    >> nie ma żadnego usprawiedliwienia dla nie stosowania tego wszędzie.
    >
    > I tam naprawdę coś takiego napisali? Przyznaję, że nie czytałem tej
    > książki (ani pewnie nawet nie miałem jej w ręku), ale to brzmi
    > przynajmniej kontrowersyjnie.
    >
    > Może napisali to tylko w tym konkretnym kontekście (np. szyfrowania
    > dysków lokalnych)? Wtedy mogę się z tym zgodzić.

    Poszukałem. Szkoda, że nie mam książki w pdf - byłoby łatwiej.
    Napisali to w pobliżu dysku ale nie w kontekście.
    Rozdział 22 - Przechowywanie tajemnic
    22.1 Dysk - że można na dysku, ale trzeba jakoś zaszyfrować
    22.2 Pamięć ludzka - dywagacje, co człowiekowi łatwo zapamiętać, a co nie.
    22.2.1 Solenie i rozciąganie
    Możliwe, że oni nie użyli określenia wydłużanie hasła, a tylko ja tak to
    zapamiętałem (bo używają pojęcia długość).
    Rozdział ten zaczyna się tak:
    "Chcąc w haśle lub frazie kluczowej o ograniczonej entropii zawrzeć jak
    najwięcej bezpieczeństwa, możemy użyć dwóch technik, których nazwy
    kojarzą się ze średniowieczną izbą tortur. Techniki te są tak proste i
    naturalne, że powinny być stosowane we wszystkich systemach haseł.
    Ignorowanie ich nie ma żadnego wytłumaczenia."

    > Albo tylko tak teoretycznie, co by było gdyby user koniecznie chciał
    > stosować to samo hasło wszędzie i jak to zrobić?

    To, że zastosowanie solenia i wydłużania (rozciągania) pozwalało by
    stosować to samo hasło wszędzie to wyłącznie moja hipoteza. W książce
    nie ma według mnie nic na ten temat. Nigdzie nie napisałem, że oni
    sugerują taką możliwość. Jeśli coś tak zrozumiałeś to musiałem się
    nieprecyzyjnie wypowiedzieć.

    > Normalnie jednak
    > korzyści wynikające z zastosowania tego lub podobnego algorytmu byłyby
    > niewspółmiernie niskie w porównaniu do zagrożeń, jakie niesie ze sobą
    > jedno hasło.

    Oczywiście, ale praktyka jest o ile wiem taka, że ludzie do wszystkich
    mało istotnych miejsc często stosują jakieś swoje jedno hasło, już
    pomijając kwestię stosowania hasła '1234'.

    >> Sprawdzenie pojedynczej hipotezy dotyczącej hasła (nie przeliczonego)
    >> to jedna operacja. Sprawdzenie tego samego hasła ale przeliczonego
    >> milion razy to milion operacji przeliczania + jedna operacja
    >> porównania.
    >
    > Zakładam, że seed jest odpowiednio silny, bo jeśli nie, to tęczowe
    > tablice mogą nam ten problem sprowadzić do prostego lookupu.
    > Ale nawet z dobrym seedem, wszystko zależy od siły oryginalnego hasła.

    To, że hasło powinno być silne nie ulega wątpliwości, ale tak ogólnie to
    nie wiem o czym mówisz i nie mam czasu szukać.

    >> Przeliczenie milion razy SHA256 na moim 10 letnim komputerze zajmowało
    >> poniżej 1s. Milion to około 2^20. Po takim zabiegu atakujący to samo
    >> hasło musi wykonać 2^60 operacji. Czyli długość hasła (przy przyjętej
    >> definicji długości) zwiększyliśmy o 20 bitów.
    >
    > Ale atakujący może sobie postawić (dość tanim kosztem - są zdjęcia
    > w sieci) 200 konsoli. Są też inne możliwości, moc obliczeniowa nie jest
    > droga. Zauważ, że postęp techniczny powoduje, że jeśli nie uda się tego
    > złamać dziś, to może uda się jutro.

    Jeśli jutro do złamania nie wydłużanego hasła w rozsądnym czasie
    wystarczy mu jeden komputer to do złamania w tym samym czasie hasła,
    które zostało wydłużone będzie potrzebował miliona komputerów.
    Tylko tyle i aż tyle.
    A takie utrudnienia kosztuje nas sekundę przy każdym sprawdzaniu hasła.
    To nie wygórowana cena.

    >> Ja za autorami tej książki przyjąłem, że nie ma żadnego
    >> usprawiedliwienia dla nie stosowania solenia i wydłużania we
    >> wszystkich aplikacjach. A że czytałem to w 2004r, gdy pewnie nie
    >> zrobiłem jeszcze żadnego zakupu przez internet więc jak zetknąłem się
    >> pierwszy raz z tworzeniem sobie konta to byłem pewien, że tak to jest
    >> wszędzie. Po prostu nie wyobraziłem sobie, że ktoś mógł nie zastosować
    >> czegoś, co jest proste i nie ma usprawiedliwienia na nie stosowanie
    >> tego.
    >
    > Nie wystarczy brak wad :-)
    > Przede wszystkim, by zastosować jakieś rozwiązanie, musi być ku temu
    > jakiś racjonalny powód. Często jest - i tam się takie rzeczy stosuje.
    > Natomiast w przypadku serwerów w Internecie - co jest, Twoim zdaniem,
    > takim racjonalnym powodem?

    Jeśli jest jakiś powód stosowania haseł to jest też naturalne aby
    złamanie było możliwie utrudnione. Konieczność przeliczenia milion razy
    każdego hipotetycznego hasła przed wysłaniem aby sprawdzić czy zadziała
    jest na pewno dodatkowym utrudnieniem przy znikomym koszcie tego
    rozwiązania. Oczywiście jeśli serwer może w inny sposób ograniczyć pasmo
    ataku czyniąc go beznadziejnym to wydłużanie (rozciąganie) wydaje się
    zbędne. Ale jest też taka ogólna zasada, aby utrudnić wszędzie gdzie się
    da, bo np. w nieprzewidziany dla nas sposób atakujący wejdzie w
    posiadanie bazy z hashami haseł. Nie powinno mu to pozwolić znaleźć
    haseł choćby dlatego, że hasła mogą pozwolić na wyciągnięcie wniosków co
    do sposobu tworzenia haseł przez userów, co może być wykorzystane do
    zaatakowania innego, ważniejszego systemu.

    > Nie żeby "wydłużanie hasła" nie miało wad. Co powiesz o takiej
    > psychologicznej - "skoro hasło jest wydłużane, to oryginalnie wystarczy
    > byle co"?

    Użytkownik nie musi wiedzieć, że jest wydłużane.
    A jeśli przekazuje mu się tę wiedzę, to powinien usłyszeć, coś w stylu,
    że obecnie hasła o długości krótszej niż 80 bitów są uznawane za zbyt
    słabe. System przedłuża hasła o 20 bitów więc stosuj hasła o długości co
    najmniej 60 bitów (czyli 12 znaków) a najlepiej dłuższe.
    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