eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plFinanseGrupypl.biznes.bankimBank - zablokowany dostępRe: 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: Mon, 8 Jun 2020 17:13:22 +0200
    Organization: news.chmurka.net
    Message-ID: <rblkij$ug5$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>
    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: Mon, 8 Jun 2020 15:13:23 +0000 (UTC)
    Injection-Info: news.chmurka.net; posting-account="PiotrGalka";
    posting-host="213.192.88.68"; logging-data="31237";
    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:651811
    [ ukryj nagłówki ]

    W dniu 2020-06-08 o 16:33, Krzysztof Halasa pisze:
    > Piotr Gałka <p...@c...pl> writes:
    >
    >> W tej gałęzi wątku twierdzę, że powinniśmy móc używać tych samych haseł.
    >> Jeśli komputery mogą nam to załatwić to powinno to (dla ogólnego
    >> bezpieczeństwa) być tak zrobione. Najlepiej 'od zawsze'.
    >> Nie widzę uzasadnienia dlaczego nie jest.
    >
    > Napisałem - dlatego, że HTTPS nie przewiduje takiego mechanizmu.
    > Dlatego, że obecnie musiałoby to być zrobione w JS, a do tego nie można
    > mieć zaufania. Poza tym, gdyby ktoś chciał to zrobić (w ogóle takie
    > rzeczy występują, tylko że nie w HTTPS), to należałoby to zrobić lepiej.

    To są argumenty dlaczego nie zrobiono.
    Mi chodzi o to czy są jakieś argumenty mówiące dlaczego 'nie da się zrobić'.

    >
    >> Moje założenie, że hasło jest hashowane w komputerze użytkownika,
    >> chyba wzięło się z lektury tej jednej książki. Z niej chyba wynikało,
    >> że tak to musi być i ja to przyjąłem jako pewnik.
    >
    > Czy ja dobrze kojarzę, że ta książka to "Applied Crypto" Schneiera?

    Nie to 'Practical Cryptography' Ferguson, Schneier.

    > Naprawdę coś takiego tam napisał? W którym miejscu?

    Jestem prawie pewien (ale nie mam czasu szukać), że gdy omawiali
    potrzebny na wydłużenie czas to właśnie pojawiła się kwestia wydajności
    komputera użytkownika a nie serwera. I była chyba mowa o przyjęciu
    rozwiązania skalowalnego w tym sensie, że wraz z przyspieszaniem
    komputerów użytkowników należy zwiększać wydłużenie tak, aby czas był
    zawsze maksymalny akceptowalny przez użytkownika.

    >> W ciągu sekundy (na zwykłym PC) daje się wydłużyć hasło o około 20
    >> bitów, a tym zabiegiem skrócił je o 32 bity.
    >
    > "Wydłużyć" to IMHO nie jest najszczęśliwsze sformułowania.

    Mi to się z niczym nie kłóci. Trzeba tylko rozumieć, że 8 znakowe hasło
    przeliczone przez SHA512 nie jest wydłużone do 512 bitów a zostało tylko
    wydłużone o 1 bit. A przeliczone milion razy jest wydłużone o około 20
    bitów.

    Dodatkowo, ta
    > np. "1s" jest korzystna, by trudniej było złamać słabe hasło - zobacz
    > np. PBKDF2.

    Na pierwszy rzut oka wygląda mi to po prostu na wydłużenie hasła.
    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