"Keep me Logged In" - najlepsze podejście

Uwaga dotycząca bezpieczeństwa: oparcie pliku cookie na hashu MD5 deterministycznych danych jest złym pomysłem; lepiej jest użyć losowego tokena pochodzącego z csprng. Zobacz odpowiedź ircmaxell na to pytanie, aby uzyskać bardziej bezpieczne podejście.

Zazwyczaj robię coś takiego:

1. Użytkownik loguje się za pomocą "keep me logged in"
2. Utwórz sesję
3. Utwórz plik cookie o nazwie coś zawierającego: md5 (salt+username+ip+salt) oraz plik cookie o nazwie somethingElse zawierający id
4. przechowuj plik cookie w bazie danych
5. User does stuff and leaves - - - -
6. user returns, check for somethingElse cookie, if it exists, get the old hash from the database for that user, check of the content of cookie SOMETHING match with the hash from the database, which should also match with a newly calculated hash (for the ip) thus: cookieHash= = databaseHash= = md5 (salt+username+ip+salt), if they do, goto 2, if they don 't goto 2, if they don' t goto 1

Oczywiście możesz używać różnych nazw plików cookie itp. możesz również nieco zmienić zawartość pliku cookie, po prostu upewnij się, że nie jest to łatwe tworzenie. Można na przykład utworzyć user_salt, gdy użytkownik jest tworzony, a także umieścić go w pliku cookie.

Wprowadzenie

Twój tytuł "Keep Me Logged In" - najlepsze podejście sprawia, że trudno mi wiedzieć, od czego zacząć, ponieważ jeśli szukasz najlepszego podejścia, musisz wziąć pod uwagę następujące kwestie :

• Identyfikacja
• bezpieczeństwo

Cookies

Pliki cookie są podatne na zagrożenia, między typowymi lukami w zabezpieczeniach przeglądarki i atakami skryptowymi między stronami musimy zaakceptować, że pliki cookie nie są bezpieczne. Aby poprawić bezpieczeństwo należy pamiętać, że php setcookies posiada dodatkowe funkcje, takie jak

Bool setcookie (string $name [, string $value [, int $expire = 0 [, string $path [, string $domain [, bool $secure = false [, bool $httponly = false ]]]]]] )

• bezpieczne (przy użyciu połączenia HTTPS)
W 2007 roku firma została założona w 2008 roku.]}

Definicje

• Token (nieprzewidywalny losowy ciąg n długości np. / dev / urandom)
• Reference (nieprzewidywalny losowy ciąg N długości np. / dev / urandom)
• Signature (generowanie wartości skrótu z kluczem przy użyciu metody HMAC)

Proste Podejście

Prostym rozwiązaniem byłoby:

• użytkownik jest zalogowany przez Remember Me
• Login Cookie issued with token & Signature
• Po powrocie podpis jest sprawdzone
• jeśli podpis jest ok .. następnie nazwa użytkownika i token są sprawdzane w bazie danych
• Jeśli nie jest poprawna .. powrót do strony logowania
• If valid automatically login

Powyższe studium przypadku podsumowuje wszystkie przykłady podane na tej stronie, ale są one wadą jest to, że

Nie wiadomo, czy ciastka zostały skradzione.]}
• atakujący może mieć dostęp do poufnych operacji, takich jak zmiana hasła lub danych, takich jak osobiste i pieczenia informacje itp.
Plik cookie może być przechowywany przez cały okres użytkowania.]}

Lepsze Rozwiązanie

Lepszym rozwiązaniem byłoby

• użytkownik jest zalogowany i wybierz Zapamiętaj mnie
• Generuj Token i podpis i przechowuj w pliku cookie
• tokeny są losowe i są ważne tylko dla pojedynczej autentykacji
• token jest zastępowany przy każdej wizycie na stronie
• gdy niezalogowany użytkownik odwiedza strona podpis, token i nazwa użytkownika są weryfikowane
• Zapamiętaj mnie login powinien mieć ograniczony dostęp i nie zezwalać na modyfikację hasła, danych osobowych itp.

Przykładowy Kod

// Set privateKey
// This should be saved securely 
$key = 'fc4d57ed55a78de1a7b31e711866ef5a2848442349f52cd470008f6d30d47282';
$key = pack("H*", $key); // They key is used in binary form

