Як надійно реалізувати автоматичний вхід

Я читав багато, багато, багатьох дописів про те, як "ви, мабуть, неправильно зберігаєте паролі". Вони завжди мають на увазі збереження паролів на сервері, на який користувач здійснює вхід; вони в основному переспівують всюдисущі поради (наприклад, переконайтеся, що соліть паролі тощо). Однак я ніколи не бачив статті про найкращі практики зберігання паролів на клієнті, щоб клієнту не довелося входити в систему вручну кожного разу, коли вони хочуть увійти; функція "запам'ятати мене".

Багато програмного забезпечення мають цю функцію - від браузерів до таких програм, як Dropbox.

Нещодавно я читав стару статтю про те, як Dropbox зберігає ідентифікатор на вашому комп’ютері, що ви можете просто скопіювати / вставити на інший комп'ютер і запустити Dropbox і ввійти в систему як пристрій, з якого ви отримали ідентифікатор; ні входу, ні нічого, і повний доступ до облікового запису Dropbox. Це здається дійсно дурним дизайном, але я не можу придумати кращого способу зробити це.

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

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

Що я можу прочитати про безпечне зберігання облікових даних для безпечного використання функції автоматичного входу? Якщо принципи занадто прості для всієї статті, які вони? Програмне забезпечення, про яке йдеться, не повинно залежати від функцій, наявних на всіх платформах (як, наприклад, "брелок брелоків", які мають деякі дистрибутиви Linux).

Один із способів:

• Коли користувач увійде в систему, збережіть ідентифікатор сеансу у файлі cookie на комп'ютері клієнта (а не ім’я користувача або пароль).
• Прив’яжіть сеанс до IP-адреси, тому індивідуальний ідентифікатор сеансу працює лише з комп'ютера, на якому він був запущений.

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

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

Оновлення: Окрім того, використовуйте HTTPS для підвищення безпеки, очевидно.

Оновлення 2: Зауважте, що цей підхід має обмеження, оскільки він не працює добре для користувачів, які сильно змінюють свою IP-адресу. Однак це забезпечує підвищений рівень безпеки і може бути корисним у деяких ситуаціях.

Амазонка (та багато інших) використовують гібридний підхід. Вони забезпечують автоматичний вхід для перегляду, додавання предметів у кошик та розміщення замовлень, використовуючи комбінації кредитних та адресних адрес, які ви використовували раніше. Однак вони вимагають ввести пароль для багатьох дій, таких як додавання кредитних карток, додавання / зміна адрес доставки, оновлення паролів, перегляд минулих замовлень (необов’язково для користувача) та безліч інших налаштувань облікового запису.

Так, так, люди, які отримують доступ до вашого комп'ютера, можуть захопити ваш сеанс, але ви все одно отримаєте те, що замовляєте! (Що ще важливіше, стимул до викрадення сеансу в значній мірі заперечується.) Але якщо хтось має доступ до мого комп'ютера, у мене є більші проблеми, ніж у людей, які крадуть середні сеанси на сайті.

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

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

Насправді це не так складно. Спочатку збережіть файл cookie у такому форматі:

userID.token

Ви можете використовувати хеш sha1 для маркера. Потім у вашій таблиці таблиць баз даних Remember_me_tokens зберігається userID, bcrypt хеш маркера та час генерування маркера.

Потім, коли хтось відвідує ваш сайт, перевірте, чи встановлено файл cookie. Якщо файл cookie встановлено, то подивіться, чи є в базі даних дійсна рядок за останні 7 днів, скажімо. Якщо в базі даних для файлу cookie є дійсний рядок, тоді встановіть сеанс, щоб вказати, що користувач увійшов у систему, а також видаліть відповідні рядки файлів cookie / бази даних та генерують новий рядок файлів cookie / token / database.

Якщо вони вийдуть із системи, видаліть файл cookie.

Виконайте роботу з кроном, щоб обрізати пам'ять_me_tokens, старші, ніж скажімо, на 7 днів.

Ви можете, лише якщо довіряти пристрою, де ви його зберігаєте. Користувач (якщо ви не можете впливати на пристрій) залежить від того, наскільки він захищений. Це просто з ваших рук.

Як зазначено в коментарях:

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