Jak najlepiej wdrożyć „zapamiętaj mnie” dla strony internetowej? [Zamknięte]

510

Chcę, aby moja witryna miała pole wyboru, które użytkownicy mogą kliknąć, aby nie musieli się logować przy każdej wizycie na mojej stronie. Wiem, że będę musiał przechowywać plik cookie na ich komputerze, aby to zaimplementować, ale co powinno być zawarte w tym pliku cookie?

Czy są też często popełniane błędy, na które należy uważać, aby ten plik cookie nie zawierał luki w zabezpieczeniach, której można by uniknąć, zapewniając jednocześnie funkcję „zapamiętaj mnie”?

security cookies remember-me

— Vort3x
źródło

5

Sprawdź stackoverflow.com/questions/549/… (część II najwyższej odpowiedzi)

— Frosty Z

jeśli używasz ASP.NET, sprawdź codeproject.com/Articles/779844/Remember-Me

— Believe2014

1

Istnieje kilka bardzo przydatnych informacji w Security SE ~ security.stackexchange.com/questions/19676/…

— b1nary.atr0phy

Akceptowana obecnie odpowiedź splattne jest zbyt skomplikowana. Utwórz token +16 bajtów z losowego źródła, zaszyfruj go i zapisz identyfikator hash + konta w bazie danych. Następnie wyślij token do użytkownika (zakodowany w standardzie base64) w pliku cookie HTTPS + httpOnly (aby JavaScript nie mógł uzyskać do niego dostępu / ukraść go). W ten sposób nikt nie może odgadnąć tokena ani wylogować się z niepoprawnymi odgadnięciami, ale nawet jeśli twoja baza danych zostanie zhakowana, nikt nie będzie mógł używać tokenów w bazie danych (są one mieszane). Tak więc tylko oryginalny klient (lub ktoś, kto kradnie token ze sklepu przeglądarki) może go używać.

— Xeoncross

536

Ulepszone trwałe logowanie do plików cookie Najlepsze praktyki

Możesz użyć tej strategii opisanej tutaj jako najlepszej praktyki (2006) lub zaktualizowanej strategii opisanej tutaj (2015):

Gdy użytkownik pomyślnie zaloguje się przy zaznaczonej opcji Zapamiętaj mnie, oprócz standardowego pliku cookie zarządzania sesją wydawany jest plik cookie logowania .
Plik cookie do logowania zawiera identyfikator serii i token . Szereg i żeton to niewyobrażalne losowe liczby z odpowiednio dużej przestrzeni. Oba są przechowywane razem w tabeli bazy danych, token jest mieszany (sha256 jest w porządku).
Gdy niezalogowany użytkownik odwiedza witrynę i przedstawia plik cookie służący do logowania, identyfikator serii jest sprawdzany w bazie danych .
1. Jeśli identyfikator serii jest obecny, a skrót tokena jest zgodny z skrótem tego identyfikatora serii, użytkownik jest uważany za uwierzytelniony . Nowy żeton generowany jest nowy hash dla tokena jest przechowywany w stosunku do starego rekordu, a nowy logowanie cookie jest wydawana użytkownika (to jest w porządku, aby ponownie użyć identyfikatora serii ).
2. Jeśli seria jest obecna, ale token nie pasuje, zakłada się kradzież . Użytkownik otrzymuje ostro sformułowane ostrzeżenie, a wszystkie zapamiętane sesje użytkownika są usuwane.
3. Jeśli nazwa użytkownika i seria nie są obecne, plik cookie logowania jest ignorowany .

Takie podejście zapewnia dogłębną obronę. Jeśli komuś uda się przeciekać tabelę bazy danych, nie daje atakującemu otwartych drzwi do podszywania się pod użytkowników.

— splattne
źródło

20

patrz także: stackoverflow.com/questions/549/ ... NIE powinieneś czytać wersji „ulepszonej”

— Jacco

8

Problem polega na tym, że ujawniasz nazwę użytkownika w pliku cookie, ale to właśnie robi Gmail. Dlaczego potrzebujesz zarówno identyfikatora serii, jak i tokena? Czy większy token nie byłby w porządku?

— Dan Rosenstark

10

