On Thursday, November 13, 2014 1:00:18 AM UTC+1, bartekltg wrote:
> 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ę:
Właśnie to jest bardzo istotne czy należy autora rozumieć dosłownie, czy
może chodzi o to, że stała sól nie utrudnia ataku tablicami tęczowymi.


> 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,
Szkoda że nie uzasadniają.

> liczba_haseł_w_bazie/liczba_potencajlnych_haseł
Tak, co do tego nie straciłem pewności w trakcie rozmowy. Natomiast
straciłem pewność czy tylko(!) rożna sól uniemożliwia atak tęczowymi
tablicami.


> na trafienie w jakis hash. Zamiast po prostu
> 1/liczba_potencajlnych_haseł
> jak będzie przy różnych solach.
Tak, to jest jasne. W przypadku takiej samej soli dla wszystkich hasel, mozemy
wrzucic zakodowane hasla do hash-table i sprawdzac tak jakby równolegle
dla wszystkich haseł na raz. Wiadomo, dostęp do dużej hash-table jest z
10-50 razy wolniejszy niż do jednego hasła, ale w przypadku miliona
użytkowników to nadal duże przyspieszenie.


Pozdrawiam