Forum PHP.pl > system autoryzacji uzytkownika

Pomoc - Szukaj - Użytkownicy - Kalendarz

Pełna wersja: system autoryzacji uzytkownika

xamil

17.05.2006, 06:11:28

Ogólnie jakie metody polecacie aby było dobrze i bezpiecznie;)

Kiedyś dawno temu tak sobie rozpisałem to co wymyśliłem:

Cytat

zdarzenia:
[ok]powitanie "Proszę się zalogować aby uzyskać dostęp do bazy"
[ok]nie_podanie_loginu_lub_hasla -> powitanie -> spróbuj_wylogować_jak_nie_to_trudno;) -> usun_klucz
[ok]wylogowanie_poprawne "Użytkownik "{user_login}" został wylogowany" -> wyloguj -> usun_klucz
wylogowanie_błędne (ktoś naciska np. przycisk wylogowania a już jest wylogowany)
klucz_istnieje
[ok]klucz_poprawny wyświetlamy komunikat "Użytkownik "{user_login}" jest już wylogowany" -> usun_klucz
[error]klucz_niepoprawny "Próba nieautoryzowanego dostępu do bazy" i -> odrzuc_ip (Musi to być bo ktoś może przelecieć wszystkie klucze a przez to zamykać uzytkownikom dostęp do serwisu. Mało tego wyłapie klucze.)
[ok]klucz_sesji_nie_istnieje -> powitanie
błędne_logowanie
[error]błędny_login "Błędny "Użytkownik" lub "Hasło"" -> odrzuc_ip
[error]błędne_hasło -> błędny_login -> odrzuc_uzytkownika (to będzie max jakieś 5 prób) -> odrzuc_ip
[ok]brak_aktywności "Brak aktywności przez co najmniej "{sekundy}" sekund, proszę się zalogować ponownie" -> wyloguj -> usuń klucz
[ok]proba_wejscia_do_systemu_bez_klucza najpierw sprawdzam przez cookie lub $_GET czy klucz istnieje i jak nie to -> powitanie
[error]proba_wejscia_do_systemu_z_błędnym_kluczem ->(wylogowanie_bledne->klucz_istnieje->klucz_niepoprawny) -> odrzuc_ip
proba_wejscia_na_zablokowane_konto
[error]błędne_hasło "Dostęp do bazy z tego IP został zablokowany, proszę spróbować ponownie {Y-m-d} o {H:i}" -> odrzuc_uzytkownika -> odrzuc_ip
[error]poprawne_dane "Dostęp do bazy z tego IP został zablokowany, proszę spróbować ponownie {Y-m-d} o {H:i}"
[error]proba_wejscia_z_zablokowanym_ip ->(próba_wejscia_na_zablokowan_konto->błędne_hasło) oraz każde odświerz powoduje -> odrzuc_ip
[error]błędne_ip ->odrzuć_ip "Błędne IP, proszę zalogować się ponownie" nie wylogowywać!

Znaczniki error i ok to to czy straszymy użytkownika że wystąpił błąd i po drugie czy podejmujemy środki zabezpieczające np. dodanie ip. do listy banowanych ip. Oczywiście musi zostać przekroczona określona ilość prób.

Czyli głównie chodzi o to, że przechowujemy klucz sesji danej osoby w bazie i porównujemy z tym kluczem którym przedstawia się user. Jeśli się nie zgadza to oczywiście się nie dostaje oraz jego ip dostaje się na czarną liste ip.

Co wy o tym sądzicie? Jak wy byście to rozegrali? Czyli jak zabezpieczyć i autoryzowac user'ow?

mike

17.05.2006, 08:13:28

Przenoszę z php Pro na php.

Master Miko

17.05.2006, 11:08:28

1. No oczywiście... używanie sesji to dobry pomysł... ale robisz je na bazie danych czy zostawiasz na plikowych?
2. Czasowe zablokowanie po np. 5 nieudanych próbach to dobry pomysł. W moim życiu pomyliłem się w logowaniu kiedyś 4 razy

