On Saturday, November 29, 2014 8:58:19 PM UTC+1, Edek wrote:

> I tylko dlatego się soli. Stała sól ma pewien sens, w końcu
> o ile nie jest znana atakującemu ma przewagę nad solą przyklejoną
> do hasha, która staje się znana wraz z hashem. Ale ma wymienione
> wady, da się wygenerować hashe no i gratis znać hasła identycznych
> hashy (z identycznego hasła przy identycznej soli powstaje identyczny
> hash).

A trzecia możliwość od macochy... Czemu nie używać zarówno stałej soli i losowej?
Dlaczego musi być albo stała, albo losowa? Jak ktoś wpisze
5cio znakowe hasło, to dasz cost na całą dobę obliczeń i logowanie
będzie trwało dobę? Stała sól o dużym rozmiarze ma zajebisty sens gdy
tablice haseł wyciekną, a kody nie wyciekną.

Jakbyś spojrzał w kody moich programów, to byś właśnie zauważył wszędzie
stałą sól. Mam niemal identyczny kod, jak owe kwiatki, z których w tym
wątku się nabijacie. Ja się nie nabijam, bo nie wiem jak ta sól jest
używana. W frameworkach w jakich pracowałem albo chociaż przeglądałem
kod, też była stała sól, i kod też wyglądał w tamtym przykładzie. Nie
nabijam się, bo nie sprawdzałem jak ta sól jest używana. Może być
jest używana całkiem mądrze.


> Nie wydaje mi się żeby to wyliczenie Bartka dotyczące czasu używania
> tablic było sensowne: można wyliczone hashe ułożyć w b-tree i zrobić
> lookup log(n) po hashu z hasła usera. Nie da się?


> Nie wymyślać tylko solić jak PB przykazał ;)
A PB przykazał albo używać stałej, albo losowej?

Zdrowia