Forum PHP.pl

Sól to przeważnie ciąg znaków dopisywany do hasła. Sam decydujesz, czy sól dopiszesz do hasła już zakodowanego i później zakodujesz je ponownie, czy dopiszesz ją do do hasła podanego przez użytkownika i zakodujesz jednokrotnie. Sól może być wspólna dla wszystkich użytkowników, a może być też unikalna dla każdego z osobna i wtedy przechowujesz ją w bazie danych obok pozostałych danych do logowania.
Zamiast md5 używaj sha1.
Nie powinieneś sprawdzać, czy pierwszym znakiem hasła jest cyfra, czy litera, a tym bardziej jaka to litera, czy cyfra - hasło to prywatna sprawa użytkownika.

Im bardziej "niestandardowy" skrypt hashujący, tym lepiej. Gdyby był jeden genialny, to by już przestał być genialny, bo pod niego by pisano łamacze

Możesz losowo wybierać metodę. Przykładowo gdy ktoś wpisuje login i hasło, sprawdzasz obecność loginu w bazie. Gdy jest, pobierasz rekord i dane z nim związane. Mogą one zawierać informacje o indywidualnej soli, typie algorytmu hashującego czy wszelkich ustawionych dla danego konta rzeczach niestandardowych. Na ich podstawie sobie ustawiasz co idzie do algorytmu hashującego i jego wyjście porównujesz z hashem zapisanym w bazie.

Trzymanie haseł w bazie w formie zaszyfrowanej ma służyć temu by w razie wycieku rekordów nie znane było hasło oraz po to by nie wykorzystywać takiego hasła w innych serwisach (przy założeniu, że użytkownik ma takie samo hasło na przykład na poczcie, w banku i w naszym portalu znając jego hasło można nieźle namieszać).

Używanie "soli" jest jak najbardziej wskazane jak i korzystanie z dłuższego sha1. Ale czy jest sens w przechowywaniu w bazie w rekordzie user'a danych dotyczących "soli" albo jej samej? To w sumie nic nie daje poza tym, że podpowiada włamywaczowi jak łamać hasło.

Ja zawsze trzymam SALT gdzieś głęboko w kodzie - wszędzie jest jednakowy i nie za krótki (przynajmniej z 256 znaków).

Zastanówmy się nad taką sytuacją w 3 podejściach:

1. Bez soli

Ktoś zdobywa hasło usera z bazy. User ma hasło numeryczne na przykład 123456 - przelecenie przez wszystkie kombinacje numeryczne md5 lub sha1 nie trwa tak strasznie długo - pyk - mamy hasło

2. Z solą w bazie

Ktoś zdobywa hasło usera i salt usera - ta sama opcja hasło nuemryczne - do każdego dodajemy salt przed lub za i testujemy - trochę dłużej to potrwa ale i tak pewnie znajdziemy to hasło.

3. Z solą poza bazą

Ktoś zdobywa hasło usera i.... no właśnie i co? Może próbować, kombinować a i tak nic mu po tym - jeśli salt jest odpowiednio długi to małe szanse są na to by kiedykolwiek zdobyć hasło - fartem chyba

Podsumowując IMHO nie ma sensu bawić się w przypiswanie saltów indywidualnych dla userów, rotacji sha1/md5... wystarczy sha1, mocny i dobrze ukryty salt i po srpawie

I popieram @Thek'a - własny algorytm (przemyślany) to też dobre rozwiązanie

Ten post edytował Sephirus 27.12.2011, 12:36:11

@Sephirus... SALT jedynie w bazie to za mało. Najlepiej mieć zarówno salt indywidulany dla usera i jeden ogólny dla serwisu a stosować oba jednocześnie. Czemu? Gdy Ci podwędzą kod serwisu to znają SALT hasła z serwisu i algorytm, ale nie znają soli indywidualnych, więc hasła są teoretycznie dalej trudne do ustalenia. Jeśli podwędzą bazę, to nie znają ani algorytmu, ani hasha serwisu, więc też zgaduj-zgadula nadal. Muszą mieć oba te komponenty naraz, aby ustalić hasła, a i tak dla każdego usera musza one być indywidualnie z użyciem "rainbow tables" (o brute force zapomnij ) odczytane. Im bardziej przemyślany algorytm z uzyciem obu soli, tym utrudnienia większe, ponieważ trzeba iść "od tyłu" i porównywać z kolejnymi etapami. Odczyt hasha z poziomu tęczowych tablic da Ci bowiem pulę wyników, którą teraz musisz analizować. A że użyjesz przypuśćmy 2-etapowego hashowania, gdzie na każdym etapie uzyjesz innego algorytmu lub będzie on modyfikowany ustawieniami to utrudniasz w jakiś tam sposób łamanie. Jeśli jesteś super paranoikiem, to zawsze jeszcze możesz jakiś element, konieczny do uzyskania danych wejściowych dla algorytmu hashującego, przenieść na serwer trzeci, który zwraca pewne elementy po SOAPie dla uwierzytelnionego i rozpoznawanego między innymi po IP - serwera Wtedy masz jako utrudnienia aż 3 elementy konieczne do uzyskania/posiadania:
a) kod serwisu,
baza serwisu
c) autoryzacja dla serwera zewnętrznego.

@up no tak tak - absolutnie masz rację - to jeszcze lepsze - ja pisałem jedynie o tym by nie dawać salta "tylko" w bazie To co napisałeś ma spory sens - podwójne zabezpieczenie co do zewnętrznego salta na serwerze zewnętrznym to faktycznie lekkie przegięcie ale w niektórych sytuacjach... może

Czyli dochodzimy do wniosku:

1. salt indywidualny (dla każdego usera w bazie)
2. salt globalny (kod)

szyfrogram to efekt hashowania hasła poprzez 1 a następnie poprzez 2

IMHO ReCaptcha - to zuo - zmusza ludzi do robienia czegoś czego nie chcą i zajmuje wbrew pozorom sporo czasu :/ Dodatkowo poza właśnie google'owską reCaptchą to reszta jest już pozłamywana. - Są inne sposoby na spam, brute force itd.