Solenie haseł

0

Mam pytanie odnośnie solenia haseł. Czy może to być tak , że podczas rejestracji koduje hasło np sha1 i dodaje do niego sól co jest np obecną datą ? A w bazie to się zapisuje jako hasło a sól to data rejestracji. Czy takie coś może być ?

A i drugie pytanie odnośnie zabezpieczeń. Jeśli w cookies bym przechowywał jakieś identyfikatory sesji a w bazie danych już tą realną sesję to nie obciąży to za bardzo systemu? Da się jakoś tak zrobić aby w normalnych $_SESSION to przechowywać tak aby nie było to do przechwycenia ?

0
no_name napisał(a)

Mam pytanie odnośnie solenia haseł. Czy może to być tak , że podczas rejestracji koduje hasło np sha1 i dodaje do niego sól co jest np obecną datą ? A w bazie to się zapisuje jako hasło a sól to data rejestracji. Czy takie coś może być ?

Jeśli "obecna data" i "data rejestracji" są takie same, to tak. Pamiętaj tylko, że salt musi być znany w postaci niezakodowanej w momencie testu hasła.

no_name napisał(a)

A i drugie pytanie odnośnie zabezpieczeń. Jeśli w cookies bym przechowywał jakieś identyfikatory sesji a w bazie danych już tą realną sesję to nie obciąży to za bardzo systemu? Da się jakoś tak zrobić aby w normalnych $_SESSION to przechowywać tak aby nie było to do przechwycenia ?

Tu nie wiem zbytnio o co Ci chodzi. Możesz przechowywać w bazie sesję (np. jakiś obiekt z danymi sesji), ale musisz skądś wiedzieć do której sesji przypiąć dane połączenie. Robisz to identyfikatorem sesji. Natomiast nie wiem co chcesz trzymać w "normalnych $_SESSION".

0

Solenie odbywa się przed haszowaniem. Sól powinna być dość długa (powiedzmy minimum 20 losowych znaków z base64) i zapisana w bazie czystym tekstem.

Edit:
Za późno :p

0

dodaje do niego sól co jest np obecną datą ?
sól powinna być raczej losowa, i różna dla różnych użytkowników. zdecydowanie nie powinna się dawać z góry przewidzieć - a datę można przewidzieć z dowolnym wyprzedzeniem.
w ten sposób atakujący może zapuścić liczenie tęczowych tablic, niech mu to zajmie nawet miesiąc, po czym dokładnie tego dnia dla którego liczył tablice system będzie jego.

0

Chodzi mi po prostu o to by nie obciążać bazy. No mam identyfikator sesji w ciasteczku. A w $_SESSION trzymam te dane które również tak samo mógłbym trzymać w bazie danych. Będzie to chyba oszczędniejsze dla bazy jednak czy tak samo bezpieczne ?

0

Skoro sól ma być taka długa to mam i ją zapisac w postaci zakodowanej ? Bo hasło wiadomo z solą. No ale też nie moze byc bóg wie ile tych znaków.

0
Azarien napisał(a)

sól powinna być raczej losowa, i różna dla różnych użytkowników.

Losowa być nie musi. Różna, zdecydowanie. Soli się w celu wygenerowania różnych haszy dla tego samego hasła. User A może mieć takie samo hasło jak user B i bez soli hasze byłyby identyczne. Znając hasło usera B, znamy wtedy hasło usera A (i na odwrót).

Azarien napisał(a)

zdecydowanie nie powinna się dawać z góry przewidzieć - a datę można przewidzieć z dowolnym wyprzedzeniem.

Obawiam się, że mylisz salt z np. wektorem. Sól musi być znana dla systemu autoryzującego. Np. PAM dokleja sól w postaci jawnej do hasha: $sól$hash$
Nie ma zatem co przewidywać, gdyż salt jest jawny.

0

Skoro sól ma być taka długa to mam i ją zapisac w postaci zakodowanej

Sól zapisujesz czystym tekstem! Jak ją zakodujesz nieodwracalnie to jak potem sprawdzisz zgodność hasła z haszem?

Nie ma zatem co przewidywać, gdyż salt jest jawny.

Azarienowi chodziło o to, że sól jest przewidywalna, a nie jawna. Załóżmy, że data rejestracji jest solą i atakujący chce zaatakować jakiś mało znany (jeszcze) ale interesujący serwis. Liczy tęczowe tablice np dla daty tydzień w przód, a potem wysyła serwis na digga czy slashdota. Zakładając, że się wstrzeli z przewidzianą datą rejestracji kont, łamanie haseł będzie bardzo łatwe.

