[php] Losowy ciąg znaków, Dlaczego tak, a nie inaczej? Opcje

[MacDada]

Hej!

Piszę właśnie mechanizm logowania. Po przeczytaniu wielu wątków na tym forum i pogoogle'owaniu tematu postanowiłem „posolić” hasła w bazie. Wykorzystuję do tego taką funkcję:

[PHP] pobierz, plaintext 
function hashPasswd($passwd)
{
	$salt = substr(md5(microtime() . substr($passwd, 1, 3)), 0, 32-strlen($passwd));
	return array('passwd' => MD5($passwd.$salt), 'salt' => $salt);
}
[PHP] pobierz, plaintext 

Szybkie objaśnienie: użytkownik może dać hasło maksymalnie 20-znakowe, ale znając życie będzie ono w stylu „dupa”, więc banalne do odgadnięcia przy użyciu tęczowych tablic. Tak więc biorę aktualny czas jako rzecz w jakimś tam stopniu losową, doklejam 3 litery oryginalnego hasła, haszuję przy pomocy MD5 i ucinam wynik do tylu znaków, ile brakuje hasłu użytkownika do 32 znaków.
W ten sposób powstaje sól, którą doklejam do hasła, które użytkownik podał i dopiero „standardowo” haszuję, by wstawić do bazy.


Podobne rozwiązania widziałem wcześniej w w wielu innych skryptach przy tworzeniu soli czy losowych danych do własnego mechanizmu sesji.
No właśnie, LOSOWYCH. Jeśli generujemy losowe dane, to dlaczego tak często widzę użycie funkcji microtime() zamiast po prostu rand()? Z tego co podaje Wikipedia bardzo dobrze do tego nadaje się linuksowy /dev/random, który śledzi sprzętowe odchylenia, żeby generować losowe liczby - czy można z /dev/random skorzystać w skrypcie php?

Wiem, że nie tworzę skryptu dla NASA czy CIA, ale jeśli mamy do dyspozycji „lepsze” i „gorsze” rozwiązania, to chyba warto wiedzieć takie rzeczy i z nich korzystać...

A jak przy okazji macie jakieś sugestie do mojego mechanizmu „solenia”, to chętnie wysłucham (IMG:style_emoticons/default/winksmiley.jpg) Tylko, żeby to nie przerodziło się w świętą wojnę, czy w ogóle warto solić - poczytałem argumenty obu stron i przy samej idei „solenia” pozostanę (IMG:style_emoticons/default/winksmiley.jpg)

pozdr.

[everth]

@wywrot4 - artykuł fajny, jednak dalej nie widzę sensu by dodawać sól w bazie danych. Z jednego powodu - o wiele łatwiej jest według mnie uzyskać dostęp do bazy niż do skryptu. Ktoś tam sensownie napisał że to likwiduje dodatkowe zabezpieczenie w postaci nieznajomości ciągu soli. Jeśli znamy hash hasła to na 99% poznamy też sól.
Na upartego można napisać algorytm generujący sól z danych w bazie - ale bez zaznaczania z których i w jakiej kolejności (ktoś się tam tak wypowiedział i ja też tak robię). To wszystko jednak można o kant d*py potłuc jak stosuje się hashowanie md5 - znalezienie kolizji dla takiego hashu to kilkanaście godzin - może dla amatorskich programów to bez znaczenia, ale jak ktoś stawia komercyjny projekt to trzeba brać to pod uwagę.
Czyli można zrobić tak:

1. Hasło co najmniej 8 znaków
2. login+hasło (kolejność złączenia dowolna)
3. + statyczna sól umieszczona w kodzie (dla mnie 128 znaków)
4. + dodatkowo zmienna sól generowana z bazy danych (ale nie zapisywana jako osobne pole w bazie)
5. Zastosowanie dobrej funkcji skrótu

Można wymyślić bardziej paranoiczne rozwiązania jednak powyższe na pewno oprze atakom za pomocą tęczowych tablic i nie tak łatwo da się złamać za pomocą znalezienia kolizji.