![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 47 Pomógł: 1 Dołączył: 24.06.2010 Skąd: Sopot Ostrzeżenie: (0%) ![]() ![]() |
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ę:
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. |
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 47 Pomógł: 1 Dołączył: 24.06.2010 Skąd: Sopot Ostrzeżenie: (0%) ![]() ![]() |
tak mam to teraz zrobione
Kilka schematów ataku… Poziom 1: Za pomocą SQL-Injection ktoś uzyskał dostęp do bazy danych. Jeśli hasła są widoczne to po zabawie. Stąd minimum to ich haszowanie. Poziom 2: Jeśli użyję MD5 lub innego powszechnego algorytmu to napastnik może użyć tęczowych tablic, żeby uzyskać prawidłowe hasło. Więc hasło musi być albo odpowiednio skomplikowane, żeby za pomocą tablic go nie znaleźć albo mogę do każdego hasła dokleić coś co sprawi, że tablice (raczej) staną się bezużyteczne. Powstaje więc sól. Poziom 3: Napastnik ma dostęp do kodu źródłowego skrypu i tym samym poznaje sól. Wystarczy więc, że ma listę popularnych haseł, podokleja do nich sól i przehaszuje je, żeby dostać hasło. Można mu jednak utrudnić pracę… Poziom 4: Tym utrudnieniem będzie różna sól dla każdego hasła. Zresztą, mechanizm utworzenia soli nie będzie publiczny, więc za pomocą security through obscurity mamy dodatkowe zabezpieczenie… |
|
|
![]() ![]() |
![]() |
Aktualny czas: 14.10.2025 - 03:12 |