Hasz + losowy salt - gdzie trzymany jest salt?

Odpowiedz Nowy wątek
2011-07-24 19:20
szibalba
0

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.

Pozostało 580 znaków

2011-07-24 19:30
0

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


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.

Pozostało 580 znaków

2011-07-24 19:35
0

@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

Pozostało 580 znaków

2011-07-24 19:38
szibalba
0

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?

Pozostało 580 znaków

2011-07-24 20:10
0

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.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
edytowany 1x, ostatnio: Wibowit, 2011-07-24 20:11
Ale jeśli chodzi o celowe wywoływanie kolizji (tzn. łamanie hasła) to np. sha1(md5()) nie jest lepsze? W końcu łamiący nie wie (chyba) jaki hash jest używany więc może próbować łamać hasło przez np. bruteforcowanie md5. - msm 2011-07-25 09:34
Taaaa, to się nazywa wtedy "security through obscurity". W takim wypadku możesz sobie wymyślić jakiegoś własnego badziewnego hasza i go użyć bezpośrednio. Hasła łamie się przede wszystkim dlatego, że ludzie lubią używać tych samych w wielu sytuacjach, więc chyba lepiej nie narażać użytkowników naiwnie myśląc, że nikt twojego kodu nie podejrzy. - Wibowit 2011-07-25 10:39

Pozostało 580 znaków

2011-07-28 15:40
3

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

edytowany 2x, ostatnio: aurel, 2011-07-28 15:50

Pozostało 580 znaków

2011-07-28 16:10
2

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.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.

Pozostało 580 znaków

2011-07-29 10:10
0

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.

Pozostało 580 znaków

2011-07-29 10:42
szibalba
0

Dzieki wszystkim za odpowiedzi, duzo mi sie wyjasnilo.

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0