Witam

Do tej pory wszystkie systemy logowań jakie robiłem opierały się wyłącznie na sesjach. Ale chciał bym to zmienić (ponieważ denerwujące jest ciągłe logowanie) na Cookies. I tu pojawia się moje pytanie. Otóż naczytałem się w internecie że używanie cookies nie jest najlepszym rozwiązaniem, gdyż niektórzy internauci mogą mieć wyłączoną obsługę cookies z powodu bezpieczeństwa. Więc czy można podczas logowania ustawiać jednocześnie cookies i sesje ? Albo czy można jakoś sprawdzić czy użytkownik ma włączoną obsługę cookies, jeżeli tak to ustalamy ciasteczka a jeżeli nie to sesje.

A może jest inny sposób na dłuższe zapamiętanie danych niż cookies ?

Tak - można jednocześnie używać sesji i cookies... załóżmy że na stronie logowania - po poprawnej weryfikacji użytkownika - tworzysz ciasteczko 'zalogowany' oraz wpis do $_SESSION['zalogowany'], potem przekierowujesz do głównej strony serwisu...

Na każdej stronie serwisu (z wyjątkiem strony logowania) sprawdzasz parametry logowania w kolejności:
1. jest cookies 'zalogowany'?
2. jeśli nie - jest zmienna sesji 'zalogowany'?
3. jeśli nie - przekierowujemy do strony logowania,
4. jeśli 1 lub 2 tak - wyświetlamy zawartość strony...

Dzięki temu, jeżeli użytkownik ma włączoną obsługę cookies - logowanie zostanie zapamiętane na dłużej - a jeżeli nie - to będzie ważne w obrębie danej sesji.

Powodzenia.

Ok wielkie dzięki za pomoc ale z racji tego mam jeszcze 2 pytania:

1. Podczas prawidłowego logowania ustawiam cookies i sesje. Internauta zamyka stronę sesje sie tracą włącza stronę i działają cookies. I czy mogę oprzeć stronie na samych sesjach a na stronie głównej dać:

[PHP] pobierz, plaintext 
<?php
if ($_COOKIE['zalogowany']) {
$_SESSION[zalogowany] = True;
}
?>
[PHP] pobierz, plaintext 

I np jeżeli ktoś ma włączone cookies i wcześniej sie logował to teraz sesje ustawiają sie jako zalogowany a jeżeli niema włączonej obsługi cookies to musi się zalogować ?

Czy to jest dobre rozwiązanie ?

2. Czy w cookies mogę przechowywać login oraz hasło w md5 ? Np użytkownik wchodzi na stronie i po cookies pobieram dane z sql na jego temat i ustawiam w sesjach jego login, e-mail itp ? Czy to jest bezpieczne ?

hasło MD5 nie ale mam pomysł ale zwykłe tak i potem konwersować na md5 a login śmiało bo ktoś może wyciągnąc twoje hasło
A jeśli chcesz przechowywać to możesz ale pierw zrob coś system kodowania tu masz przykład

[PHP] pobierz, plaintext 
<?php
$str = md5(sha1(md5(md5($str.'someshit').'anyshit').'o.0').'bullshit!');
?>
[PHP] pobierz, plaintext 

hm... a nie lepiej generować coś unikatowego(np. md5(microtime()); ) zapisywać to do bazy danych wraz z loginem i wysyłać do ciastka? jeśli ta unikatowa wartość z ciastka będzie w bazie to znaczy że user jest zalogowany jako ten z loginem który jest w bazie przypisany do ciastka....
Tak działa system "zapamiętaj mnie" np. w phpBB2

Ciastka nie są bezpieczne co byś nie robił

choćbyś użył 100 razy różnych funkcji skrótu w tym 2 swoich algorytmów to i tak kradzież ciastka pozwoli się zalogować nie znając hasła.

Jedyne bezpieczne rozwiązanie to sesje, ale żeby były bepieczne to też nie mogą być gołe, tak jak są dostraczane w php.

ale jak dzialają sesje? zapisują id sessji do ciastka... jak ktoś wyciągnie id sessji z czyjegoś ciastka to tak jak by to on się zalogował... żadna różnica... no chyba że czegoś nie wiem i sessje sprawdzają też ip - ale można też to robić z ciastkami:)

Nie no, sesje trzeba wspomóc bo tak też są nieodporne na nic.

Ale z tymi ciastkami
Ja bym generował co tam sobie chcecie jako idnetyfikator usera nie powiązany z sesjami
lokalnie na serwerze zapisywał hash md5 z remote address, forwarded for i browsera (bez wyświetlania!!!).

