Zastanawiam się jak bezpiecznie przy pomocy ciasteczka pozwolić na pamiętanie zalogowania? Chodzi mi o taką sytuacje jak jest w gmail.com czyli input text - login, input text - haslo, checkbox - pamiętaj mnie. I bardziej szczegółowo chodzi mi o obsłużenie przypadku gdy ten checkbox jest zahaczony. Trzeba strzymać u użytkownika login (bo trzeba wiedzieć kto to jest), pytanie czy warto trzymać hasło (nawet zahaczowane SHA2)? Ja sobie wymyśliłem, że będę trzymał w ciastku dwie wartości - login i hash SHA2 z loginu+'zalogowany'. dzięki temu, że hash będzie składać się z loginu i stringu zalogowany hash dla każdego użytkownika będzie inny, co trochę utrudnia podszycie się pod daną osobę (chyba, że ktoś odkryje moją zmyślną konkatacje i algorytm hashujący). Pewne jest to, że nie można trzymać nic w stylu zalogowany czt zalogowany=1 bo każdy może sobie takie ciastko zrobić i bez znajomości hasła wejść a konto. Ma ktoś jakiś pomysł jak to można zrobi, żeby było jeszcze bezpieczniejsze?

ID użytkownika + unikalny, losowy klucz, regenerowany przy każdym logowaniu.

Może być ten z bazy danych czy to zbyt niebezpieczne? Jeśli tak to jak go skonstruować?


Jakiś przykład na klucz losowy - zwykła funkcja liczb pseudolosowych random? I ten klucz za każdym wysłaniem w ciastku trzeba podmienić w bazie danych?

ID użytkownika - nie wiem czym ono jest u Ciebie, ale najprawdopodobniej jest to kolejny numer o jeden większy od poprzedniego.
Klucz możesz wygenerować chociażby poprzez:

[PHP] pobierz, plaintext 
$key = md5(uniqid(mt_rand(), true));
[PHP] pobierz, plaintext 

A regenerujesz go po każdym pomyślnym zalogowaniu się.

Regeneracja to wysłanie nowego ciasteczka + aktualizacja wpisu w bazie danych.

Przyjmij sobie najlepiej zasadę że w cookie nie trzymasz nic oprócz id sesji i najlepiej na tym wyjdziesz. Bo i po co trzymać id użytkownika? W zależności od stopnia paranoi generowanie id co odsłonę, sprawdzanie ip + danych przeglądarki.

Sprawdzanie IP bez sensu... IP jest z reguły zmienne.
Sprawdzanie przeglądarki - może być.

Zależy od zastosowań. Przecież IP nie zmienia się co 5 minut (zazwyczaj ). Jeśli sesja żyje krótszy okres ma to jak najbardziej sens.

Co 5min nie, ale co dwa dni, gdy chciałbym móc się automatycznie zalogować - już tak.

Ale co konkretnie? User Agent czy o co chodzi?

Dokładnie.

Chociaż to też nie jest zbyt "wygodne" dla użytkownika.

Tak w bazie jest to klucz główny z autoinkrementacją. Pytanie czy warto go ujawniać czy może dodać kolumnę do bazy danych z identyfikatorem użytkownika bardziej wysublimowanym i z tego korzystać? Z drugiej strony login jest mailem więc też jest unikalny, więc może login?

Przykładowo na allegro sesja trwa 30 minut i nie słyszałem wielkich krzyków. Na poczta.o2.pl jest się zalogowanym do zmiany IP. I tak dalej. Naprawdę zależy od sytuacji i tego jak chcemy być bezpieczni.

"Dokładnie" odnosi się do którego mojego postu?


Właśnie w moim przypadku jest gorzej bo ja chcę pamiętać użytkownika około rok czasu (to jest taki serwis, który ze swojej natury nie jest odwiedzany codziennie)

W przypadku sesji sprawdzanie IP jak najbardziej tak... ale nie w przypadku autologowania, które ma zapewnić nam możliwość automatycznego zalogowania się przez okres np. 20 dni.

"Dokładnie" odnosi się do ostatniego posta, przed tym postem.

OK, powiedzmy, że zostaje przy danych w ciasteczku - przy losowy kluczu i identyfikatorze użytkownika (user agenta nie chcę sprawdzać bo jeśli ktoś zaloguje się np po 8 miesiącach to pewnie z kołowa takich ludzi będzie miała nowszą wersję przeglądarki czyli UA będzie inny). Już wiem jak zrobić losowy klucz (dzięki Crozin) a co z identyfikatorem użytkownika? Dodam, że baza danych może być dowolnie modyfikowana więc nie ma problemu, żeby dodać jakieś nowe kolumny czy nawet tabele.

8 miesięcy to IMO stanowczo za dużo jak na okres ważności takiego autologowania.

Id użytkownika - no po prostu jego id... po co kombinować? I tak jest pewnie ono jawne.

Zgadzam się, że 8 miesięcy to dużo. Ale do tego serwisu ludzie zaglądają co 6 miesięcy w najlepszym wypadku dlatego trudno go porównywać z normalnym portalem. Taka jest niestety jego specyfika.

Jeśli chodzi o id to nie jest jawny, nigdzie go nie używam w parametrach. Dlatego mogę zamiast ściągać go z klucza głównego dodać jakiś inny unikatowy, który będzie również generowany losowo. Pytanie czy to zwiększa bezpieczeństwo?

