Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

 
Reply to this topicStart new topic
> [PHP][HTML][MYSQL] Bezpieczeństwo logowania
czychacz
post
Post #1





Grupa: Zarejestrowani
Postów: 189
Pomógł: 13
Dołączył: 20.09.2008
Skąd: Lublin

Ostrzeżenie: (0%)
-----


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.
Go to the top of the page
+Quote Post
Mlodycompany
post
Post #2





Grupa: Zarejestrowani
Postów: 910
Pomógł: 44
Dołączył: 20.02.2008
Skąd: Łódź

Ostrzeżenie: (20%)
X----


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
Go to the top of the page
+Quote Post
czychacz
post
Post #3





Grupa: Zarejestrowani
Postów: 189
Pomógł: 13
Dołączył: 20.09.2008
Skąd: Lublin

Ostrzeżenie: (0%)
-----


jak bardzo pomoże to w zabezpieczeniu??
Go to the top of the page
+Quote Post
WojtasSP320
post
Post #4





Grupa: Zarejestrowani
Postów: 87
Pomógł: 13
Dołączył: 13.08.2008
Skąd: Chełmno

Ostrzeżenie: (0%)
-----


Ja zmieniłbym jeszcze md5 na sha1 - generuje dłuższy klucz publiczny, a używa się go tak samo: sha1(string)
Go to the top of the page
+Quote Post
Mlodycompany
post
Post #5





Grupa: Zarejestrowani
Postów: 910
Pomógł: 44
Dołączył: 20.02.2008
Skąd: Łódź

Ostrzeżenie: (20%)
X----


no jezeli dasz warunek to np. zwyklemu klientowi nie pokaze sie panel admina czy tam pracownika
Go to the top of the page
+Quote Post
czychacz
post
Post #6





Grupa: Zarejestrowani
Postów: 189
Pomógł: 13
Dołączył: 20.09.2008
Skąd: Lublin

Ostrzeżenie: (0%)
-----


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

Ten post edytował czychacz 21.09.2008, 15:18:00
Go to the top of the page
+Quote Post
golaod
post
Post #7





Grupa: Zarejestrowani
Postów: 419
Pomógł: 42
Dołączył: 12.08.2008
Skąd: Wrocław

Ostrzeżenie: (0%)
-----


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 ?
Go to the top of the page
+Quote Post
czychacz
post
Post #8





Grupa: Zarejestrowani
Postów: 189
Pomógł: 13
Dołączył: 20.09.2008
Skąd: Lublin

Ostrzeżenie: (0%)
-----


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
Go to the top of the page
+Quote Post
golaod
post
Post #9





Grupa: Zarejestrowani
Postów: 419
Pomógł: 42
Dołączył: 12.08.2008
Skąd: Wrocław

Ostrzeżenie: (0%)
-----


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.
Go to the top of the page
+Quote Post
sowiq
post
Post #10





Grupa: Zarejestrowani
Postów: 1 890
Pomógł: 339
Dołączył: 14.12.2006
Skąd: Warszawa

Ostrzeżenie: (0%)
-----


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

Ten post edytował sowiq 22.09.2008, 12:45:57
Go to the top of the page
+Quote Post
czychacz
post
Post #11





Grupa: Zarejestrowani
Postów: 189
Pomógł: 13
Dołączył: 20.09.2008
Skąd: Lublin

Ostrzeżenie: (0%)
-----


dzięki za odpowiedź. dzisiaj już nie dostanę się do serwera, ale jak tylko będę mógł to zmienię wszystko.
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 Użytkowników czyta ten temat (1 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 



RSS Aktualny czas: 21.08.2025 - 13:39