I jak gosc wchodzi, nie ma sesji, ale ma ten identyfikator w ciastku to hash i porównanie z tym przypisanym do identyfikatora.

To da chyba największe szanse ochrony w przypadku kradzieży ciastka.

W końcu jak robisz serwis to chyba Twoi usesrzy powinni mieć jakieś poczucie bezpieczeństwa...

już się można śmiać...? fowarded? no to masz podstrony 1.php 2.php 3.php 4.php 5.php cookie zapisujesz na 1.php, wchodzisz na 2.php i co? cookie nie aktywne... nie ma co kombinować... jedynie zapisywanie md5 browsera to nie jest bardzo za głupi pomysł... ale instalacje niektórych dodatków do przeglądarki, aktualizacja itd=utrata cookie a jemu chodzi o to by osoba była zalogowana jak najdłużej...


moja wersja:
w bazie pola |id|login|time|ip
w id np. md5(microtime());
w login - login osoby która jest zalogowana
time - kiedy ostatnio się wszedło
ip - zakodowane ip...

skrypt sprawdza najpierw czy jest to ip w bazie, jeśli jest to sprawdza czy ludzie którzy są w bazie mają to id ciastka co w cookie - będzie napewno jedno lub zero rekordów jako wyniki.. jeśli wszystko zwróci TRUE to zapisuje się sessje zwykłą jako osobę z loginem z bazy i upadatuje czas w bazie... można dodać by czas mógł wynosić max np. 7 dni potem usuwa się z bazy czy coś...

to cookie by miało służyć jako... hm.. przedlużacz sessji bo taki ma być efekt:)

Jak mamy się pośmiać to opisz co ma wspólnego forwarded for z nazwami plików na sewerze? (:

Swoją drogą microtime to też nie jest głupie, tyle że trzeba ciągle aktualizować.

A mi się wydaje że jemu chodzi o to żeby zrobić coś jak zapamiętaj mnie na tym serwerze.

Ja jako user wolę mieć trochę bezpieczniej i 10 razy w roku stanąć przed koniecznością wpisania loginu

dobra sorka za tempy jestem:P(skojażyłem to fowarded for z foward url) ale patrzyłem troszkę w google i w jak dobrze rozumiem może być problem jeśli provider przeglądającego używa servera przekaźniczego... np. SQUID:)

z microtime chodziło mi o robienie uniq id - raz przy pierwszy wejściu

też tak go zrozumiałem...
patrzymy na to inaczej.... ja sobie nie wyobrażam żeby user był u mnie zalogowany na miesiąc(10 razy w roku = 10/12=logowanie co 1.2 miecha sredni)... od tak... dla mnie to max 7-14dni...

@forwarded, nigdy się nad tym nie zastanwaiałem, ale nie słyszałem o problemach w działaniu

@sredni czas zalogowania, więc myślę że temat aktualizacji przeglądarki możemy odpuścić i uznać za ok to md5

@microtime, Twój pomysł w takim razie nie daje nic w przypadku kradzieży zawartości ciacha ale można chyba by go rozszerzyć na działanie podczas weryfikowania sesji. Mam nawet pomysł ale jest długi do opisania w skrócie Ci napiszę że chodzi mi o to aby za każdym razem przesyłać microtime i go porównywać jak się nie zgodzi to usunąć wpis z nim związany, co w przypadku kradzieży ciacha poskutkuje wylogowaniem i właściciela i złodzieja ciastka.

Offtop:
Jak my się tu jeszcze trochę pokłócimy to autor tematu będzie mógł robic doktorat z zabezpieczania sesji w php

Hm... ale Ty zakładasz ze każdyemu ciacho będą kraść:P po pierwsze wątpie by to był tak wymagający projekt że każdą osobę będą nasłuchiwać hakjerzy w celu kradzieży ciacha... po drugie... jak ktoś chce korzystać z neta niech się umie bronić.... jak nie umie się bronić... jego strata... przyjmuje zasade "internet dla myślących"

to powiedz jak zabezpieczasz zwykłą sessje - to można zabezpieczyć tak samo:)
my się nie kłócimy tylko wymieniamy poglądami:)

Ok wielkie dzieki za pomoc ale mam nastepne pytanie:

Chcę zrobić tak po zalogowaniu ustawiam sesje i ciasteczko a do bazy sql do tabeli wgrywam id login i jakiś wygenerowany długi ciąg cyfr, który umieszczam równiez w ciasteczku.