Również w odniesieniu do tego modelu, co ma zapobiec atakowi, który może ukraść, a następnie umieścić plik cookie na swoim komputerze i usunąć plik cookie z zaatakowanego komputera. Jego komputer byłby wtedy uwierzytelniany i aktualizowany w razie potrzeby bez wiedzy hakowanego komputera? Jedyną zmianą byłoby to, że użytkownik zaatakowanych komputerów musiałby zalogować się ponownie i ustawić zapamiętaj mnie. To, czy zaatakowany użytkownik rozpozna to, byłoby niepewne.

24

@HiroProtagonist Identyfikator serii ma zapobiegać atakowi DoS. Bez tego mógłbym szybko napisać skrypt uderzający w twoją witrynę przy każdej nazwie użytkownika i niepoprawnym tokenie, wylogowując wszystkich na twojej stronie.

— Chris Moschini,

6

To rozwiązanie jest NIEPRAWIDŁOWE, nie obsługuje współbieżności: jeśli dwa żądania uwierzytelnienia „zapamiętaj mnie” z tym samym plikiem cookie „zapamiętaj mnie”, pierwsze powiedzie się i zmieni token, drugie spowoduje nieudane uwierzytelnienie i fałszywy alarm (ponieważ token został już zmieniony przez pierwsze żądanie). (Taka sytuacja może się zdarzyć, gdy uruchomi się przeglądarka, a strona zostanie przywrócona na dwóch kartach przeglądarki.)

— slobo

9

Przechowałbym identyfikator użytkownika i token. Gdy użytkownik wróci do witryny, porównaj te dwie informacje z czymś trwałym, takim jak wpis w bazie danych.

Jeśli chodzi o bezpieczeństwo, po prostu nie umieszczaj w nim niczego, co pozwoli komuś zmodyfikować plik cookie, aby uzyskać dodatkowe korzyści. Na przykład nie przechowuj ich grup użytkowników ani hasła. Cokolwiek, co można zmodyfikować, co obejdzie Twoje bezpieczeństwo, nie powinno być przechowywane w pliku cookie.

— Dragonmantank
źródło

8

Przechowuj ich UserId i RememberMeToken. Kiedy logują się przy użyciu zapamiętaj mnie zaznaczone, wygeneruj nowy RememberMeToken (które unieważniają wszystkie inne zaznaczone maszyny zapamiętują mnie).

Kiedy wrócą, odszukaj je według tokena zapamiętaj mnie i upewnij się, że identyfikator użytkownika pasuje.

— jonnii
źródło

Można to brutalnie wymusić w kilka sekund. Po prostu ustawię identyfikator_użytkownika na 1 i brutalnie wykorzystam wszystkie tokeny. Umożliwi mi dostęp w ciągu kilku sekund

— przyjaciel

4

Sam badając trwałe sesje, odkryłem, że po prostu nie warto ryzykować. Skorzystaj z niego, jeśli absolutnie musisz, ale powinieneś rozważyć taką sesję tylko słabo uwierzytelnioną i wymusić nowy login dla wszystkiego, co może mieć wartość dla atakującego.

Powodem jest oczywiście to, że pliki cookie zawierające trwałą sesję są tak łatwo kradzione.

4 sposoby na kradzież plików cookie (od komentarza Jensa Rolanda na stronie @splattneopartej na jego odpowiedzi):

Przechwytując go przez niezabezpieczoną linię (wąchanie pakietów / przejęcie sesji)
Poprzez bezpośredni dostęp do przeglądarki użytkownika (poprzez złośliwe oprogramowanie lub fizyczny dostęp do skrzynki)
Czytając go z bazy danych serwera (prawdopodobnie SQL Injection, ale może być dowolny)
Przez hack XSS (lub podobny exploit po stronie klienta)

— Jarl
źródło

104

1. HTTPS został zaprojektowany, aby temu zapobiec. 2. Pozostań zalogowany nie jest tutaj problemem bezpieczeństwa, masz większe problemy. 3. To samo co 2. 4. Można temu zapobiec dzięki polityce kontroli dostępu i dobrym warunkom sanitarnym; jeśli nie podejmiesz tych kroków, ponownie będziesz mieć większe problemy niż Pozostań zalogowany.

— Chris Moschini,