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.

do góry

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

do góry

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

do góry

"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

do góry

"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

do góry

"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

do góry

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

do góry

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

do góry

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

do góry

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.

do góry