// Am Using Memecahe as Sample Database
$db = new Memcache();
$db->addserver("127.0.0.1");

try {
    // Start Remember Me
    $rememberMe = new RememberMe($key);
    $rememberMe->setDB($db); // set example database

    // Check if remember me is present
    if ($data = $rememberMe->auth()) {
        printf("Returning User %s\n", $data['user']);

        // Limit Acces Level
        // Disable Change of password and private information etc

    } else {
        // Sample user
        $user = "baba";

        // Do normal login
        $rememberMe->remember($user);
        printf("New Account %s\n", $user);
    }
} catch (Exception $e) {
    printf("#Error  %s\n", $e->getMessage());
}

Klasa Używana

class RememberMe {
    private $key = null;
    private $db;

    function __construct($privatekey) {
        $this->key = $privatekey;
    }

    public function setDB($db) {
        $this->db = $db;
    }

    public function auth() {

        // Check if remeber me cookie is present
        if (! isset($_COOKIE["auto"]) || empty($_COOKIE["auto"])) {
            return false;
        }

        // Decode cookie value
        if (! $cookie = @json_decode($_COOKIE["auto"], true)) {
            return false;
        }

        // Check all parameters
        if (! (isset($cookie['user']) || isset($cookie['token']) || isset($cookie['signature']))) {
            return false;
        }

        $var = $cookie['user'] . $cookie['token'];

        // Check Signature
        if (! $this->verify($var, $cookie['signature'])) {
            throw new Exception("Cokies has been tampared with");
        }

        // Check Database
        $info = $this->db->get($cookie['user']);
        if (! $info) {
            return false; // User must have deleted accout
        }

        // Check User Data
        if (! $info = json_decode($info, true)) {
            throw new Exception("User Data corrupted");
        }

        // Verify Token
        if ($info['token'] !== $cookie['token']) {
            throw new Exception("System Hijacked or User use another browser");
        }

        /**
         * Important
         * To make sure the cookie is always change
         * reset the Token information
         */

        $this->remember($info['user']);
        return $info;
    }

    public function remember($user) {
        $cookie = [
                "user" => $user,
                "token" => $this->getRand(64),
                "signature" => null
        ];
        $cookie['signature'] = $this->hash($cookie['user'] . $cookie['token']);
        $encoded = json_encode($cookie);

        // Add User to database
        $this->db->set($user, $encoded);

        /**
         * Set Cookies
         * In production enviroment Use
         * setcookie("auto", $encoded, time() + $expiration, "/~root/",
         * "example.com", 1, 1);
         */
        setcookie("auto", $encoded); // Sample
    }

    public function verify($data, $hash) {
        $rand = substr($hash, 0, 4);
        return $this->hash($data, $rand) === $hash;
    }

    private function hash($value, $rand = null) {
        $rand = $rand === null ? $this->getRand(4) : $rand;
        return $rand . bin2hex(hash_hmac('sha256', $value . $rand, $this->key, true));
    }

    private function getRand($length) {
        switch (true) {
            case function_exists("mcrypt_create_iv") :
                $r = mcrypt_create_iv($length, MCRYPT_DEV_URANDOM);
                break;
            case function_exists("openssl_random_pseudo_bytes") :
                $r = openssl_random_pseudo_bytes($length);
                break;
            case is_readable('/dev/urandom') : // deceze
                $r = file_get_contents('/dev/urandom', false, null, 0, $length);
                break;
            default :
                $i = 0;
                $r = "";
                while($i ++ < $length) {
                    $r .= chr(mt_rand(0, 255));
                }
                break;
        }
        return substr(bin2hex($r), 0, $length);
    }
}

testowanie w Firefoksie i Chrome

korzyść

• Lepsze Bezpieczeństwo
• ograniczony dostęp dla atakującego
• gdy cookie jest kradziony jest tylko ważny dla pojedynczego dostępu
Kiedy następny użytkownik wejdzie na stronę, możesz automatycznie wykryć i powiadomić użytkownika o kradzieży.]}

wada

