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

> Ale ten hash jest dobry tylko dla tego jednego serwera. Skoro ten
> serwer został tak zaatakowany, że ktoś wydobył te hashe to ten serwer
> już i tak jest stracony.

Eee, wcale nie ma takiej gwarancji. Istnieje klasa ataków, np. pasywny
podsłuch, gdzie taki atak dawałby atakującemu dostęp do naszego konta,
natomiast klasyczny mechanizm challenge-response jest bezpieczny.
--
Krzysztof Hałasa

do góry

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

> Jednak są pewne, kluczowe różnice:
> - hash jest znacznie dłuższy od hasła użytkownika (nie da się
> zaatakować ani siłowo, ani słownikowo),

Ale dlaczego nie? Przecież możemy dokleić salt i przelecieć słownikiem
tak samo. Jedynie trudniej zrobić rainbow tables (może nawet nie da
się).

> - jest inny w każdym serwisie nawet jak użytkownik używa tego samego hasła.

No tak. Ale w praktyce tego nie można wykorzystać.
--
Krzysztof Hałasa

do góry

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.

> 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?
Naprawdę coś takiego tam napisał? W którym miejscu?

> Pamiętam opisywany tam przykład błędu w oprogramowaniu. Ktoś
> prawidłowo wydłużył i posolił hasło, ale aby użytkownik nie musiał
> czekać około 1s aby się dowiedzieć, że się pomylił w haśle to
> programista zrobił sobie tabelkę CRC32 haseł użytkowników i najpierw
> sprawdzał to CRC.
> 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. Dodatkowo, ta
np. "1s" jest korzystna, by trudniej było złamać słabe hasło - zobacz
np. PBKDF2.
--
Krzysztof Hałasa

do góry

W dniu 2020-06-08 o 16:23, Krzysztof Halasa pisze:
> Piotr Gałka <p...@c...pl> writes:
>
>> Jednak są pewne, kluczowe różnice:
>> - hash jest znacznie dłuższy od hasła użytkownika (nie da się
>> zaatakować ani siłowo, ani słownikowo),
>
> Ale dlaczego nie? Przecież możemy dokleić salt i przelecieć słownikiem
> tak samo.

Jako oczywistą oczywistość przyjąłem stosowne wydłużenie hasła.
Wydłużając proces logowania o 1s można wydłużyć atak siłowy/słownikowy
milion razy (atak dający się przeprowadzić w godzinę będzie wymagał 114
lat.

> Jedynie trudniej zrobić rainbow tables (może nawet nie da się).

Nie znam pojęcia.
P.G.

do góry

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.

do góry

Krzysztof Halasa napisał(a) :
> Zasadniczo, w życiu musimy komuś ufać - w sensie nie możemy zakładać, że
> wszyscy nas chcą zgodnie oszukać.

Zgodnie nie. Każdy z osobna ;-)

--
Pozdrawiam
Zbyszek
PGP key: 0xDCEF4E65

do góry

"Zbynek Ltd." <s...@p...onet.pl> writes:

>> Zasadniczo, w życiu musimy komuś ufać - w sensie nie możemy zakładać, że
>> wszyscy nas chcą zgodnie oszukać.
>
> Zgodnie nie. Każdy z osobna ;-)

Aaa, to wtedy asym crypto nas zabezpiecza (może zabezpieczyć) :-)
--
Krzysztof Hałasa

do góry

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

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

Różne rzeczy da się zrobić, ale jeśli nie wystarcza nam TLS, to zamiast
robić takie solone skróty, lepiej użyć zwykłego podpisu asymetrycznego.
Wymagamy wtedy mniej-więcej tyle samo wiedzy od klienta (no niestety),
ale uzyskujemy dużo więcej - np. niezaprzeczalność złożenia zlecenia.

> 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.

A więc chodzi o coś w stylu PBKDF2. Stosuje się to głównie tam, gdzie
w ogóle nie ma żadnych serwerów, a musimy mieć klucz o znacznej
długości. Standardowy przykład to szyfrowanie dysków. To jest kompromis.
Każde "prawdziwe" rozwiązanie kryptograficzne będzie lepsze.

W przypadku serwerów wcale nie zależy nam na tym, by policzenie takiej
funkcji trwało długo. Przeciwnie, serwer ma obsłużyć jak najwięcej zadań
(w tym także jak najwięcej sprawdzań hasła). Owszem, możemy sztucznie
zwiększyć czas wykonania procedury, by trudniej było nas atakować - ale
to nie ma pochłaniać czasu CPU. Jeśli włamywacz uzyskał dostęp do haseł
(nawet zaszyfrowanych) - to jest to klęska.

> 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.

W moim przekonaniu ono nie zostało w ogóle wydłużone, bo liczba
możliwych kombinacji się nie zmieniła. Tylko policzenie tego trwa
dłużej, ale na zbyt słabe hasła żadne takie wydłużanie nie pomoże.
Różnica między sprzętem usera i atakującego (być może w przyszłości)
definiuje jakie to są te "zbyt słabe" hasła.
--
Krzysztof Hałasa

do góry

W dniu 2020-06-08 o 21:12, Krzysztof Halasa pisze:

> Różne rzeczy da się zrobić, ale jeśli nie wystarcza nam TLS, to zamiast
> robić takie solone skróty, lepiej użyć zwykłego podpisu asymetrycznego.
> Wymagamy wtedy mniej-więcej tyle samo wiedzy od klienta (no niestety),
> ale uzyskujemy dużo więcej - np. niezaprzeczalność złożenia zlecenia.

Osobiście uważam, że kiedyś się okaże że z tą niezaprzeczalnością to
może nie tak do końca. Skoro zdarzają się kradzieże danych z na prawdę
dobrze chronionych miejsc w sieci (nie mam na myśli sklepów w pl, tylko
jakieś projekty militarne) to skąd pewność, że użytkownik faktycznie
dobrze zabezpieczył swój klucz prywatny służący mu do podpisu.

> A więc chodzi o coś w stylu PBKDF2. Stosuje się to głównie tam, gdzie
> w ogóle nie ma żadnych serwerów, a musimy mieć klucz o znacznej
> długości. Standardowy przykład to szyfrowanie dysków. To jest kompromis.
> Każde "prawdziwe" rozwiązanie kryptograficzne będzie lepsze.

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.

> W przypadku serwerów wcale nie zależy nam na tym, by policzenie takiej
> funkcji trwało długo. Przeciwnie, serwer ma obsłużyć jak najwięcej zadań
> (w tym także jak najwięcej sprawdzań hasła). Owszem, możemy sztucznie
> zwiększyć czas wykonania procedury, by trudniej było nas atakować - ale
> to nie ma pochłaniać czasu CPU. Jeśli włamywacz uzyskał dostęp do haseł
> (nawet zaszyfrowanych) - to jest to klęska.

Między innymi dlatego wydłużanie hasła powinno być robione na komputerze
użytkownika - nie zabiera czasu CPU serwera.

>> 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.
>
> W moim przekonaniu ono nie zostało w ogóle wydłużone, bo liczba
> możliwych kombinacji się nie zmieniła. Tylko policzenie tego trwa
> dłużej, ale na zbyt słabe hasła żadne takie wydłużanie nie pomoże.

Kluczem jest definicja długości hasła. Ich definicją długości hasła (i
ja to po prostu przyjąłem bo tylko to jedno źródło znam i myślałem, że
to jest powszechnie stosowana definicja) jest liczba operacji
kryptograficznych które musi wykonać atakujący aby sprawdzić całą
przestrzeń haseł (z uwzględnieniem wiedzy słownikowej o hasłach).
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.
Hasło 8 znakowe, mimo, że znaki są kodowane na 8 bitach nie ma długości
64 bitów. Ma ono długość około 40 bitów (5 bitów na znak).
Wydaje się mało, bo przecież same duże, małe litery i cyfry to więcej
jak 32 znaki, ale w hasłach występują korelacje między kolejnymi znakami
(zależne też od tego jakim językiem posługuje się autor hasła). Na
przykład - jak hasło składa się z dużych liter i cyfr to znacznie
bardziej prawdopodobne jest, że cyfry wystąpią w zwartej grupie a nie
rozstrzelone losowo między literami (przy takim założeniu kilka
kolejnych bajtów ma tylko jedną z 10 wartości).
Dlatego hasło 8 znakowe wymaga około 2^40 sprawdzeń - czyli ma 40 bitów
długości. Oczywiście to jest tylko szacunek.
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.

> Różnica między sprzętem usera i atakującego (być może w przyszłości)
> definiuje jakie to są te "zbyt słabe" hasła.

Jakakolwiek by nie była przewaga sprzętu atakującego, jeśli poświęcimy
1s czasu usera przy każdym logowaniu to zwiększymy ilość pracy
atakującego milion razy. Czy to wystarczy aby odechciało mu się ataku.
Zapewne zależy, ale na pewno zwiększy koszt ataku.

Solenie ma na celu uniemożliwienie jednoczesnego ataku na wiele
systemów. Bez soli atakujący musiałby wykonać ten milion przeliczeń
tylko raz dla danego hasła (lub + user) i potem mógłby sprawdzać wynik w
wielu systemach, a z solą (jawną) musi to przeliczenie wykonać dla
każdego systemu osobno.

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.
P.G.

do góry

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

> Osobiście uważam, że kiedyś się okaże że z tą niezaprzeczalnością to
> może nie tak do końca. Skoro zdarzają się kradzieże danych z na prawdę
> dobrze chronionych miejsc w sieci (nie mam na myśli sklepów w pl,
> tylko jakieś projekty militarne) to skąd pewność, że użytkownik
> faktycznie dobrze zabezpieczył swój klucz prywatny służący mu do
> podpisu.

To bez znaczenia - chodzi o to, że piłeczka jest wtedy po stronie
klienta. Równie dobrze mógłby podpisać dokument po pijaku.

> 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ć.
Albo tylko tak teoretycznie, co by było gdyby user koniecznie chciał
stosować to samo hasło wszędzie i jak to zrobić? 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.

> 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.

> 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.

> 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?

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"?

No i tak, jak napisałem - może lepiej po prostu zastosować podpis
elektroniczny (niekoniecznie dokładnie w obecnej "kwalifikowanej"
postaci)? To załatwia dużo więcej, można też naprawdę mieć to samo hasło
(albo w ogóle żadne, zależnie od warunków). Czymś pośrednim są wszelkie
"notatniki haseł".
--
Krzysztof Hałasa

do góry