Zapamiętaj mnie Cookie best practice?

Question

Mam na sobie wiele starych pytań na temat tego argumentu i myślę, że uważam, że najlepszą praktyką jest utworzenie pliku cookie z username, user_id i losowym tokenem.

Te same dane cookie są przechowywane w DB przy tworzeniu plików cookie, a gdy użytkownicy mają plik cookie, są porównywane (dane cookie, dane DB).

Pozdrawiam, że nie mogę zrozumieć, gdzie jest logika bezpieczeństwa, jeśli jest to najlepsza praktyka.

Osoba atakująca, która kradnie plik cookie, ma to samo ciasteczko, co oryginalny użytkownik: |

Zapomniałeś jakiegoś kroku? : P

Answer 1

Powinieneś przechowywać numer user_id i dodatkowo losować token jako hasło użytkownika. Użyj tokena w pliku cookie i zmień token po zmianie hasła. W ten sposób, jeśli użytkownik zmieni swoje hasło, plik cookie zostanie unieważniony.

Jest to ważne, jeśli plik cookie został przejęty. Zostanie ono unieważnione, jeśli użytkownik wykryje porwanie, a ponadto, ponieważ token nie ma związku z hasłem, którego porywacz nie będzie mógł uzyskać, a następnie zmieni hasło konta użytkownika i "będzie właścicielem" konta (zakładając, że potrzebujesz istniejącego hasła przed zmianą haseł porywacz nie jest właścicielem konta e-mail, więc nie może używać "Nie pamiętam hasła" itp.).

Uważaj, aby tokeny nie były łatwe do odgadnięcia (tj. Powinny składać się z całkowicie losowych danych, np. Z CRNG).

Jeśli chcesz pójść o krok dalej, możesz zaszyfrować plik cookie przed wysłaniem go i odszyfrować go przy odbiorze. Co więcej, nie zakładaj, że porywacz nie zna klucza szyfrowania, więc sprawdź poprawność zawartości pliku cookie po odszyfrowaniu.

Ale wszystko, co powiedzieliśmy, wolimy używać stałego zarządzania sesją biblioteki zamiast przewracać własne.

Answer 2

Zawsze wiedziałem, że funkcja "zapamiętaj mnie" tylko przekształciła plik cookie sesji (np. Plik cookie z identyfikatorem sesji) z wygasającego przy zamykaniu przeglądarki na przyszłą datę, nie wiąże się z koniecznością zapisywania dodatkowych danych, tylko przedłużanie sesji.

I tak, jeśli osoba atakująca otrzyma plik cookie, może podszyć się pod użytkownika. Ale jest to zawsze ważne i nie ma nic wspólnego z "pamiętaj mnie".

Answer 3

jeśli Twoje pliki cookie zostaną skradzione, każdy może zalogować się na Twoje konta. w rzeczywistości to, co robi fajerwerk. zabezpieczenie polega na losowym tokenie. cały system zakłada, że ​​ciasteczka nie mogą zostać skradzione. jedyny inny sposób na wejście to odgadnięcie losowego tokena. jeśli zrobisz to wystarczająco długo, powinno być prawie niemożliwe.

Answer 4

"Krok", o którym wydaje się, że zapominasz, jest taki, że jeśli wartość pliku cookie zostanie odpowiednio zakodowana, będzie miała niewielką wartość dla atakującego.

EDIT:

Oto kilka rzeczy, które możesz zrobić, aby chronić użytkowników przed kradzieżą Cookie związanych ataków:

• zregenerować żetonów w czasie, tak, że atakujący nie będzie w stanie podszywać użytkownika, chyba że ma wystarczająco dużo plików cookie. Jeśli bezpieczeństwo ma najwyższy priorytet, zregeneruj tokeny przy każdym żądaniu (ładowanie strony). Jeśli nie jest, zregeneruj tokeny po zmianie hasła.
• Przechowuj i sprawdzaj skróty user agents, aby osoba atakująca nie mogła podszyć się pod użytkownika, chyba że ma zarówno plik cookie, jak i agenta użytkownika użytkownika.

p.s. Pliki cookie powinny zawierać (losowe) tokeny, a nie hasze hasła (patrz Hashes or tokens for "remember me" cookies?).

Answer 5

nawet bym nie przechowuj nazwy użytkownika w pliku cookie, tylko losowy żeton wygenerowany near impossible to crack technique i map, które dla użytkownika w bazie danych, a nigdy sklep hasło użytkownika nawet zakodowane w pliku cookie, to będzie otwarte na Brute Force Attack. Tak, jeśli ktoś ukradnie token, będzie mógł uzyskać dostęp do konta użytkownika, ale hasło nie zostanie naruszone, a token zostanie unieważniony, gdy tylko prawdziwy użytkownik się wyloguje. Należy również pamiętać, że nie należy zezwalać na newralgiczne zadania, takie jak zmiana hasła dla użytkownika, który ma już ważny token, należy ponownie poprosić o hasło w przypadku takich zadań.

Answer 6

Moje podejście jest następujące:

1. Hash user_id
2. wygenerować unikalny klucz dla użytkownika - md5(current_timestamp)
3. Zapisz klucz do DB
4. Koduje wszystko tak wygląda jak BS - base64
5. Zachowaj w pliku cookie

Do tej pory działało dobrze dla mnie :)

Answer 7

NIGDY nie należy przechowywać hasła użytkownika w pliku cookie, nawet jeśli jest zaszyfrowane !!

Spójrz na tym blogu:

• Improved Persistent Login Cookie Best Practice (Nov 2006; by bjaspan) (orignal)

Cytat:

1. Gdy użytkownik pomyślnie loguje się z Remember Me zaznaczone, Plik cookie logowania jest wydany jako dodatek do standardowego pliku cookie zarządzania sesją. [2]
2. Plik cookie logowania zawiera nazwę użytkownika, identyfikator serii i token. Seria i token to niepotrzebne liczby losowe z odpowiednio dużej przestrzeni. Wszystkie trzy są przechowywane razem w tabeli bazy danych.
3. Gdy niezalogowany użytkownik odwiedza witrynę i prezentuje cookie logowania, nazwa użytkownika, seria i token są wyszukiwane w bazie danych.
4. Jeśli triol jest obecny, użytkownik jest uznawany za uwierzytelniony. Używany token jest usuwany z bazy danych. Nowy token jest generowany, przechowywany w bazie danych z nazwą użytkownika i tym samym identyfikatorem serii, a nowy plik cookie do logowania, zawierający wszystkie trzy, jest wydawany użytkownikowi.
5. Jeśli nazwa użytkownika i seria są obecne, ale token nie pasuje, zakłada się kradzież. Użytkownik otrzymuje ostrzeżenie o silnym brzmieniu i wszystkie zapamiętane sesje użytkownika są usuwane.
6. Jeśli nazwa użytkownika i seria nie są obecne, plik cookie logowania jest ignorowany.