On 13.11.2014 00:12, M.M. wrote:
> On Wednesday, November 12, 2014 11:48:57 PM UTC+1, M.M. wrote:
> Jeszcze cytat z wiki:
> [
> Biorąc pod uwagę, że złodziej haseł może posłużyć się tęczowymi tablicami, możemy
powiększyć dane do takiego rozmiaru, przy którym używanie tęczowych tablic przestanie
mieć sens. Np. gdy tęczowe tablice nadają się do łamania skrótów, które powstały od
danych mających od 1 do 8 bajtów, wystarczy dodać 8 bajtów soli, aby uniemożliwić ich
stosowanie. Nawet jeśli złodziej zna sól, nie będzie w stanie jej ominąć.
> ]
> Nic tutaj nie piszą o tym, że dla każdego hasła musi być inna sól, aby
> posłużenie się tęczowymi tablicami było niemożliwe. Piszą tylko, że
> wystarczy powiększyć dane. Albo na wiki jest nieścisłość, albo argument z
> tęczowymi tablicami odpada. Kiedyś czytałem inny artykuł, też nie pisali
> nic o tym, że wszędzie musi być inna sól. Ale nie wiem, może to ogólnie
> panujący błędy pogląd.

Wydaje mi się, że autor miał na myśli to, że przygotowanie takiej
tablicy dla porządnej kryptograficznej funkcji skrótu trochę trwa,
zakłada więc, że taką tablicę przygotowujemy raz i potem tylko
chcemy używać. Użycie _jakiejś_ odpowiednio długiej soli uniemożliwia
atakującemu zbudowanie tablicy dekodującej na zapas. Może ją zacząć
budować dopiero, gdy sol wycieknie.

Tele na temat 'co autor miał na myśli'. Klikam na dłuższą wersję:

The salt value is not secret and may be generated at random and
stored with the password hash. A large salt value prevents
precomputation attacks, including rainbow tables, by ensuring that
each user's password is hashed uniquely. This means that two users
with the same password will have different password hashes (assuming
different salts are used). In order to succeed, an attacker needs to
precompute tables for each possible salt value. The salt must be large
enough, otherwise an attacker can make a table for each salt value.

Tu już zalecają różne sole. Przemykają nieco nad uzasadnieniem,
czyli tym, że nie tylko mamy większy koszt _wcześniejszego_
przygotowania (co było już przy wspólnej _tajnej_ soli) ale
i koszt ataku w momencie wypłynięcia jest *liczba użytkowników
raza mniejszy.

To ostatnie zdanie musze doprecyzować. Oczekiwany koszt w obu
przypadkach jest liniowy. Tylko jeśli znamy sol, która jest wspólna
dla wszystkich haseł, hashując jakąś propozycję hasła mamy
prawdopodobieństwo

liczba_haseł_w_bazie/liczba_potencajlnych_haseł

na trafienie w jakis hash. Zamiast po prostu
1/liczba_potencajlnych_haseł
jak będzie przy różnych solach.

pzdr
bartekltg