3. Zabezpieczenia wylogowania są trochę nie potrzebne, bo możesz np. sprawdzać czy gościu jest zalogowany.. jeśli nie używać headera do logina. Małoprawdopodobne jest że użytkownik wejdzie na logout nie będąc zalogowanym.. bo nie będzie miał jak (chyba że udostępnisz mu nie znikający przeycisk "wyloguj się"). Tego będzie mógł dokonać tylko przez manualne wpisanie adresu do przeglądarki... wtedy blokowanie może być potrzebne: po np. 7 takich próbach może nastąpić ban na jakiś czas.
4. Brak aktywności to dobry pomysł. Po 3 minutach header do strony wylogowania.

Tzn cały ten system można podsumować tak:
- po 5 nieudanych próbach zalogowania = ban czasowy
- po 7 wylogowaniach bez zalogowania = ban czasowy

ps. Chcesz za każdym razem jak user chodzi po stronie sprawdzać czy jest zarejestrowany? Moim zdaniem to zły pomysł. Bardzo zawali bazę danych. Lepiej te dane czy user jest zarejestrowany trzymać w sesji.
Czyli przy loginie raz sprawdzić czy user istnieje w bazie... potem w sesji ustalić, że jest zalogowany.

xamil

18.05.2006, 07:18:17

Odp. do p.s.

Tak. Gdy użytkownik coś kliknie i pośle żądanie to zanim cokolwiek sie wykona to sprawdzam czy klucz sesji jakim się przedstawia pasuje do klucza w bazie danych.

Generalnie podobny system mam już postawiony tylko brakuje mu sporo rzeczy ktore tu wymienilem. Ciężko mi jednak powiedzieć czy jest wolny czy nie bo w godzinach szczytu korzysta z niego góra 5 osob;)

Pytanie właśnie czy i jak innaczej bronić się np. przed próbą przejęcia klucz'a sesji php? Tzn. ktoś może sobie zapuścić skrypt który będzie generował wszystkie możliwe kombinacje jakie moze uzyskać klucz php i będzie przedstawiał sie takim ciastkiem i a nuż mu się uda?

Generalnie jak powinno się zabezpieczyć przed przejęciem klucza sesji? Logowanie to pikus. Jak wcześniej zostało wspomnniane - ban czasowy na dany ip.

Master Miko

18.05.2006, 10:04:32

Mówię Ci że sprawdzanie za każdym razem w bazie danych czy sesja jest prawdłowa mija się z celem. Danych sesji NIE da się zmienić bez ingerencji skryptu php. Wystarczy je raz ustalić. Jak nawet hacker przejąłby id sesjii to co by Ci to dało? Hacker miałby prawidłowe wartości w sesji, które zgadzałyby się z bazą danych i chodził sobie normalnie po stronce.

Sprytnym zabezpieczeniem byłoby trzymanie w sesji adresu IP człowieka który jest zalogowany. Wtedy nawet, gdyby hacker przjął id sesji, skrypt porównałby IP i wykrył włamanie.

Jak bronić się przed przejęciem? Co pewien czas regenerować id sesji... może to dobry pomysł ale na zabezpieczeniach samych sesji dobrze się nie znam. Więc tu daję polę do popisu bardziej zaawansowanym phpowcom

xamil

18.05.2006, 10:46:28

Cytat

Właśnie. Chodzi o to, że sprawdzając automatcznie podbijałbym licznik prób wejścia z błędnym kluczem z tego ip. Przy powiedzmy 100 odrzucałbym to ip na powiedzmy 2h. Bez tego gościu może zapuścić skypt i łączyć się bez końca.

Cytat

Sprytnym zabezpieczeniem byłoby trzymanie w sesji adresu IP człowieka który jest zalogowany. Wtedy nawet, gdyby hacker przjął id sesji, skrypt porównałby IP i wykrył włamanie.