Jeszcze raz zapytam. Po co ci id_uzytkownika w cookie? Bo na siłę żeby było nie ma sensu. Wszystkie dane masz wiązane przez identyfikator sesji.

to wrzuce i swoje 2gr http://www.beldzio.com/autologowanie

Teoretycznie da się zidentyfikować użytkownika bez id, jako, że sam klucz wygenerowany np z md5(uniqid(mt_rand(), true)) gwarantuje unikalność, więc można dać zapytanie do bazy i wiadomo, że w najlepszym wypadku zwrócony zostanie tylko jeden rekord. Dobrze kombinuję?

Wiesz - z pseudolosowością nigdy nic nie wiadomo i ja osobiście nie polegałbym tylko na tej jednej funkcji. Poza tym hashe md5 są podatne na kolizje co powoduje, że kilka różnych wartości może mieć ten sam hash, co z kolei powoduje, że nici z naszego pamiętania... Musi być jeszcze jakiś element identyfikujący użytkownika, a takim elementem, który nic nikomu nie powie, ani nie zaszkodzi jest id użytkownika z bazy. Więc użycie id i klucza/hasha/soli do zabezpieczenia takiego logowania jest już w porządku według mnie.

Polecalbym w cookie przechowywac id i shashowane(haslo+jakas kilkunastoznakowa sol). Id w zasadzie i tak jest jawne, a jezeli nie to co z tego ze zna id jak haslo i przede wszystkim sol sa niewiadomymi.

Wydaje mi sie ze to dobry sposob na zabezpieczenie przed ewentualna proba ataku na jakikolwiek id poprzez cookies. Sol zabezpiecza przed atakiem brute force w przypadku krotkich hasel, a dzieki przechowywaniu id masz szybki dostep do rekordu w bazie.

Co do sprawdzania Agenta i IP. Kod wywolywany na poczatku kazdej podstrony

[PHP] pobierz, plaintext 
if(zalogowany()){
	if($_SESSION['kod'] != md5($_SERVER['REMOTE_ADDR'].$_SERVER['HTTP_USER_AGENT'])){
		wyloguj();
	}
}else{
	zaloguj_z_cookies();
}
[PHP] pobierz, plaintext 

zalogowany() - sprawdza istnienie zmiennej sesyjnej o okreslonej nazwie
zaloguj_z_cookies - sprawdza istnienie zmiennych cookies, pozniej sprawdza ich zgodnosc z danymi w bazie, jezeli wszystko sie zgadza loguje uzytkownika (ustawia SESSION), jezeli nie - nic nie robi.

Mozna zaimplementowac funkcje regeneracji id sessji co x sekund lub x wyswietlonych stron.

Hashownie haseł nie jest bezpieczne - o wiele bezpieczniejszy jest właśnie jakiś przypadkowy zestaw znaków zapisywany również do bazy do danego id, regenerowany przy każdym logowaniu/wejściu na stronę jako zalogowany i mamy sprawę bezpieczną.

md5($haslo.'2DJ5oW9b3dopw')
Czy istnieje sposob na zlamanie np takiego hasha? Slyszalem o metodzie teczowych tablic (rainbow array), ale one skuteczne sa do 'cofania' hasha dla ciagow mniej niz 8 znakow. W moim przypadku sama sol jest dluzsza. A znajomosc mojego hasha md5(haslo+sol) w zaden sposob nie pozwoli wejsc mi w posiadanie wartosci soli potrzebnej do ewentualnego ataku.

Mowisz ze jest niebezpieczne. Moim zdaniem niezbezpieczne byloby md5(pass) i wtedy gdy uzytkownik ma krotkie haslo. Przy uzyciu tablic teczowych mozna byloby odgadnac...

A jakie ma znaczenie, jakie hasło? Wyszukiwany jest jakikolwiek ciąg, który będzie pasował do sumy kontrolnej. Może być nawet inne hasło, byleby hash był taki, który umożliwi wejście do systemu. Jest osobny, przyklejony wątek na ten temat.

Tak w ogóle, to PHP posiada tyle funkcji hashujących, że tylko wybierać, nie mam pojęcia, dlaczego wszyscy się uczepili md5. :/


Całkowicie się zgadzam. Do tego zapisanie parę informacji o użytkowniku, aby zminimalizować ryzyko przejęcia sesji.

Tak, masz racje, ze dwa rozne ciagi moga dac jednakowy hash. Jednak ryzyko jest chyba niewielkie? W takim razie niewazne czy shashujemy haslo, haslo+sol czy unikalna liczbe i inne dane o userze skoro w kazdym wypadku istnieje mozliwosc uzyskania takiego samego hasha bez znajomosci shashowanych przez nas danych? Czy dobrze rozumuje?



A co polecasz innego?

Każdy mówi, że ryzyko jest niewielkie, a jak przychodzi co do czego, to jest płacz i zgrzytanie zębów.


hash i sobie przejrzyj, co jest.

...ale ustosunkuj sie do 2 czesci mojej wypowiedzi. Co za roznica co hashujemy skoro hash mozna obejsc tak samo w przypadku hasha hasla jak hasha z Bog wie jakis wartosci?

Ale do jednego algorytmu dopasujesz w kilka sekund, a dla drugiego - kilkaset lat. MD5/SHA1 jest oklepane po prostu, właśnie dla nich nie problem znaleźć.