On 12.11.2014 10:47, Krzychu wrote:
> 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.

Jasne.


> 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.

Obawiam się, że tego nie robi, w koncu w kodzie napisali, że to
bardzo dobre bardzo losowe liczby. ;-)

A na serio, jeśli gdzieś w opisie nie ma wyraźnie napisanego:
w tej linijce i tym pliku podmień to a to, cieżko oczekiwać
od każdego użytkownika przeczytania całego kodu.

> 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.

Przychodzi mi do głowy tylko to, że też jest krótki.

pzdr
bartekltg