0
Wibowit napisał(a)

Azarienowi chodziło o to, że sól jest przewidywalna, a nie jawna. Załóżmy, że data rejestracji jest solą i atakujący chce zaatakować jakiś mało znany (jeszcze) ale interesujący serwis. Liczy tęczowe tablice np dla daty tydzień w przód, a potem wysyła serwis na digga czy slashdota. Zakładając, że się wstrzeli z przewidzianą datą rejestracji kont, łamanie haseł będzie bardzo łatwe.

Racja. Niedoczytałem, że chodzi o TT. Chyba pora iść spać.

0

No dobra wymyśliłem tak sobie na szybkości.

  • Mam jakiś stały tekst np. "Lubie mleko" ( zapisany gdzieś w pliku konfiguracyjnym ) , przepuszczam go np. przez md5.
  • Kolejnym krokiem jest zapisanie unikalnego ciągu znaków również zakodowanego jakimś tam algorytmem ( Będzie to zapisane w DB bo gdzieś trzeba zapisać ) .
  • Pobranie daty rejestracji w formacie unixowym.

Teraz łącze wszystkie 3 powyższe czynności z hasłem które przepuszczam np. przez md5.

Czy ten algorytm/sposób już wzbudza większe szanse powodzenia ?

0

Po co tak kombinować?

  1. Generujesz sól za pomocą sól = base64(random) gdzie random zwraca losową liczbę np 100-bitową, albo i większą,
  2. Zapisujesz do bazy dwie rzeczy: otrzymaną sól czystym tekstem oraz np base64(md5(sól + hasło)).
  3. Przy uwierzytelnianiu użytkownika obliczasz base64(md5(sól_pobrana_z_bazy + hasło_podane_w_formularzu_logowania)) i sprawdzasz z zapisaną w bazie wartością.

Edit:
Zamiast md5 lepiej użyć sha1 lub sha256/ sha512.

0

Po prostu generuj ~200 znaków sól przy rejestracji (np. pare sha512(random) sklejonych z jednym saltem z konfiguracji (zapisanym nie-w-bazie-danych)) a do hashowania używaj pbkdf2 z min 500 przebiegów. Nie ma co wymyślać koła od nowa, w dodatku słabo okrągłego.

0

uważam, że sha1 jest na tyle dobry, że te całe sole to niepotrzebne robienie sobie roboty. lepiej skupić się na tym żeby atakujący nie dostał w żaden sposób hashy

0

Solenie jest właśnie po to, żeby w przypadku wycieku zhaszowanych haseł nie dało się ich łatwo odtworzyć. Zakładanie, że twoja aplikacja nie ma dziur pozwalających na wyciek jest bardzo naiwne i naraża użytkowników na niebezpieczeństwo. A wpadki z wyciekami zhaszowanych haseł zdarzały się największym. I niektórzy właśnie haseł nawet nie solili.

W ogóle jeśli zakładasz, że atakujący nie może się dostać do haseł to po co je haszować? Dla picu?

0

po to żeby w razie wycieku nie ułatwiać atakującemu. ale po to ktoś wymyślił algorytmy hashujące, żeby już bardziej nie kombinować

1

Algorytmy haszujące nie wymyślono po to, aby haszować hasła. ROTFL. Haszowanie haseł to tylko jedna z pierdyliarda różnych zastosowań haszy.

Atakujący może włamać się do systemu i wyciągnąć nie tylko całą zawartość bazy danych, ale też wszystkie kody źródłowe. Security by obscurity w takim przypadku będzie dla atakującego zbawieniem.

0

Bardzo dziękuje za pomoc szczególnie Wibowitowi :) Jeszcze jednej odpowiedzi tylko nie dostałem.

  • Użytkownik się loguje ( z użyciem wspaniałego algorytmu solenia haseł :D )
  • Dostaję jego id , login , uprawnienia i zapisuje to w $_SESSION
  • Tworzę ciasteczko z identyfikatorem sesji.
  • Działam.

Czy to mądre rozwiązanie ? Identyfikator sesji pewnie też pasuje jakoś zakodować? A może lepiej robić to w podobny sposób lecz nie zapisywać w sesjach tylko w bazie danych ? Ale np. za każdym odświeżeniem strony lub np. dodaniem nowego posta będzie pobierane to z bazy danych aby identyfikować użytkownika :/

0

Kodowanie identyfikatora sesji, moim zdaniem, jest bez sensu. Jeśli łączysz się przez HTTPS to i tak nikt nie może podejrzeć identyfikatorów sesji, a jeżeli zwykłym HTTP to i tak atakujący może przejąć sesję.

