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.