Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [PHP][HTML][MYSQL] Bezpieczeństwo logowania
Forum PHP.pl > Forum > Przedszkole
czychacz
Mam dylemat: nie wiem na ile i czy w ogóle bezpieczny jest system logowania na stronkę, którą tworzę.
Sprawa wygląda tak:
Na stronie głównej jest formularz (pole "nazwa usera" i "hasło") i link do strony logowania dla pracownika (formularz taki jak wyżej). Zacznę od opisu logowania dla klienta (strona główna).
Po kliknięciu na Zaloguj użytkownik zostaje przekierowany do skryptu logowania (dla klientów).
Skrypt działa następująco:
1. rozpoczyna sesję i otwiera połączenie z bazą MySQL za pomocą danych zawartych w pliku config.php (nazwa usera, hasło, adres bazy, nazwa bazy).
2. pobiera dane użytkownika wpisane w formularzu (przez $_POST).
3. wyszukuje nazwę użytkownika i hasło zaszyfrowane funkcją md5 w tabeli "klienci".
4. jeśli dane pasują, zapisuje nazwę użytkownika i ID w tablicy $_SESSION (pola "nazwa" i "idklienta"), a potem przekierowuje do następnego skryptu (skryptu głównego dla klienta). w przeciwnym razie pokazuje komunikat.
skrypt główny dla klienta:
1. przy każdym załadowaniu skrypt sprawdza czy istnieją wpisy "nazwa" i "idklienta" w tablicy sesji.
2. jeśli tak to w nagłówku strony wyświetla te dane.
3. przetwarza kolejne operacje, jakie chce wykonać klient.
4. jeśli nie ma pól "nazwa" i "idklienta", bądź są puste lub zawierają nieprawidłowe dane - następuje przekierowanie na stronę logowania.

teraz opiszę, co robią skrypty dla pracowników.
logowanie:
1. j.w.
2. j.w.
3. j.w. tyle, że z tabeli pracownicy.
4. jeśli dane pasują, zapisuje nazwę użytkownika i ID w tablicy $_SESSION (pola "nazwa" i "idpracownika"), a potem przekierowuje do następnego skryptu (skryptu głównego dla pracownika). w przeciwnym razie pokazuje komunikat. (zmienia się nazwa pola w tablicy ("idpracownika")).
skrypt główny dla pracowników:
1. przy każdym załadowaniu skrypt sprawdza czy istnieją wpisy "nazwa" i "idpracownika" w tablicy sesji.
2. j.w.
3. j.w.
4. jeśli nie ma pól "nazwa" i "idpracownika", bądź są puste lub zawierają nieprawidłowe dane - następuje przekierowanie na stronę logowania.


Teraz główne pytanie: czy klient może w jakiś sposób uruchomić skrypty dla pracowników w taki sposób, aby wykonywane były tak, jakby uruchomił je pracownik?
Chodzi mi głównie o bezpieczeństwo, dlatego pytam i liczę na wyczerpujące odpowiedzi.
Mlodycompany
dodaj sobie w sesji poziom i po zalogowaniu zapisuj to, a na stronach sprawdzaj jaki user zalogowany ma poziom i do tego poziomu wyswietlaj dane
czychacz
jak bardzo pomoże to w zabezpieczeniu??
WojtasSP320
Ja zmieniłbym jeszcze md5 na sha1 - generuje dłuższy klucz publiczny, a używa się go tak samo: sha1(string)
Mlodycompany
no jezeli dasz warunek to np. zwyklemu klientowi nie pokaze sie panel admina czy tam pracownika
czychacz
zmiana na sha1 nie będzie problemem w bazie danych mam 64 znaki na hasło

macie jeszcze jakieś pomysły jak to bardziej zabezpieczyć??

nie macie już więcej zastrzeżeń co do tego systemu logowania? bardzo mi zależy na jego bezpieczeństwie, więc dobrze by było, gdybyście napisali coś więcej
golaod
Można by się do wielu rzeczy przyczepić. Czemu brak soli ? W końcu to też ważne. A gdzie obsługa sytuacji gdy ktoś ma wyłączone cookie ? Chcesz wtedy sesid przesyłać GET'em ?
czychacz
Cytat(golaod @ 22.09.2008, 11:40:30 ) *
Można by się do wielu rzeczy przyczepić. Czemu brak soli ? W końcu to też ważne. A gdzie obsługa sytuacji gdy ktoś ma wyłączone cookie ? Chcesz wtedy sesid przesyłać GET'em ?

co do soli - nie wiem o co chodzi blink.gif
co do obsługi strony z wyłączonymi cookie - nad tym musze się jeszcze zastanowić, bo nie tylko informacje sesji są tam przechowywane. poza tym nie wiem gdzie wtedy miałbym przechowywać te informacje, które nie powinny być edytowane po zalogowaniu (np. idpracownika, idklienta, nazwa logowania, hasło, itp...), dlatego właśnie proszę o jakieś podpowiedzi
golaod
Wtedy jedną z możliwości jest wrzucanie tego do bazy sql lub do pliku.
Poszukaj sobie o dodawaniu soli do md5 lub sha1 taka lepsza wersja zabezpieczenia by ktoś kto chce np. użyć tęczowych tablic do łamania haseł miał spory problem. bo ktoś poda np hasło "lol" które przypuśćmy zmieni się w "asd9SDh23287aASHdJs" a dzięki temu, że dodasz sól np "lol"+"tru" czyli "loltru" hash będzie już wyglądał kompletnie inaczej.
sowiq
Ale weź pod uwagę, że sens ma stosowanie długiej soli, np.
  1. <?php
  2. $sol = 'ToJestSoolMojegoWspanialegoPortalikuODupieMaryni';
  3. $haslo = $_POST['pass'];
  4. $zakodowane = sha1($haslo . $sol)
  5. ?>

Wtedy masz nikłe prawdopodobieństwo, że ktoś wrzucił do tęczowych tablic takiego hash'a, a łamanie BF nie wchodzi raczej w grę przy takiej długości.

Co do bezpieczeństwa:
1) dane, które przechowujesz w cookies - zapisz do sesji
2) w danych sesji przechowuj IP, z którego nastąpiło zalogowanie
3) jeśli user ma wyłączone cookies, SID przesyłaj za pomocą $_GET, wtedy przyda Ci się punkt (2)
[za każdym przeładowaniem oprócz stanu zalogowania sprawdzaj z jakiego IP przyszło zapytanie. Jeśli IP z sesji różni się z tym z zapytania to wiesz, że ktoś sobie "pożyczył" sid Twojego użytkownika - wtedy po prostu dla bezpieczeństwa robisz wylogowanie/blokowanie tego podejrzanego IP itp.]
4) zainteresuj się funkcją session_regenerate_id() - nawet po poznaniu ID sesji, intruz niewiele zdziała, bo to ID jest ważne tylko do kolejnego przeładowania strony. Potem generowane jest zupełnie nowe. Jeśli połączysz to z pkt. (2), to będzie dosyć bezpiecznie.

Mnogość zabezpieczeń tak na prawdę zależy tylko od pomysłowości, ale przedstawiłem Ci takie, które wydały mi się najbardziej oczywiste w tym przypadku smile.gif
czychacz
dzięki za odpowiedź. dzisiaj już nie dostanę się do serwera, ale jak tylko będę mógł to zmienię wszystko.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.