Кращі практики для автентифікації / безпеки веб-додатків (будь-яка платформа)


12

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

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

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

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

Чи є основні недоліки безпеки при такому підході? Чи є якісь кращі пропозиції?


Зберігаючи зашифрований односторонній (тобто хешований) пароль, переконайтеся, що ви або використовуєте сильний хеш (тобто не MD5) або соліть пароль (див. Stackoverflow.com/questions/420843/… ) або і те і інше.
Jordan Reiter

Перегляньте веб-сайт OWASP ( owasp.org ). У них багато дуже корисної інформації про безпеку, включаючи "шпаргалки" для різних протоколів.
Ральф

Тут є кілька вказівок щодо автентифікації веб-сайтів на основі форм. Тут stackoverflow.com/a/477578/463478
Тільки ти

Відповіді:


13

Деякі поради високого рівня:

  1. Зберігайте лише потрібні вам дані
  2. Завжди шифруйте конфіденційні дані (SSN, пароль, номер кредитної картки тощо), коли ви їх зберігаєте
  3. Завжди шифруйте трафік за допомогою SSL під час передачі / отримання конфіденційних даних
  4. Якщо ви сумніваєтесь у чутливості інформації, зашифруйте її
  5. Не довіряйте вводу користувачів (хтось спробує ввести щось погане)
  6. Не довіряйте своїм даним (хтось може змінити їх у базі даних - наприклад, ввести шкідливий скрипт)
  7. Не розгортайте власне шифрування
  8. Захистіть сервери, що розміщують додатки / бази даних
  9. Збільште навантаження на кінцевих користувачів заради безпеки (обмеження паролів, ніколи не виставляйте паролі, не надсилайте URL-адреси електронною поштою, скорочуйте час сеансу тощо)

Я б вам запропонував придбати книгу про безпеку веб-додатків. Є просто занадто багато інформації, щоб передати в одній відповіді / блозі / статті. Сама тема шифрування є суттєвою.


Які міркування щодо використання SSL замість того, щоб розгорнути власне шифрування? Чи могли б ви використати щось на зразок WS-Security для прокатки власного шифрування? Налаштування SSL може бути болем.
Містер Джефферсон

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

2
@ Mr.Jefferson Я б сказав, що 99,999999% часу ви НІКОЛИ не хочете "котити власне шифрування".
Зак Лейтон

2

Ви можете спробувати перевершити поведінку веб-переглядача - кілька хороших порад тут:

/programming/32369/disable-browser-save-password-functionality


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

1

Я б сказав, що ти маєш добре.

Більшість користувачів будуть досить яскравими, щоб не зберігати свій пароль на загальнодоступному терміналі, а паролі зберігатимуться в одному профілі. Майте на увазі, що вони так само легко могли написати це на клейкій записці або використовувати слабкий пароль.

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

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


Чудовий пост, я забув додати, хоча ім'я користувача не буде адресою електронної пошти, проте користувач матиме електронну адресу, збережену в системі. Смішно ви згадуєте про це, хоча тому, що навіть такі популярні веб-сайти, як Facebook, сприйнятливі до нюхання пакетів за адресами електронної пошти та паролями.
maple_shaft

Я також хочу додати, що я не вказую на недоліки безпеки у Facebook як «привід» обов'язково для поганої моделі безпеки в моїй заяві. Тільки тому, що мама Джої дозволяє йому дивитись
рейтинги

1

У певний момент ви не можете (і не вимагаєте законного захисту) користувача від себе. Функція "Запам'ятати пароль" може бути ризикованою, але це ризик, який бере на себе користувач. Так само, якщо користувач вирішив повторно використовувати свій пароль для декількох послуг, він також бере на себе цей ризик. Ви також не зобов’язані попереджати їх про те, щоб не записувати свій пароль на клейкій примітці і не приклеювати їх до свого монітора, навіть якщо користувачі часто це роблять.

Тобто, поки хтось успішно не судиться і не змінить правила. Дивіться також: "Попередження: вміст може бути гарячим".


0

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

Я здогадуюсь, що ви можете зробити, це кожен раз рандомізувати імена полів у формі реєстрації. Замість цього <input name="username"використовуйте щось подібне <input name="user658667587". Це зробить кешовані імена користувачів марними. Але я не знаю, чи варто було б накладні витрати. Не кажучи вже про незручні користувачі, які не відвідують громадські машини.

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.