• nie obsługuje stałego połączenia przez wiele przeglądarek (mobilnych i internetowych)
• plik cookie może zostać skradziony, ponieważ użytkownik otrzymuje powiadomienie dopiero po następnym zalogowaniu.

Quick Fix

• wprowadzenie homologacji system dla każdego systemu, który musi mieć stałe połączenie
• Użyj wielu plików cookie do uwierzytelniania

Podejście Wielu Plików Cookie

Gdy atakujący ma zamiar ukraść gotuje tylko skupić się na konkretnej stronie internetowej lub domenie np. example.com

Ale tak naprawdę można uwierzytelnić użytkownika z 2 różnych domen ( example.com & fakeaddsite.com ) i sprawić, by wyglądało to jak " reklamowe ciasteczko"

• użytkownik zalogowany na example.com with remember me
• nazwa użytkownika, token, odniesienie w pliku cookie
• Nazwa Użytkownika Sklepu, token , odniesienie w bazie danych np. Memcache
• Wyślij refrence id poprzez get i iframe do fakeaddsite.com
• fakeaddsite.com używa referencji do pobrania user & token z bazy danych
• fakeaddsite.com przechowuje podpis
• gdy użytkownik zwraca fetch signature information with iframe od fakeaddsite.com
• Połącz dane it i wykonaj walidację
• ..... znasz pozostałe

Niektórzy mogą się zastanawiać, jak można używać 2 różnych plików cookie ? To możliwe, wyobraź sobie example.com = localhost i fakeaddsite.com = 192.168.1.120. Jeśli przejrzysz pliki cookie, wyglądałoby to tak

Z obrazka powyżej

W tym celu należy skontaktować się z Działem obsługi klienta.]}
• zawiera również pliki cookie ustawione z 192.168.1.120

192.168.1.120

• akceptuje tylko zdefiniowane HTTP_REFERER
• akceptuje tylko połączenie z podanego REMOTE_ADDR
• bez JavaScript, bez treści, ale nie składają się z niczego, zamiast podpisywać informacje i dodawać lub pobierać je z pliku cookie

korzyść

• 99% procent czasu, kiedy oszukałeś napastnika
• możesz łatwo zablokować konto przy pierwszej próbie ataku
• atak może być uniemożliwione nawet przed następnym logowaniem, podobnie jak inne metody

wada

• wielokrotne żądanie do serwera tylko dla jednego logowania

Poprawa

• Done use iframe use ajax

Są dwa bardzo ciekawe artykuły, które znalazłem szukając idealnego rozwiązania problemu "Zapamiętaj mnie":

• Trwałe Pliki Cookie Do Logowania Najlepsze Praktyki
• Ulepszona Najlepsza Praktyka Trwałych Plików Cookie Logowania

Zadałem jedno pytanie tutaj , A odpowiedzi poprowadzą Cię do wszystkich potrzebnych linków do plików cookie opartych na tokenie.

Zasadniczo nie przechowujesz identyfikatora użytkownika w pliku cookie. Przechowujesz jednorazowy token (ogromny ciąg znaków), którego użytkownik używa do odebrania swojej starej sesji logowania. Następnie, aby było naprawdę bezpieczne, prosisz o hasło do ciężkich operacji (takich jak zmiana samego hasła).

Polecam podejście wspomniane przez Stefana (tj. postępuj zgodnie z wytycznymi w Improved Persistent Login Cookie Best Practice), a także zalecam, aby upewnić się, że Twoje pliki cookie są HttpOnly cookies, aby nie były dostępne dla, potencjalnie złośliwego, JavaScript.

Wygeneruj hash, może z tajemnicą, którą znasz, a następnie przechowuj go w DB, aby mógł być powiązany z użytkownikiem. Powinno zadziałać całkiem nieźle.

Stary wątek, ale nadal ważny problem. Zauważyłem kilka dobrych odpowiedzi na temat bezpieczeństwa i unikania stosowania "bezpieczeństwa przez ciemność", ale rzeczywiste metody techniczne nie były wystarczające w moich oczach. Rzeczy, które muszę powiedzieć, zanim wniosę swój wkład w moją metodę:

