![]() |
![]() ![]() |
![]() |
![]()
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. |
|
|
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 910 Pomógł: 44 Dołączył: 20.02.2008 Skąd: Łódź Ostrzeżenie: (20%) ![]() ![]() |
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
|
|
|
![]()
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??
|
|
|
![]()
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)
|
|
|
![]()
Post
#5
|
|
Grupa: Zarejestrowani Postów: 910 Pomógł: 44 Dołączył: 20.02.2008 Skąd: Łódź Ostrzeżenie: (20%) ![]() ![]() |
no jezeli dasz warunek to np. zwyklemu klientowi nie pokaze sie panel admina czy tam pracownika
|
|
|
![]()
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 |
|
|
![]()
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 ?
|
|
|
![]()
Post
#8
|
|
Grupa: Zarejestrowani Postów: 189 Pomógł: 13 Dołączył: 20.09.2008 Skąd: Lublin 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 ? co do soli - nie wiem o co chodzi ![]() 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 |
|
|
![]()
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. |
|
|
![]()
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.
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 ![]() Ten post edytował sowiq 22.09.2008, 12:45:57 |
|
|
![]()
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.
|
|
|
![]() ![]() |
![]() |
Aktualny czas: 21.08.2025 - 13:39 |