sesje po stronie klienta

Może mi ktoś wytłumaczyć o co właściwe w tym chodzi? Analizuję pewien projekt który korzysta (https://github.com/mozilla/node-client-sessions#readme) i nie mogę zrozumiec pierwszego zdania:
client-sessions jest middleware który implementuje sesje w zaszyfrowanych, wolnych od manipulacji ciasteczkach.
Czy ktoś może byłby chętny wytłumaczyć mi to w sposób bardziej zrozumiały? Z góry dziekuję.

Sesja jest po stronie clienta ale on sobie jej nie moze modyfikowac (np. set admin = 1) bo token jest zaszyfrowany (edit: podpisany*).

Jak jakies losowe bajty pozmieniasz to sie weryfikacja tokena wylozy a bez klucza nie wiesz jak to prawidlowo modyfikowac.

Totalnie bez sensu bo jak masz secret wstawiony we froncie to za pomoca tej funkcji mozesz sobie odkodowac i zakodowac zmiany w ciachu. Musialbys miec pare kluczy czyli jesli budujesz serwis to musialbys z kazdym odwiedzajacym stworzyc pare kluczy publiczny-prywatny

@masterc: Nie masz sekretu we froncie. Backend ma sekret a front tylko podpisana wiadomosc.
Wiesz jak dziala JWT?

masterc napisał(a):

Totalnie bez sensu bo jak masz secret wstawiony we froncie to za pomoca tej funkcji mozesz sobie odkodowac i zakodowac zmiany w ciachu. Musialbys miec pare kluczy czyli jesli budujesz serwis to musialbys z kazdym odwiedzajacym stworzyc pare kluczy publiczny-prywatny

Ciasteczko jest ustawiane przez serwer i kompilowane przez serwer. Walidacja też musi nastąpić po stronie serwera. Wszystko co musisz zrobić, żeby to zabezpieczyć, to dodać do ciasteczka "podpis" wygenerowany np. tak sha256("treść ciasteczka"+"ten ciąg zna tylko serwer")

Wszystko co musisz zrobić, żeby to zabezpieczyć, to dodać do ciasteczka "podpis" wygenerowany np. tak sha256("treść ciasteczka"+"ten ciąg zna tylko serwer")

@piotrpo NIE NIE NIE. Jeśli w ogóle to należy użyć konstrukcji HMAC. To co pokazałeś nie jest wcale bezpieczne, bo kolizja na prefixie powoduje kolizje także po dodaniu tego twojego sekretu (tzn jeśli dupa i dupa2 mają ten sam hash to po dodaniu sekretu też mają ten sam hash). Sytuacja odwrotna tzn secret+message jest jeszcze gorsza bo wtedy wchodzi Hash Length Extension Attack.