Witam,
Stworzyłem prosty schemat logowania oparty na sesjach oraz ciastkach, ale nie jestem pewien co do tego, czy rzeczywiście jest on bezpieczny, a co najwazniejsze - nie mam już kompletnie żadnych pomysłów na to, w jaki sposób mógłbym podnieść poziom zabezpieczeń. Cały system ogranicza dzieli się na dwie części:

1) logowanie tymczasowe (tylko sesje, wylogowanie po 3 godzinach bezczynności)
- sprawdzenie czy sesja została zainicjowana.
- sprawdzenie IP oraz przeglądarki użytkownika - czy aktualny adres oraz nazwa klienta nie zmieniły się od czasu logowania.
- sprawdzenie, czy ID sesji istnieje w bazie danych.
- sprawdzenie, czy nie minęły 3 godziny od czasu ostatniej aktywności na koncie.
2) logowanie stałe (ciasteczka + sesje)
- sprawdzenie, czy ID sesji istnieje w bazie, a jeśli istnieje to zainicjowanie całej sesji.
- sprawdzenie, czy nie minęła ważność ciastka.

Dokładniej opisuje to poniższy schemat blokowy (PS. a owszem, nudziło mi się )



Chciałem pobrać i przejrzeć kilka gotowych rozwiązań logowania (np. z phpBB3, WordPressa, Joomla), ale dzisiaj już nie mam na to czasu, więc może jutro się tym zajmę.
Co o tym sądzicie? Jakie zabezpieczenia mógłbym jeszcze do tego dodać?

>Co o tym sądzicie?

Moim zdaniem, aż za dobrze

Witaj
Jeśli można Ci coś zasugerować to wywal sprawdzanie po IP, bo połączenia modemowe (np. neostrada) lub poprzez komórki mają zmienne ip, a często się zdarza że podczas przeglądania modem komórka łaczy się po pare razy.

Niepotrzebne jest też sprawdzanie kiedy była czynność bo wystarczy w meta dać
<meta http-equiv="refresh" content="60000;url=index.php?modules=logOn&amp;action=out">

i użytkownik sam jest wylogowany po upływie czasu.

A i jeszcze zliczaj ile razy było nieudanych prób logowania, jak przekroczy x wartości to zablokuj przegladarkę sesją, ciachem lub zapisz do bazy kiedy była ostania próba i po upływie x minut może spróbować ponownie. Takie małe zabezpieczenie przed próbą przejęcia konta.

Pozdrawiam

W czym robiony był ten schemat?

Małe sprostowanie co do inicjacja a inicjalizacja. Pojęcia często używane zamiennie, a to jednak nie to samo. Tobie raczej chodzi o to drugie Z angielskiego Initialization.

Schemat bardzo ładny jedno tylko ale. Sesje posiadają pewną małą wadę która po wykradnięciu sesji (czyt. ciasteczka z przeglądarki użytkownika) pozwala na hulanie po aplikacji imitując tamtego użytkownika. Przechwycenie adresu IP również nie jest wielkim problemem jeżli ktoś siedzi na WiFi. Dlatego osobiście radzę abyś za każdym razem wywoływał "session_regenerate_id" ponieważ ono zmienia identyfikator sesji co powoduje że po odświeżeniu strony stary identyfikator przestaje istnieć. Osobiście dodał bym jeszcze "sekretny klucz" przechowywany w ciastkach i porównywany przy logowaniu.

Oczywiście to co napisałem to trzeba brać pod uwagę jedynie w przypadku gdy projektujesz system logowania do danych "wraźliwych".

Temu panu już podziękujemy

YourFrog

session_regenerate_id za każdym razem?. Przy wysokim ruchu na stronie, mogą zacząć się problemy (wydajnościowe i losowe utraty sesji). Jak już coś to po 1, dla session_regenerate_id należy wskazzać wartośc false - aby nie tworzyło na nowo pliku tymczasowego, tylko zmeniialo jego identyfikator. Po za tym ogólnie nie zaleca się ciągłej regeneracji - powinno się ją robić co jakiś czas albo tylko na stronach specjalnego przeznaczenia.

