Який найкращий спосіб застосувати "запам'ятати мене" для веб-сайту? [зачинено]

510

Я хочу, щоб на моєму веб-сайті було встановлено прапорець, який користувачі можуть натискати, щоб не потрібно було входити в систему під час кожного відвідування мого веб-сайту. Я знаю, що мені потрібно буде зберегти печиво на своєму комп’ютері, щоб це здійснити, але що має міститись у цьому файлі cookie?

Крім того, чи є загальні помилки, на які слід стежити, щоб цей файл cookie не представляв уразливості безпеки, чого можна уникнути, надаючи функціонал "запам'ятати мене"?

security cookies remember-me

— Vort3x
джерело

5

Перевірте stackoverflow.com/questions/549/… (частина II головної відповіді)

— Frosty Z

якщо ви використовуєте ASP.NET, перегляньте codeproject.com/Articles/779844/Remember-Me

— Believe2014,

1

У Security SE ~ security.stackexchange.com/questions/19676/…

— b1nary.atr0phy

На даний момент прийнята відповідь splattne надмірно складна. Створіть маркер +16 байт з випадкового джерела, хеште його та збережіть ідентифікатор хеш + акаунта в базі даних. Потім відправте маркер користувачеві (закодований base64) у файлі cookie HTTPS + httpOnly (тому Javascript не може отримати доступ / викрасти його). Таким чином, ніхто не може вгадати маркер або видалити людей з невірними здогадами, але навіть якщо ваша база даних зламана, ніхто не може використовувати жетони в базі даних (вони хешировані). Тож користуватися ним може лише оригінальний клієнт (або той, хто якось краде маркер із магазину браузера).

— Ксеонкросс

536

Покращений досвід роботи зі збереженим файлом cookie

Ви можете використовувати цю описану тут стратегію як найкращу практику (2006) або оновлену стратегію, описану тут (2015):

Коли користувач успішно входить у систему з позначкою "Запам'ятати мене", на додаток до стандартного файлу cookie управління сеансом видається печиво для входу .
Файл cookie для входу містить ідентифікатор серії та маркер . Серія та маркер - це непридатні випадкові числа з відповідно великого простору. Обидва зберігаються разом у таблиці бази даних, маркер хешований (sha256 - це добре).
Коли користувач, що не входить в систему, відвідує сайт і представляє файли cookie для входу, ідентифікатор серії шукається в базі даних .
1. Якщо ідентифікатор серії присутній і хеш маркера відповідає хешу для цього ідентифікатора серії, користувач вважається автентифікованим . Створюється новий маркер , новий хеш для маркера зберігається над старою записом, а користувачеві видається новий файл cookie (нормально повторно використовувати ідентифікатор серії ).
2. Якщо серія присутня, але маркер не збігається, передбачається крадіжка . Користувач отримує чітко сформульоване попередження і всі запам’ятовані користувачем сесії видаляються.
3. Якщо ім'я користувача та серія відсутні, файли cookie для входу ігноруються .

Такий підхід забезпечує глибоку оборону. Якщо комусь вдається витікнути таблицю бази даних, це не дає зловмиснику відкритих дверей для видавання себе за користувачів.

— splattne
джерело

20

дивіться також: stackoverflow.com/questions/549/… НЕ слід читати "покращену" версію

— Jacco

8

Проблема з цим полягає в тому, що ви відкриваєте ім'я користувача у файлі cookie, хоча це робить Gmail. Для чого потрібні ідентифікатор серії, і маркер? Невже більший жетон не буде добре?

— Дан Розенстарк

10

Також щодо цієї моделі, що це не дозволяє злочинцю викрасти крадіжки, а потім розмістити файли cookie на своєму комп’ютері та видалити файли cookie зі зламаного комп'ютера. Його комп'ютер замість того, щоб аутентифікувати та оновлювати, як потрібно, із зламаним комп’ютером, що коли-небудь знає? Єдина зміна полягала б у тому, що користувачеві, що зламав комп’ютери, доведеться знову входити в систему та налаштовувати на мене запам'ятовування. Незалежно від того, визнає зламаний користувач, це було б невизначено.

24

@HiroProtagonist Ідентифікатор серії призначений для запобігання DoS-атаки. Без цього я міг би швидко написати сценарій, що вражає ваш сайт із кожним іменем користувача та недійсним маркером, вилучаючи всіх із вашого сайту.

— Кріс Москіні

6

Це рішення WRONG, воно не обробляє певну валюту: якщо одночасно надходять два запити аутентифікації пам'яті, з одним і тим же файлом cookie-пам'яті, перший успішно змінює маркер, другий викликає невдалу автентифікацію, і помилковий сигнал тривоги (оскільки маркер уже змінено першим запитом). (Така ситуація може статися, коли браузер запускається, а сайт відновлюється на двох вкладках браузера.)

— slobo

9

Я б зберігав ідентифікатор користувача та маркер. Коли користувач повертається на сайт, порівняйте ці два відомості з чимось стійким, як-от запис бази даних.

Що стосується безпеки, просто не вкладайте нічого, що дозволить комусь змінити файл cookie, щоб отримати додаткові переваги. Наприклад, не зберігайте їх групи користувачів або їх пароль. Все, що може бути змінено, що б обходило вашу безпеку, не повинно зберігатися у файлі cookie.

— драконів
джерело

8

Зберігайте їх UserId та RememberMeToken. Коли ви входите в систему, щоб перевірити мене, згенеруйте новий RememberMeToken (який визнає недійсним будь-які інші позначені машини запам'ятають мене).

Коли вони повернуться, перегляньте їх на жетон запам'ятовування і переконайтеся, що UserId відповідає.

— jonnii
джерело

Це може бути жорстоко змушене за лічені секунди. Я просто встановлю свій user_id на 1 і грубою формою всіх жетонів. Це дасть мені доступ за лічені секунди

— Друг

4

Досліджуючи постійні сеанси, я виявив, що це просто не варто ризикувати безпекою. Використовуйте його, якщо вам абсолютно доведеться, але ви повинні вважати такий сеанс лише слабкою аутентифікацією та змусити новий логін для будь-якого, що може нанести користі зловмиснику.

Причина, звичайно, полягає в тому, що файли cookie, що містять ваш постійний сеанс, так легко вкрадаються.

4 способи вкрасти куки (з коментаря Йенса Роланда на сторінці, @splattneспираючись на його відповідь):

Перехоплюючи його через незахищену лінію (викрадення пакетів / захоплення сеансу)
Прямий доступ до браузера користувача (через зловмисне програмне забезпечення або фізичний доступ до вікна)
Читаючи його з серверної бази даних (можливо, SQL Injection, але може бути що завгодно)
Шляхом злому XSS (або подібного використання на стороні клієнта)

— Jarl
джерело

104

1. HTTPS призначений для запобігання цього. 2. Будьте увійшли в систему - це не проблема безпеки, у вас є більші проблеми. 3. Те саме, що і 2. 4. Цьому можна запобігти за допомогою політики контролю доступу та належної санітарії введення; якщо ви не зробите цих кроків, у вас знову будуть більші проблеми, ніж залишатися в системі.

— Кріс Москіні