Tak. Wziąłem to pod uwage. Ostatnia linijka (wiem, przepraszam za to że mało czytelne jest to dla osób nie wtajemniczonych;)). Ale nie daje to moim zdaniem dobrego zabezpieczenia bowiem często jedno IP to cały akademik;)

Cytat

Jak bronić się przed przejęciem? Co pewien czas regenerować id sesji... może to dobry pomysł ale na zabezpieczeniach samych sesji dobrze się nie znam.

Fakt. Regenerowanie id sesji napewno zmniejszy prawdopodobieństwo zgadnięcia ID.

Cytat

Więc tu daję polę do popisu bardziej zaawansowanym phpowcom snitch.gif

Właśnie dlatego temat wydawał mi sie dobry na php PRO... No cóż:/

Ogólnie może faktycznie kombinacja regeneracji ID i sprawdzania IP daje wystarczająco małe prawdopodobieństwo na zgadnięcie ID sesji, że nie warto zapisywać klucza do bazy... choć wydaje mi sie że gdzieś widziałem takie rozwiązanie.

Bo co do sprawy samego logowania to wiadomo, że tu nie ma wielkiej logiki. Max. 5 prób błędnego logowania w przeciągu 15minut na dane konto i blokujemy możliwość dalszego logowania z tego ip na to konto. Przy 100 blokujemy całe konto (dla dobra użytkownika). Czy coś w ten deseń.

Ktoś jeszce może doradzi?

Master Miko

18.05.2006, 11:23:20

Cytat

No własnie nie za bardzo!

Wg Ciebie patrz:

Użytkownik loguje się user: a haslo: b -> poprawnie ma id sesji c -> za każdym razem chodzi po stronie i baza danych sprawdza czy ma dobre dane a i b z sesji c
Hacker przechwytuje sesję c -> jego parametrami są a i b -> chodzi po stronie -> baza danych POTWIERDZA, że to jest prawdziwy użytkownik

Jeśli zapiszesz IP w bazie danych to będzie głupie, bo użytkownik np. nie będzie mógł wejść z kafejki internetowej

a teraz jak ja to widzę:

Użytkownik z IP d loguje się (user: a) (haslo: B ). IP o nazwie d zapisuje się w sesji-> poprawnie ma id sesji c -> za każdym razem chodzi po stronie i skrypt sprawdza czy jego aktualny IP ( d ) zgadza się z tym z sesji c -> chodzi normalnie po stronie -> skrypt patrzy czy TYLKO jest ustawiona sesja i jej parametry: login i hasło. Skrypt nie patrzy czy są to poprawne bo sprawdził wcześniej! Nie da się zmienić parametrów sesji bez ingerencji skryptu, więc użytkownik jest 100% legal.

Hacker z IP e przechwytuje sesję c -> jego parametrami są a i b i z sesji parametr d -> chodzi po stronie -> skrypt wykrywa że jego IP e nie jest równe IP z sesji d. Wywala go

Zabezpieczenie na akademika? Regeneracja sesji co 4 ruchy na stronie i automatyczne wylogowanie się po 2 minutach bezczynności

em1X

18.05.2006, 11:25:49

a to chyba nie wiecie hakierzy, ze mozna bez problemu zmodyfikowac naglowek pakietu i ustawic

SOURCE IP ADDR = IP ATAKOWANEJ OSOBY heh

Master Miko

18.05.2006, 11:30:13

Tak to prawda. Ale skąd hacker ma wiedzieć że dokładnie taka osoba z takim IP ma dokładnie ten ID w sesji?

xamil

23.05.2006, 09:41:09

A nie jest czasem tak, że wystarczy sprawdzić przy logowaniu dane (login i hasło) i jeśli poprawne to zapisać w sesji, że jest zalogowany ($_SESSION['loged_in']=1) i nie przejmować się możliwościami przejęcia sesji bo całość puszczamy po SSL'u? O ile się nie myle wtedy nagłówki (łącznie z ciastkami) są szyfrowane.

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.