W dniu 09.11.2014 o 15:51, bartekltg pisze:
> Ciekawy kwiatek
>
> https://github.com/haiwen/ccnet/issues/35
> https://github.com/haiwen/ccnet/blob/master/net/serv
er/user-mgr.c#L612
>
> /* -------- EmailUser Management -------- */
> /* truly random sequece read from /dev/urandom. */
> static unsigned char salt[8] = { 0xdb, 0x91, 0x45, 0xc3, 0x06, 0xc7,
> 0xcc, 0x26 };
>
> I ta tabelka użyta jest przynajmniej w funkcji hash_password_salted.

Nie jest to wcale takie złe. Co prawda gorsze od funkcji skrótu z losową
solą, ale lepsze od funkcji skrótu bez soli.

Atakujący nie posłuży się już ogólnodostępnymi rainbowtables, będzie
musiał wytworzyć własne. A jeśli nie ma dostępu do kodu źródłowego (bo
każda osoba wdrażająca ten kod może sól zmienić na własną) to nawet i
tego nie zrobi.

Ja używam w swoich aplikacjach stałej soli + loginu jako sól. Szukałem
informacji na temat używania loginu jako soli - czy są jakieś
przeciwskazania - ale niestety nic nie znalazłem.