Jeśli twój serwis ma mieć jakieś płatne opcje, to polecam zdobyć certyfikat SSL i postawić serwis wyłącznie na HTTPS (no, może oprócz zawartości dostępnej publicznie, bez logowania). W takim wypadku może też stać się ofiarą phishingu, więc dobrze byłoby poinformować użytkowników, aby nie wysyłali swoich haseł czy loginów mejlem, aby nie klikali w linki w mejlach i aby upewnili się, że adres strony jest poprawny, ew wpisywali zawsze ręcznie.

0

Więc jak zabezpieczyć się jeżeli korzystam ze zwykłego HTTP ?

1

na jedno wychodzi czy zapiszesz to w sesjach czy w bazie danych
standardowe sesje to też takie "bazy danych" tylko że na zwykłych plikach tekstowych, możesz użyć funkcji session_set_save_handler tak żeby dane sesji zapisywały się w bazie danych - ale poziomu bezpieczeństwa to nie zwiększa

jeżeli chcesz się zabezpieczyć przed przejęciem sesji to:

  1. Użyj połączenia SSL, ciasteczkom nadaj parametry secure oraz httpOnly
  2. Sesję przypisz do konkretnego IP, nie ustawiaj zbyt długiego czasu sesji
  3. Generuj nowy identyfikator sesji po każdym odwołaniu (session_regenerate_id(true) tuż za session_start())

rozwiązania możesz ze sobą łączyć, ale:
użycie pierwszego rozwiązania wymaga wykupienia certyfikatu,
użycie drugiego rozwiązania uniemożliwia zapamiętanie hasła użytkownikom ze zmiennym IP;
użycie trzeciego rozwiązania powoduje że identyfikatory sesji są jednorazowe i działają jak tokeny - atakujący musiałby przechwycić identyfikator i spieszyć się z wykorzystaniem go przed użytkownikiem - może to jednak stwarzać pewne problemy - nowe ciasteczko z nowym identyfikatorem jest wysyłane przy każdym odwołaniu do strony, zwiększa to obciążenie serwera i w przypadku równoległych zapytań przez przeglądarkę jedno z zapytań może się zakończyć niepowodzeniem bo zostanie wysłane jeszcze ze starym identyfikatorem

pozdr

1

Serwisy, które wyciągają kasę od internauty mają opcję albo wymuszają połączenia poprzez HTTPS i to jest w zasadzie jedyne słuszne rozwiązanie w takim przypadku. Serwisy, które nie wyciągają kasy od internauty zwykle się przed phishingiem czy przechwytywaniem sesji nie zabezpieczają (vide np 4p) - co nie znaczy, że to jest dobre.

Małych serwisów raczej się nie atakuje, a HTTPS nie musi byś wspawany w serwis od razu. Jeśli zauważysz, że serwis odnosi sukces i generuje sensowne obroty, to wtedy możesz kupić certyfikat.

0
krwq napisał(a)

uważam, że sha1 jest na tyle dobry, że te całe sole to niepotrzebne robienie sobie roboty. lepiej skupić się na tym żeby atakujący nie dostał w żaden sposób hashy

Po co w ogóle hashować, a w ogóle to po co się przejmować dobrymi hasłami. Przecież hasła typu 1qaz3edc i tak nikt nie zgadnie.

0
alligotisthisnick napisał(a)
krwq napisał(a)

uważam, że sha1 jest na tyle dobry, że te całe sole to niepotrzebne robienie sobie roboty. lepiej skupić się na tym żeby atakujący nie dostał w żaden sposób hashy

Po co w ogóle hashować, a w ogóle to po co się przejmować dobrymi hasłami. Przecież hasła typu 1qaz3edc i tak nikt nie zgadnie.

po co w ogóle hasła, wystarczy odpowiednio skomplikowany login ;)

0
fretgert napisał(a)
alligotisthisnick napisał(a)
krwq napisał(a)

uważam, że sha1 jest na tyle dobry, że te całe sole to niepotrzebne robienie sobie roboty. lepiej skupić się na tym żeby atakujący nie dostał w żaden sposób hashy

Po co w ogóle hashować, a w ogóle to po co się przejmować dobrymi hasłami. Przecież hasła typu 1qaz3edc i tak nikt nie zgadnie.

po co w ogóle hasła, wystarczy odpowiednio skomplikowany login ;)

a może najlepiej , żeby ludzie mogli się logować dopiero po zadzwonieniu do siedziby firmy która jest właścicielem strony lub do automatu ? Lub lepiej logować można się tylko w kafejce która znajduję się w owej siedzibie ;p

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