Hasz + losowy salt - gdzie trzymany jest salt?

Hej. Takie pytanko - mam uzytkownikow w tabeli w bazie, i tam sa trzymane tez hasla. Poki co sa to hasze (aktualnie md5, ale moze powinienem uzywac SHA-512?), i gdy uzser sie loguje, licze hash z hasla ktore wklepie, i je porownuje - standard.
Chcialem jednak dodac salt aby bylo bezpieczniej, w celu np uniemizliwienia zlamania hasla z rainbow tables. I teraz mam kilka pytan:

1. rozumiem ze salt jest losowy, generowany dla usera w czasie rejestracji / tworzenia wpisu w bazie danych?
2. salt jest dodawany przed / po wlasciwym hasle? (czy przed / po ma jakiekolwiek znaczenie?) a moze dzielic haslo na pol i tam wstawiac? czy nie trzeba tak kombinowac? (tak tak wiem ze hasla moga miec nieparzysta liczbe znakow ale to latwo obejsc zaokraglajac pass.length / 2 w dol)
3. zakladam ze salt jest losowy (patrz pytanie 1) - musi byc gdzies zapisany aby system identyfikacji umial poprawnie zlozyc haslo i salt w celu weryfikacji; czy salt moze byc skladowany w tej samej tabelce, w jakiejs specjalnej kolumnie? czy to ma sens z punktu widzenia bezpieczenstwa?

Pozdrawiam.

Sól jest zapisywana "otwartym tekstem" w bazie i najlepiej ją włożyć w kolumnę obok zhaszowanego hasła. MD5 chyba nie jest najbezpieczniejszym haszem (tzn są już jakieś tam szybsze metody łamania niż brute chyba), SHA-512 będzie raczej lepszym wyborem. Nie stosuj zagnieżdżeń haszy np md5(sha1(hasło)), gdyż to pogarsza "entropię" zakodowanego hasła. Haszuj tylko raz i stosuj najlepiej dość długą sól (np co najmniej 20 losowych znaków).

@Wibowit w taki sposób na pewno pogorszysz jak już to sha1(md5(hasło)). Ja kiedyś w moim programie pseudoszyfrującym zrobiłem coś prawie jak One-Time-Pad poprzez użycie SHA1 na haśle, podzieleniu powstałego hasha na 4 części, każdej z części potraktowanie znów SHA1 i tak dalej aż nie uzyskałem odpowiednio długiego hasła :P

Czy jak ktos mi sie wlamie do bazy, znajdzie tabelke z userami, to czy taki jawny salt w jakims stopniu utrudnia zlamanie hasel?
Mi sie wydaje ze tak, poniewaz jest o wiele wiecej kombinacji dla crackera, mimo ze zna ten salt, ale nie jestem pewien, nie znam sie ;d Prosze o zweryfikowanie.

Dlaczego sha1(md5(hasło)) nie pogarsza entropii, ale md5(sha1(haslo)) juz tak?

Obydwa pogarszają. Jeżeli md5 daje X możliwych wyników a sha1 daje Y, gdzie X < Y to zarówno md5(sha1) jak i sha1(md5) mogą dać co najwyżej X możliwych wyników.

sha1(md5) zapewne jest gorsze niż samo md5 gdyż dla pewnych haszy md5 mogą powstawać kolizje po dodatkowym potraktowaniu sha1.

Czy jak ktos mi sie wlamie do bazy, znajdzie tabelke z userami, to czy taki jawny salt w jakims stopniu utrudnia zlamanie hasel?

Choć z początku i mi wydawało się (intuicyjnie), że jawny salt to świętokradztwo, to jednak wychodzi na to, że salta mógłbyś wyświetlać w okienku logowania, a i tak nic by to nie pomogło crackerowi ;)
Dlaczego? Zacznijmy od opowieści czym są rainbow tables :>
Jesteśmy crackerem, który dostał się do naszej bazy danych, wziął z niej loginy i hashe haseł. Wiedząc, że jest skończona liczba możliwych skrótów, generujemy ich sobie sporo z losowych ciągów znaków (tu są jakieś metody optymalizacji tej generacji, ale już ich nie znam). Mając swoje wygenerowane hashe, które wiemy z czego zostały wygenerowane, porównujemy je do tych z bazy danych - pasuje? Kól, wpisujemy ciąg, z którego otrzymaliśmy dany hash i się włamaliśmy!
Warto zauważyć, że wcale nie znaczy to, że zgadliśmy hasło. To był po prostu inny ciąg znaków, który daje ten sam hash.

Dlatego wymyślono sól. Jeśli mamy sól, to wpisanie tego ciągu znaków nic nam nie da, bo program doklei do niego sól, zhashuje - i to będzie inny hash niż ten przez nas uzyskany.
Zastanówmy się, co możemy z tym zrobić. Znając sól, moglibyśmy na przykład generować tak długo hashe, aż znajdziemy taki, który nie tylko jest zgodny z tym z bazy danych, ale jeszcze jest generowany z ciągu znaków, który zaczyna się od tej soli. Ale kto powiedział, że sól będzie dodana na początku....? :)

I to w sumie tyle tego wywodu. Gdy masz hash i sól, to jeszcze za mało - musisz znać sposób doklejania jej do hasła. Stąd ludzie wymyślają różne kombinacje - na końcu, w środku, w dwóch trzecich, na początku ale odwrócony albo bierzemy miesiąc urodzenia użytkownika i dajemy salt na tej pozycji w stringu. Albo mieszamy salt z hasłem (jedna literka stąd, druga stąd...).

Sól jest tylko po to, aby tęczowe tablice nie nadawały się do łamania hasła. Mechanizmy zabezpieczające tworzy się tak, aby były bezpieczne nawet gdy napastnik zna cały mechanizm - w przypadku systemów informatycznych wystarczy wykradzenie kodu źródłowego. Dlatego sposób przechowywania soli czy sposób jej dołączania nie ma znaczenia - ważne, aby sól dla każdego hasła była różna i dość długa. Hasła się haszuje i soli przede wszystkim po to, aby zabezpieczyć hasła, a nie system.

Dodatkowo, dzieki soli dwoch uzytkownikow, ktorzy uzywaja te same hasla bedzie mialo dwa rozne hashe. Napastnik majac liste wykradzionych hashy, nie bedzie mogl stwierdzic, jacy uzytkownicy posiadaja te same hasla do logowania. To jest tez wazny punkt dotyczacy soli.

Dzieki wszystkim za odpowiedzi, duzo mi sie wyjasnilo.