• nigdy nie przechowuj hasła w czystym tekście...Nigdy!
• nigdy nie przechowuj hashowanego hasła użytkownika w więcej niż jednym miejscu w bazie danych. Backend serwera jest zawsze w stanie wyciągnąć haszowane hasło z tabeli użytkowników. Nie jest bardziej wydajne przechowywanie nadmiarowych danych zamiast dodatkowych transakcji DB, odwrotność jest prawdziwa.
• Twój identyfikator sesji powinien być unikalny, więc żaden użytkownik nie mógł kiedykolwiek udostępnić identyfikatora, stąd cel ID (czy numer Twojego prawa jazdy mógłby kiedykolwiek pasować do innej osoby? Nie.) Tworzy to dwuczęściową unikalną kombinację, opartą na 2 unikalnych strunach. Twoja tabela sesji powinna używać ID jako PK. Aby umożliwić zaufanie wielu urządzeniom w przypadku auto-signin użyj innej tabeli dla zaufanych urządzeń, która zawiera listę wszystkich zweryfikowanych urządzeń (patrz mój przykład poniżej) i jest mapowana przy użyciu nazwy użytkownika.
• nie służy do hashowania znanych danych do pliku cookie, plik cookie można skopiować. To, czego szukamy, to zgodne urządzenie Użytkownika, które dostarcza autentycznych informacji, których nie można uzyskać bez naruszenia komputera użytkownika przez osobę atakującą (zobacz mój przykład). Oznaczałoby to jednak, że uprawniony użytkownik, który zabrania informacje statyczne jego komputera (tj. adres MAC, Nazwa hosta urządzenia, useragent, jeśli jest ograniczona przez przeglądarkę, itp.) z pozostających spójnych (lub fałszywych w pierwszej kolejności) nie będzie mógł korzystać z tej funkcji. Ale jeśli jest to problemem, rozważ fakt, że oferujesz auto-signin użytkownikom, którzy identyfikuj się wyjątkowo, więc jeśli nie chcą być znani przez fałszowanie ich MAC, fałszowanie ich useragent, fałszowanie / zmienianie nazwy hosta, ukrywanie się za proxy, itp., wtedy nie są one możliwe do zidentyfikowania i nigdy nie powinny być uwierzytelniane dla usługi automatycznej. Jeśli tego chcesz, musisz przyjrzeć się dostępowi do kart inteligentnych w pakiecie z oprogramowaniem po stronie klienta, które ustala tożsamość używanego urządzenia.

To wszystko jest powiedziane, istnieją dwa świetne sposoby, aby mieć auto-signin w systemie.

To jest tanie, a także może być uznane za brudne przez niektórych, ponieważ stara się zweryfikować potencjalnie już zalogowany w siebie z miejsc takich jak Google i Facebook, nawet nie mówiąc ci. Nie należy go jednak używać u użytkowników, którzy nie poprosili o Automatyczne logowanie na twojej stronie, a ta konkretna metoda służy tylko do zewnętrznego uwierzytelniania, jak w przypadku Google+ lub FB.

Ponieważ zewnętrzny authenticator został użyty do poinformowania serwera za kulisami, czy użytkownik został zweryfikowany, czy nie, atakujący nie może uzyskać niczego innego niż unikalny identyfikator, który sam w sobie jest bezużyteczny. Rozwiążę:

• użytkownik " joe "odwiedza witrynę po raz pierwszy, identyfikator sesji umieszczony w pliku cookie "session".
• użytkownik " joe "loguje się, zwiększa uprawnienia, otrzymuje nowy identyfikator sesji i odnawia "sesję" pliku cookie.
• użytkownik " joe " wybiera auto-signin używając google+, dostaje unikalny identyfikator umieszczony w pliku cookie "keepmesignedin".
• użytkownik " joe " ma google keep them login in, umożliwiając Twojej witrynie Automatyczne logowanie użytkownika za pomocą google w Twoim backendzie.
• atakujący systematycznie próbuje unikalnych identyfikatorów dla 'keepmesignedin' (jest to wiedza publiczna przekazywana każdemu użytkownikowi) i nie jest zalogowany nigdzie indziej; próbuje unikalnych identyfikatorów dla 'joe'.
• serwer otrzymuje unikalny identyfikator dla 'joe', pobiera dopasowanie w DB dla konta google+.
• serwer wysyła atakującego do logowania strona, która uruchamia żądanie AJAX do google, aby się zalogować.
• serwer Google otrzymuje żądanie, używa swojego API, aby zobaczyć, że atakujący nie jest aktualnie zalogowany.
• Google wysyła odpowiedź, że nie ma aktualnie zalogowanego użytkownika przez to połączenie.
• strona atakującego otrzymuje odpowiedź, skrypt automatycznie przekierowuje na stronę logowania z wartością posta zakodowaną w adresie url.
• strona logowania pobiera wartość POST, wysyła plik cookie dla "keepmesignedin" do pustej wartości i ważnego do daty 1-1-1970, aby powstrzymać automatyczną próbę, powodując, że przeglądarka atakującego po prostu usunie plik cookie.
• atakujący otrzymuje normalną stronę logowania po raz pierwszy.