i teraz gdy osoba wejdzie ponownie na stronę pobierany będzie ciąg cyfr z ciasteczka i porownywany z tymi w bazie jezeli bedzie sie zgadzal z istniejącym juz w bazie danych user zostanie zalogowany wedlug wpisanego wczesniej loginu do bazy sql.

Czy jest to dobre rozwiazanie

moja odpowiedz: dobre, zapisujesz sessje z tym loginem z bazy, dodaj jeszcze pole z czasem a w nim dawaj kiedy ktoś ostatnio odświerzyl strone(updatuj przy odświerzeniu)

odpowiedz netmare: Dobre ale mało bezpieczne, jak ktoś ukradnie ciacho to będzie zalogowany za kogoś innego...

No okej ale co bym nie dał do ciastka zeby potem sprawdzic uzytkownika i go zalogowac automatycznie to zawsze ktos moze ukrasc ciastko i co kolwiek niebylo by w ciastku zeby sprawdzic to i tak zaloguje sie na kogos innego.

Czy jest jakieś zabezpieczenie tego ?

czy to nie jest cytat z tego tematu?

No tutaj moim zdaniem trochę przesadziłeś, choć może Twoja ignorancja wynika z niewiedzy.
"będą nasłuchiwać hakjerzy" - no cóż ja znam trochę więcej sposobów na zaznajomienie się z czyimś ciastkiem.
Nawet phpBB, na którym tak się wzorujesz, co jakiś czas okazuje się podatnym w penych miejscach na xss-a.

Pochwal się swoim "internetem dla myślących", i powiedz jak się bronisz przed kradzieżą ciastek
Może np jako admin forum wylogowujesz się za każdym razem przed kliknięciem linku

Przy okazji ja wyznaję zasadę "lenistwo warunkiem postępu", i nie uważam żeby użytkownik internetu miał popadać w paranoję broniąc się przed możliwymi atakami, bo lepiej żeby ten czas tworzył coś pożytecznego. A że myślenie ponoć nie boli to webmaster powinien myśleć jak zabezpieczyć użytkownika. Jakby wszyscy byli tak leniwi jak Ty, to hasła byś pewnie szyfrował rotem, a bazę danych miał w zeszycie zamiast na dysku

Edit: //oczywiście gdyby ktoś już wymyślił pismo i papier

@autor pytania
Ja już Ci napisałem jakie widzę możliwości zabezpieczenia przed kradzieżą ciastek, więcej na razie pomysłów nie mam.
Jakby coś to pisz na PW, postram Ci się jakoś pomóc. Pisz dzisiaj albo w przyszłym tygodniu.

Okej więc na koniec zrobiłem tak :

po zalogowaniu ustawiłem cookies (ważne 2 dni) w którym zapisałem losowy ciąg znaków, a do tabeli sql wgrałem id, login, taki sam ciąg znaków jak do cookies, IP użytkownika.

I teraz jak user ponownie wejdzie na stronę pobierana jest od niego zawartość cookies (czyli ten ciag znaków) oraz aktualne IP i porównywane z wpisem w tabeli jeżeli ip i kod zgadza się user jest logowany na wcześniej zapisany do bazy login.

Myślę że jest to bezpieczne ponieważ samo cookies nic nie daje, ponieważ jest jeszcze autoryzacja IP.

nie będę oceniał na ile bezpieczne, ale na pewno bezużyteczne dla wszystkich mających zmienne ip - czyli dla całkiem sporej grupy użytkowników internetu...

Kurcze, o co chodzi z tym forwarded for? nie mogę nigdzie znaleźć

Sorry za odkopanie tak starego tematu ale w tej dyskusji nie mogę dojść do ładu i składu

Przecież sprawdzenie IP to kaplica dla wszystkich użytkowników neostrady i tym podobne. Wydaje mi się,że do cookies wrzucimy login (zakodowany) i ciąg cyfr. czy to rozwiązanie będzie dobre ? I potem to z bazą porównujemy i wszystko gra

Ale jak ktos Ci ukradnie cookie z tym zakodowanym loginem czy jaki on by tam nie byl to i tak uzyska dostęp do twojego konta. Musisz tu sprawdzić dodatkowo coś unikalnego lub chociaż częsciowo unikalnego dla każdego z uzytkowników.

@edit

