Logowanie po raz setny, Słabe punkty rozwiązania Opcje

[athabus]

Ostatnio było wiele dyskusji na temat logowania i zapamiętywania użytkownika.
Troche nad tym myślałem i taki mi pomysł wpadł do głowy (pewnie już ktoś wcześniej to wymyślił).

Użytkownik po zalogowaniu dostaje ciasteczko na swojego kompa z loginem.
Przy kolejnej wejściu na stronę login pobierany jest z ciasteczka i automatycznie user jest logowany. W sesji dajmy na to ustawiamy $_SESSION['user']=$_COOKIE['user'].

Szkopuł w tym, że logowanie tym sposobem jest niepełne. Gdy użytkownik chce wykonać jakąś "poważniejszą operację" musi mimo wszystko się zalogować na stronie.

Dajmy na to jest druge zmienna np. $_SESSION['zalogowany'], która mówi o tym czy dany user zalogował się w danej sesji. Żeby miała wartość true user musi sie zalogować ręcznie.

Do czego ten sposób może sie przydać - np. w moim sklepie użytkownik może od razu widzieć swoje rabaty, ceny dostaw itp. Jednakże jeśli chce już złożyć zamówienie, czy chociażby zobaczyć swój profil (gdzie są dane osobowe, adres wysyłki itp) musi się zalogować. Ostatecznie nie każda wizyta kończy się tranzakcją - user może kompletować swój koszyk np. na raty.

Jest to rozwiązanie połowiczne ale chyba bezpieczne.

I tu moje pytanie - czy to rozwiązanie rzeczywiście jest bezpieczne czy tylko mi się tak wydaje? Jakie są jego słabe punkty?

[ave]

nie jest bezpieczne

Użytkownik po zalogowaniu dostaje ciasteczko na swojego kompa z loginem.

a jak zmieni sobie login w ciasteczku na inny?
1.Ja to inaczej rozwiazalem w przypadku nie zaznaczenia opcji zapietaj mnie user dostaje ciastko z idsesji a wszelkie dane o nim trzymam w sesji( login, i kilka inny potrzebnym mi rzeczy,(hasla nie trzymam bo po co)).

2.Gdy zaznaczy opcje zapamietaj mnie dostaje ciastko z md5(data zalozenia konta+haslo) + login + kilka losowych ciagow nie istotnych. i to wszystko x razy base64_encode, str_rot13, strrev, nastepnie serializacja i znowu base64_encode, str_rot13, strrev.
No i potem za pomoca ciastka, usera wlogowuje ( patrz punkt 1).

[athabus]

a jak zmieni sobie login w ciasteczku na inny?

No wlasnie wtedy nic sie nie stanie - po prostu zobaczy jakie rabaty ma user o tym loginie. Ale żeby móc wykonać jakąkolwiek poważniejszą operację i tak musi sie zalogować "ręcznie".

Np, gdy postanowi przejść do kasy, zostanie poproszony o zalogowanie.

Plus jest taki, że user może sobie spokojnie przeglądać sklep itd, a tylko jeśli ostatecznie chce coś zakupić musi się zalogować. Wydaje mi się, że jest to bezpieczniejsze od przechowywania hasła w ciasteczku (nawet zakodowanego).

Co prawda po takim przygotowaniu ciasteczka jak tu opisujesz, odgadnięcie hasła graniczy z cudem, ale pojawia się ryzyko, że nieświadomy user zapamięta hasło na kompie, do którego dostęp ma inna osoba i może się pojawić problem. Nie mówie tu nawet o włamaniu, ale np. o przypadkowym złożeniu zamówienia na konto kolegi z pracy.

[ave]

a no chyba ze tylko do tego chcesz ciacha uzywac,
to wrzuc np

[PHP] pobierz, plaintext 
<?php
base64_encode(str_rot13(strrev(zserializowana_tablica[login]+[data_zalozenia_konta]))) 
?>
[PHP] pobierz, plaintext 

potem gdy dany user nie ma swojej sesji to szukaj ciasteczka i na jego podstawie stworz mu sesje.
a przy zamowieniach wymagaj hasla i bedzie ok.

a to se user przez rozstrzepanie zostawi ciasteczko na obcym kompie, nic juz nie poradze, ewidentna jego wina...

[athabus]

a no chyba ze tylko do tego chcesz ciacha uzywac,
to wrzuc np

[PHP] pobierz, plaintext 
<?php
base64_encode(str_rot13(strrev(zserializowana_tablica[login]+[data_zalozenia_konta]))) 
?>
[PHP] pobierz, plaintext 

potem gdy dany user nie ma swojej sesji to szukaj ciasteczka i na jego podstawie stworz mu sesje.
a przy zamowieniach wymagaj hasla i bedzie ok.

No właśnie o tym myśle - to z jednej strony wygoda dla usera, ale z drugiej jakiś tam spory stopień bezpieczeństwa. Kodowanie w tym wypadku nie wiem czy jest potrzebne (skoro to tylko login), ale na pewno nie zaszkodzi a zawsze utrudnie podejrzenie rabatów.

a to se user przez rozstrzepanie zostawi ciasteczko na obcym kompie, nic juz nie poradze, ewidentna jego wina...

Ja tam wolę myśleć także o takich sytuacjach, bo one niestety są bardzie prawdopodobne niż np. włamanie (oczywiście jeśli nie jesteś dużym, znanym serwisem jak np allegro gdzie co chwila pewnie ktoś próbuje robić włamy).

A z takim 'połowicznym' zapamiętaniem użytkownika, unika się chyba większości podobnych problemów.

[DeyV]

Uważam, że niezależnie od wielkości serwisu należy zastosować podobne metody.

Czyli po pierwsze - zabezpieczyć informacje przechowywane w ciasteczku - choćby właśnie przy pomocy mechanizmów wspomnianych wyżej - tj. nie dać możliwości userowi w żaden sposób podszyć się pod kogoś.

A po drugie - na ważniejsze operacje zezwalać tylko po bezpośrednim zalogowaniu na stronie. Sądzę, że w takim przypadku wystarczyłoby przechowywać w sesji 2 dodatkowe informacje.
1 - czy to logowanie wykorzystywało dane z cookiza, czy oparte było na podaniu logina i hasła.
2. Czy login i hasło podawane były powiedzmy w ciągu ostatnich 15 min.

[TomASS]

Wydaje mi się, że najbezpieczniejszym rozwiązanie jest niestosowanie "cookiza" wogóle - ja stosuje same sesji i wymagam każdorazowago logowania się.

[athabus]

Zgadza się, że tak jast najbezpieczniej. Ja też jestem zwolennikiem przechowywania takich info w sesji, ale z drugiej strony nie można popadać w paranoję.
Wydaje mi się, że taki model jak przedstawiłem - czyli zapamiętanie użytkownika w ciasteczku (ale tylko np loginu ewentualnie nawet w jakiś sposób zabezpieczonego) a wymaganie potwierdzenia przed ważniejszą operacją powtórnym logowaniem jest równie bezpieczne a daje userowi sporo wygody, bo nie musi logować się za każdym razem, a tylko gdyz chce np złożyć zamówienie czy obejrzeć/poprawić swoje dane osobowe.