Bez względu na wszystko, nawet jeśli atakujący użyje identyfikatora, który nie istnieje, próba powinna zakończyć się niepowodzeniem we wszystkich próbach, z wyjątkiem sytuacji, gdy otrzymana zostanie potwierdzona odpowiedź.

Ta metoda może i powinna być używana w połączeniu z twoim wewnętrznym uwierzytelniaczem dla tych, którzy logują się do twojej witryny za pomocą zewnętrznego authenticator.

=========

Teraz, dla Twojego własnego systemu authenticator, który może automatycznie podpisywać użytkowników, tak to robię:

DB ma kilka tabel:

TABLE users:
UID - auto increment, PK
username - varchar(255), unique, indexed, NOT NULL
password_hash - varchar(255), NOT NULL
...

Zauważ, że nazwa użytkownika może mieć długość 255 znaków. Mój program serwera ogranicza nazwy użytkowników w moim systemie do 32 znaków, ale zewnętrzne uwierzytelniacze mogą mieć nazwy użytkowników ze swoją domeną@.tld być większy niż to, więc po prostu obsługuję maksymalną długość adresu e-mail dla maksymalnej kompatybilność.

TABLE sessions:
session_id - varchar(?), PK
session_token - varchar(?), NOT NULL
session_data - MediumText, NOT NULL

Zauważ, że w tej tabeli nie ma pola user, ponieważ nazwa użytkownika, po zalogowaniu, znajduje się w danych sesji, a program nie zezwala na dane null. Session_id i session_token mogą być generowane przy użyciu losowych skrótów md5, skrótów sha1/128/256, znaczników datetime z losowymi ciągami dodanymi do nich, a następnie hashowanymi, lub cokolwiek chcesz, ale Entropia twojego wyjścia powinna pozostać tak wysoka, jak tolerowana, aby złagodzić ataki brute-force z nawet wysiadania grunt i wszystkie hasze generowane przez klasę sesji powinny być sprawdzane pod kątem dopasowań w tabeli sesji przed próbą dodania ich.

TABLE autologin:
UID - auto increment, PK
username - varchar(255), NOT NULL, allow duplicates
hostname - varchar(255), NOT NULL, allow duplicates
mac_address - char(23), NOT NULL, unique
token - varchar(?), NOT NULL, allow duplicates
expires - datetime code

Adresy MAC ze swojej natury mają być unikalne, dlatego ma sens, że każdy wpis ma unikalną wartość. Z drugiej strony nazwy hostów mogą być legalnie powielane w oddzielnych sieciach. Ile osób używa "Home-PC" jako nazwy komputera? Nazwa użytkownika jest pobierana z danych sesji Przez zaplecze serwera, więc manipulowanie tym jest niemożliwe. Jeśli chodzi o token, ta sama metoda generowania tokenów sesji dla stron powinna być używana do generowania tokenów w plikach cookie dla użytkownika auto-signin. Na koniec, kod datetime jest dodawany, gdy użytkownik będzie musiał ponownie potwierdzić swoje poświadczenia. Albo zaktualizuj tę datę po zalogowaniu użytkownika, zachowując ją w ciągu kilku dni, lub Wymuś jej wygaśnięcie niezależnie od ostatniego logowania, zachowując ją tylko przez miesiąc lub dłużej, niezależnie od tego, co dyktuje Twój projekt.