diagram ok

@gitbejbe

1. bool session_regenerate_id ([ bool $delete_old_session = false ] )
2.
Test: http://wklej.to/mbdAd
Sprzęt: Lenovo G780, ze zwiększonym ramem na 8GB, standardowe obciażenie 10% procesora, 49% ramu.

Przy 10k wywołań czas potrzebny to 0.59 sekundy. Jeżeli zrobi to tak jak powiedziałem przy danych "wraźliwych" czyli panelu (witryny / użytkownika). śmiem twierdzić że mało z nas pracuje przy serwisie gdzie by zabolało to opóźnienie. Pomijając już fakt że serwery są mocniejsze od mojego laptopa. Dla mnie to mała cena za zwiększone bezpieczeństwo. Swoją drogą większych serwisów nie robi się na sesjach wbudowanych w php bo jak wiemy mają jeszcze jeden minus odkładają sesje w plikach.

W swoich aplikacjach klucz rozpoznawczy generuję przy każdym odświeżeniu bo nawet jeżeli użytkownik straci jakimś sposobem kontrolę nad swoimi ciastkami to jest szansa że kliknie coś na stronie zanim oprawca się na niego zaloguje.

3. Co do utraty sesji to nie wiem bo nie korzystam z tych standardowych.

Schemat zrobilem z pomocą https://www.lucidchart.com/

Tak, dobrze zadaje sobie sprawę z tego, ze w przypadku przejęcia id sesji zalogowanego usera (zdalnie lub bezpośrednio z komputera ofiary gdy jest zalogowany na stale), wystarczy utworzyć nowe ciastko z tym id w srodku aby zalogować sie na cudze konto. Rownie dobrze moglbym użyć jakiegoś innego klucza, a nie id sesji, ale bez dodatkowych zabezpieczeń po wykradnięciu ciastka wyszloby na to samo.

Session_regenerate_id() chcialem stosować zawsze, gdy id sesji nie zostalo ustawione przez serwer, tylko przez użytkownika, ale to tez mija sie z celem przez te ciasteczka...

A jakie sa jeszcze mozliwosci zrobienia tego systemu (np. tak jak juz tu pisaliscie bez standardowych sesji)?

Niema idealnego sposobu bo gdyby był to ty byś nie tworzył swojego diagramu logowania, ja bym nie miał swojego sposobu uwierzytelniania. Ilu programistów spotkasz na swojej drodze życiowej tyle będzie rozwiązań. Proponuję ci przejrzeć sprawdzone sposoby logowania które istnieją od dłuższego czasu w "stabilnych" aplikacjach open source jak WordPress, Joomla, Prestashop, Zend (Moduł Authorization), Symfony (Moduł Guard), Drupal itp. itd.

W pewnym momencie zrozumiesz że i tak wszystkie sposoby rozbijają się o głupiutkiego użytkownika który zapisuje hasła, nie wylogowuje się idąc na kawę, daje laptopa dziecią itp. itd. Jedyne co możesz robić to próbować te wszystkie rzeczy niwelować. Właśnie jak generowanie kluczy na nowo przy zmianie zakładki, wykonywanie ajax'owo zapytań o aktualny klucz, wylogowywać po x czasu, nie pozwalać się zalogować kilku osobą na jedno konto, blokować konta przy próbie zalogowania się na raz 2 użytkowników z nie zaufanych przeglądarek.

Ogólnie zostań przy swoim, a nasze gadanie przeczytaj i przyswój. Bo schemat schematem, a pozostaje jeszcze kod który może posiadać również swoje dziury. A o wymaganiach przyszłych klientów/pracodawców nie wspominając

Dość dobry artykuł o własnych sesjach przedstawił zyxist na swoim blogu.