On Wednesday, December 3, 2014 9:13:41 PM UTC+1, Edek wrote:

> Logowanie nie będzie trwało dobę, sól jest znana - doklejasz i liczysz
> hash w tym samym czasie co zawsze.
Podstawą jest regulowanie tego czasu. Gdy policzy się raz hash(string), to
hasła o długości 5 znaków od razu rozkodują. Składające się z 8 znaków na
mocnym sprzęcie też da rady. Można łamać z milion na sekundę w brutforce.

> Ten koszt o którym pewnie mówisz to hash(hash(hash(...(hash(string)))).
O kiedy dostałem funkcję biblioteczną, to szkoda mi czasu na sprawdzanie
co to naprawdę robi.


> Taki trick pozwala na zwiększenie kosztowności potrzebnych obliczeń
> a dodatkowo trzeba wiedzieć ile razy liczyć hash z hasha z hasha -
> trzeba znać tę liczbę.
Nie wiem jak jest w bibliotekach których Wy używacie, ja przywykłem, że
ta liczba jest tak samo doklejana do hasła, jak losowa sól.


> Używa się raczej do szyfrowania plików niż haseł, ale też można.
Ale czego używa się do szyfrowania plików? Na pewno zwiększa się
koszt przy szyfrowaniu haseł. A pliki to chyba zupełnie inna inszość...
bo hasha nie da się rozszyfrować. Zwykły sha czy md5 to można użyć
jako coś lepszego od crc do plików, ale do szyfrowania? Sorry, nie
widzę związku.


> O ile nie masz na myśli gigantycznej soli...
Mam na myśli, może nie gigantyczny, ale duży koszt. Zresztą stała sól
też może być duża, bo czemu nie?


> Stała + losowa - ma sens, o ile ta stała nie jest znana.
Jak masz dużą stałą sól i duży koszt (np. 3 sekund na jednym
rdzeniu) to nawet po wycieku trudno wygenerować tablice tęczowe.
Na jednym kompie dla 5 znakowych haseł (powiedzmy znak pochodzi z
80elementowego zbioru), generowanie może trwać 100 lat.


> czyli w praktyce łatwa do zdobycia.
Gdy się udostępnia kod (obojętnie czy binarny czy źródłowy) to
jedyną gwarancję daje świadomość użytkownika, aby nie używał
hasła takiego samego jak do banku. Zresztą o czym rozmawiamy,
jeśli na kompie da się zainstalować spyware...


> Jakoś sens zaszycia stałej w binarce przy
> podstawowej umiejętności deasemblowania jaką każdy cracker posiada
> mnie mało przekonuje.
W ogóle nie przekonuje. Chodzi o sytuacje, gdy trudno jest wykraść
cokolwiek.


> Czyli jak mówisz, sprowadza się do sytuacji
> gdy kody nie wyciekną co zakłada closed-source przy okazji jeżeli
> nie one-time builds - zbudowanie builda dla każdego z inną stałą.
Ściśle, sprowadza się do sytuacji colsed-salt ;-)


> Pytanie jak się ją stosuje. Oba zastosowania mają sens tylko też inne
> właściwości. W kryptografii różne elementy różnie się stosuje, nie ma
> jednej złotej reguły na wszystko, jak właściwości pasują do celu
> to się ich używa. Dlatego trzeba rozumieć co się robi i dlaczego,
> kopiowanie rozwiązań jest dla misiów o małym rozumku.
Nie zgodzę się. Jeden i drugi sposób solenia ma swoje zalety. Połączenie
stałej soli z losową nie powoduje utraty zalet ani jednego sposobu,
ani drugiego. Dlatego zawsze należy połączyć oba sposoby i
zawsze należy ustawić duży koszt.


> Do haseł: doklejonej do hasha zmiennej o ile rozwiązanie jest znane.
> Zawsze można stworzyć jakieś security by obscurity albo olać -
> o ile zna się konsekwencje. Ja na mojej prywatnej apce na mojej
> prywatnej bazce używam hasło plaintext - DO NOT TRY THIS AT HOME.
Ja mam do tego celu bibliotekę. Generuję sól i wywołuję jedną, może
dwie funkcje. Nieważne czy aplikacja będzie dla studenta czy poważnej
firmy.

Zdrowia