Jedyne co mi przychodzi do głowy to 100% zabezpieczenie strony przed atakami typu XSS, generowanie własnego identyfikatora sesji opartego najlepiej na jakimś swoim wymyślonym algorytmie i teoretycznie to wystarczy, jeśli potrzebujesz większego bezpieczeństwa to wykup certyfikat SSL, ew. nie stosuj możliwości podtrzymywania sesji przez cookies, lub ogranicz jego czas do kilkunastu minut, kilku godzin.

No w twoim rozwiązaniu jeśli chodzi o algorytm jest mały sens. Ale wtedy może ktoś powiedzieć jak z tym problemem radzi sobie google, yputube, nasza-klasa.pl itd. Przecież oni stosując jakieś rozwiązanie robią to z głową i patrzą w przyszłość co i kto im może to zepsuć. Jakoś oni nie martwią się o funkcję "zapamiętaj mnie".

Jak oni to robią ?

Mają odpowiednio zabezpieczone strony przed atakami typu XSS, co wyklucza przechwycenie ciasteczka. Stosują certyfikat SSL.
Poza tym wszystkim robią to o czym my tutaj mówimy, zaloguj się proszę na wymienione przez Ciebie strony i wpisz sobie w pasku adresu, coś takiego :

java script:prompt(document.cookie);

W przypadku naszej-klasy występuje tam zmienna nk_session.
Jeśli strona jest zabezpieczona przed XSS to jedyną możliwością przejęcia cookies jest nasłuch, ale gdyby ktoś czuł się zagrożony takimi działaniami może skorzystać z udostępnionego przez nich certyfikatu SSL, który jak wiem zapewnia duże bezpieczeństwo.

Witam dołącze do tematu.

Napisał srypt logowania oparty na sesjach w mysql

Podczas logowania tworzy się wpis z następującymi danymi : id sesji, ip uzytkownika oraz ważność sesji

do ciacha zapisywany jest tylko id sesji

po zalogowaniu skrypt sprawdza id sesji oraz ip . jeżeli jest oprawne id lub ip z któego uzytkownik zopstał zalogowany to poprostu nie uzyska dostępu do stron wymagających logowania. Dodatkowo jeżeli przez jakiś okres nie bedzie ruchu od strony uzytkownika to wpis sesji zostaje skasowany..
Wiec moje pytanie jest następujące. Czy można do dac jeszcze do sesji jakis unikalny identyfikator aby bardzie utrudnić przejęcie takie sesji.

Narazie aby ktoś mógł przejąć sesjeto musiał by w ciągu kilku mitut przejąć ciacho oraz podszyć się pod adres IP który jest zapisany w sesji.

Proszę o sugestie dotyczące dodania jakiegoś unikalnego identyfikatora.

Myslałem aby dodać jeszcz do sesji z jakie przeglądarki uzytkownik zostal zalogowany

Sprawdzanie IP jest problematyczne przy neostradzie. Osobiście polecam sprawdzanie przeglądarki. Oprócz tego możesz jecze:

-> zmieniać ID sesji w bazie i ciastu przy każdym odświeżeniu strony wtedy napewno nikt nie ukradnie ID. Generuje to jednak dodatkowe zapytanie.
-> W ciastu trzymać zmienną która odpowiada numerowi aktualnego wywołania sesji. Na starcie 0, jeśli ktoś odświerzy to 1 id... Potem tylko sprawdzasz czy numerki w ciastu zgadzają się z numerkami w bazie. Potencjalny złodziej musiałby ukraść numerek, sesję i podszyć sie pod kogoś zanim użytkownik odświeży stronę.

Problematyczne w neostradzie, no ok, ale przecież IP w neo nie zmienia sie co minutę. Trzeba zresetować neta żeby tak się stało.

Moje pytanie więc jest takie: czy jest jakiś inny, powszechny rodzaj neta w którym IP zmienia się co kilka minut samoczynnie.

Sprawdzanie IP to zabezpieczenie jak z koziej dupy trąba.

szczerze mówiąc, wolę zabezpieczenie jak z koziej dupy trąba niż jego brak...

No tak ale jesli założysz ze ktoś jest na tyle sprytny zeby ukrasc ci nazwe przeglądarki i ciastka to spokojnie mozesz załozyc ze pierwsze co zrobi to ukradnie również IP.

Dla zasady mozna sprawdzac tez IP ale najwazniejsze to sprawdzic przeglądarkę.

ok, a możecie dać kod jak ustawić setcookie i session_start() tak by nie wysypywał błędów typu cannot send header ... itp. Bo z tego co wiem i setcookie i session muszą być jako pierwsze.