To uniemożliwia komuś systematyczne fałszowanie MAC i nazwy hosta dla użytkownika, który zna Automatyczne logowanie. nigdy niech użytkownik zachowa plik cookie z hasłem, wyraźnym tekstem lub w inny sposób. Niech token zostanie zregenerowany podczas każdej nawigacji po stronie, tak jak token sesji. To znacznie zmniejsza prawdopodobieństwo, że atakujący może uzyskać poprawny token cookie i użyć go do zalogowania. Niektórzy ludzie będą próbowali powiedzieć, że atakujący może ukraść pliki cookie ofierze i powtórzyć sesję atak, aby się zalogować. Jeśli atakujący mógłby ukraść pliki cookie( co jest możliwe), z pewnością naraziłby całe urządzenie, co oznacza, że mógłby po prostu użyć urządzenia do zalogowania się, co całkowicie zaprzecza celowi kradzieży plików cookie. Tak długo, jak twoja witryna działa przez HTTPS (co powinno się robić w przypadku haseł, numerów CC lub innych systemów logowania), zapewniłeś użytkownikowi pełną ochronę, jaką możesz uzyskać w przeglądarce.

Jedna rzecz, o której należy pamiętać: dane sesji nie powinno wygasnąć, jeśli używasz auto-signin. Można wygasnąć możliwość kontynuowania sesji fałszywie, ale Walidacja do systemu powinna wznowić dane sesji, jeśli oczekuje się, że są to dane trwałe, które mają być kontynuowane między sesjami. Jeśli chcesz mieć zarówno trwałe, jak i nietrwałe dane sesji, użyj innej tabeli dla trwałych danych sesji z nazwą użytkownika jako PK i poproś serwer o pobranie ich tak, jak normalne dane sesji, po prostu użyj innej zmiennej.

Gdy login ma w ten sposób serwer powinien nadal sprawdzać poprawność sesji. W tym miejscu można kodować oczekiwania dotyczące skradzionych lub skompromitowanych systemów; wzorce i inne oczekiwane wyniki logowania do danych sesji często mogą prowadzić do wniosków, że system został porwany lub pliki cookie zostały sfałszowane w celu uzyskania dostępu. W tym miejscu technologia ISS może wprowadzić reguły, które spowodowałyby zablokowanie konta lub automatyczne usunięcie użytkownika z systemu auto-signin, utrzymując atakujących wystarczająco długo aby ustalić, w jaki sposób atakujący odniósł sukces i jak go odciąć.

Na zakończenie należy upewnić się, że wszelkie próby odzyskania, zmiany hasła lub błędy logowania po przekroczeniu progu skutkują wyłączeniem funkcji auto-signin, dopóki użytkownik nie potwierdzi poprawności i nie potwierdzi tego.

Moje rozwiązanie jest takie. Nie jest w 100% kuloodporny, ale myślę, że zaoszczędzi ci na większości przypadków.

Gdy użytkownik zalogowany pomyślnie Utwórz łańcuch z tą informacją:

$data = (SALT + ":" + hash(User Agent) + ":" + username 
                     + ":" + LoginTimestamp + ":"+ SALT)

Szyfruj $data, Ustaw typ na HttpOnly i ustaw plik cookie.

Kiedy użytkownik powróci na Twoją stronę, wykonaj następujące kroki:

1. Pobierz dane cookie. Usuń niebezpieczne znaki wewnątrz pliku cookie. Explode it with : character.
2. Sprawdź ważność. Jeśli plik cookie jest starsze niż X dni następnie przekierować użytkownika do strony logowania.
3. Jeśli plik cookie nie jest stary; uzyskaj czas ostatniej zmiany hasła z bazy danych. Jeśli hasło zostanie zmienione po ostatnim zalogowaniu użytkownika, przekieruj użytkownika na stronę logowania.
4. Jeśli pass nie został ostatnio zmieniony; Pobierz aktualnego agenta przeglądarki użytkownika. Sprawdź czy (currentUserAgentHash == cookieUserAgentHash). Jeśli agenci są tacy sami, przejdź do następnego kroku, w przeciwnym razie przekieruj na stronę logowania.
5. Jeśli wszystkie kroki pomyślnie przeszły autoryzację nazwa użytkownika.

