autologowanie przez klucz w url'u? Opcje

[czachor]

Witam,

jak waszym zdaniem wygląda pomysł autologowania przy pomocy unikalnego parametru w url'u? Przykład zastosowania to newsletter wysyłany na e-maila: w treści wiadomości są linki z unikalnym kluczem dla każdego usera (np. ...&key=uxsNesfh2kMsl12ao). User klika sobie na link, system rozpoznaje 'key' jako właściwy dla użytkownika X i automatycznie loguje go na stronie.

Moim zdaniem z punktu bezpieczeństwa to kiepski pomysł - wystarczy, że prześle dalej e-maila ("heej, zobacz jakiego ciekawego newslettera dostałem") i ktoś ma dostęp do jego konta.

Macie jakieś dobre rozwiązania dla takich sytuacji (jeśli w ogóle jest jakieś)? Oczywiście kliknięcie "zapamiętaj mnie" odpada, bo chodzi o autologowanie bez cookie, wpisywania loginu, hasła...

[vokiel]

A co jeśli ktoś prześle innej osobie login i hasło do swojego konta? Ktoś będzie miał dostęp do jego konta...

Jeśli ma być automatyczne, to bym ograniczył raz z jednego hasha. Czyli po zalogowaniu tworzysz w bazie nowy hash, wysyłając link pobierasz ten hash. Użytkownik wchodzi na stronę, następuje sprawdzenie, zalogowanie, zmiana hasha. Teraz jeśli prześle wiadomość dalej, to logowanie się już nie uda.
Jest to jakieś rozwiązanie, lipne tak samo jak pomysł autologowania przez GET;)

[czachor]

Zgadzam się, zastanawiam się właśnie, czy są jakieś rozsądne rozwiązania - zleceniodawca chce mieć taką funkcjonalność, do której powoli go zniechęcam... Rozwiązanie z jednokrotnym hashem brzmi ciekawie, ale ciągle jest to tak na prawdę obejście logowania

[Victor152]

Zawsze mozna przy rejestracji zrobic coś w stylu: twoje sekretne pytanie i przy takim autologwaniu prosic o odp. na pytanie .

[cojack]

Albo klucze publiczne.

[Pilsener]

Jak będzie chciał kliknąć jeszcze raz to już nie wyświetli, pytania także są bez sensu. Rozwiązanie dla mnie jest proste i dość oczywiste: wysyłamy userowi klucz w url a gdy kliknie w niego to klucz deaktywujemy i zastępujemy ciachem. Oczywiście należy przesłać ostrzeżenie, że jest to wiadomość tylko dla niego i po wysłaniu jej komu innemu nie będzie już mógł jej odczytać. Jak user chce sam sobie zaszkodzić to potrzebny mu lekarz a nie programista. Oczywiście warto także dodać określony czas ważności takiego klucza w mailu, powiedzmy 24 godziny.

[czachor]

No i chyba to rozwiązanie z ważnością klucza i jednorazową możliwością jest najciekawszym. Tak czy siak uważam, że sama idea jako taka jest trochę strzałem w kolano, dlatego chcę jakoś maksymalnie ją okroić. Może też dorzucę do tego ograniczenie praw do edycji profilu po wykryciu przez logowanie via klucz... Dzięki za pomysły.

[erix]

Moim zdaniem z punktu bezpieczeństwa to kiepski pomysł - wystarczy, że prześle dalej e-maila ("heej, zobacz jakiego ciekawego newslettera dostałem") i ktoś ma dostęp do jego konta.

Niekoniecznie. Wystarczy powiązać te dane z identyfikatorem sesji użytkownika. Przez session_set_cookie_params ustawiasz dłuższą ważność ciastka, w bazie tworzysz mapowanie SID<->unilalny klucz, a ciastko przez linka da się przesłać tylko dodatkowo gimnastykując. Któreś z nich się nie zgadza - wywalasz i SID, i klucz z magazynu.