Jeśli użytkownik wylogowuje się, usuń ten plik cookie. Utwórz nowy plik cookie, jeśli użytkownik ponownie się zaloguje.

Nie rozumiem koncepcji przechowywania zaszyfrowanych rzeczy w pliku cookie, gdy jest to zaszyfrowana wersja tego, że trzeba zrobić hacking. Jeśli coś przeoczyłem, proszę o komentarz.

Myślę o podjęciu takiego podejścia, aby "zapamiętać mnie". Jeśli widzisz jakieś problemy, prosimy o komentarz.

1. Utwórz tabelę do przechowywania danych "Zapamiętaj mnie" - oddzielona od tabeli użytkownika, abym mógł zalogować się z wielu urządzeń.

2. Przy pomyślnym logowaniu (z Zapamiętaj mnie):

   A) Wygeneruj unikalny losowy ciąg znaków, który będzie używany jako identyfikator użytkownika na tej maszynie: bigUserID

   B) Wygeneruj unikalny losowy ciąg znaków: bigKey

   C) przechowuje plik cookie: bigUserID: bigKey

   D) w tabeli "Remember Me" Dodaj rekord z: UserID, IP Address, bigUserID, bigKey

3. Jeśli próbujesz uzyskać dostęp do czegoś, co wymaga logowania:

   A) sprawdź plik cookie i wyszukaj bigUserID & bigKey z pasującym adresem IP adres

   B) Jeśli go znajdziesz, Zaloguj się, ale ustaw flagę w tabeli użytkownika "soft login" , aby w przypadku jakichkolwiek niebezpiecznych operacji można było poprosić o pełne logowanie.

4. Po wylogowaniu Zaznacz wszystkie rekordy "Zapamiętaj mnie" dla tego użytkownika jako wygasłe.

Jedyne luki jakie widzę to;

Możesz chwycić czyjś laptop i sfałszować jego adres IP za pomocą pliku cookie.
• za każdym razem można podmienić inny adres IP i zgaduj całość - ale z dwoma dużymi strunami do dopasowania, to by było...wykonując podobne obliczenia jak powyżej...Nie mam pojęcia...wielkie szanse?

Przeczytałem wszystkie odpowiedzi i nadal trudno było wydobyć to, co miałem zrobić. Jeśli obraz jest wart 1K słów, mam nadzieję, że pomoże to innym zaimplementować bezpieczne trwałe przechowywanie w oparciu o najlepsze praktyki Barry ' ego Jaspana Improved Persistent Login Cookie

Jeśli masz pytania, opinie lub sugestie, postaram się zaktualizować diagram, aby odzwierciedlić dla nowicjusza próbującego zaimplementować bezpieczne trwałe logowanie.

Implementacja funkcji "bądź zalogowany" oznacza, że musisz dokładnie określić, co to będzie oznaczać dla użytkownika. W najprostszym przypadku użyłbym tego, aby oznaczać, że sesja ma znacznie dłuższy czas oczekiwania: 2 dni (powiedzmy) zamiast 2 godzin. Aby to zrobić, potrzebujesz własnego magazynu sesji, prawdopodobnie w bazie danych, dzięki czemu możesz ustawić niestandardowe czasy wygaśnięcia danych sesji. Następnie należy upewnić się, że ustawiono plik cookie, który pozostanie na kilka dni (lub dłużej), a nie wygaśnie po zamknięciu przeglądarka.

Słyszę, jak pytasz " dlaczego 2 dni? dlaczego nie 2 tygodnie?". Dzieje się tak dlatego, że użycie sesji w PHP automatycznie przesunie wygaśnięcie. Dzieje się tak dlatego, że wygaśnięcie sesji w PHP jest w rzeczywistości bezczynnym timeoutem.

Teraz, powiedziawszy to, prawdopodobnie zaimplementowałbym trudniejszą wartość timeout, którą przechowuję w samej sesji, a na około 2 tygodnie, i dodał kod, aby to zobaczyć i siłą unieważnić sesję. Albo przynajmniej je wylogować. Oznacza to, że użytkownik zostanie poproszony o okresowe logowanie. Yahoo! czy to.