Питання Остаточне керівництво для автентифікації веб-сайтів на основі форм [closed]


Аутентифікація на основі форм для веб-сайтів

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

Вона повинна включати такі теми, як:

  • Як увійти
  • Як вийти
  • Як залишитися в системі
  • Керування файлами cookie (включаючи рекомендовані налаштування)
  • SSL / HTTPS шифрування
  • Як зберігати паролі
  • Використання секретних питань
  • Забуті функціональність імені користувача та пароля
  • Використання ноки запобігати Перехресне запит на підробку (CSRF)
  • OpenID
  • Прапорець "Запам'ятати мене"
  • Автозавершення браузера для імен користувачів та паролів
  • Секретні URL-адреси (загальнодоступні URL-адреса захищений дайджестом)
  • Перевірка сили пароля
  • Перевірка електронної пошти
  • і багато чого іншого  Аутентифікація на основі форми...

Вона не повинна містити такі речі:

  • Ролі та авторизація
  • Базова аутентифікація HTTP

Будь ласка, допоможіть нам:

  1. Пропонуємо підтеми
  2. Надсилання хороших статей про цю тему
  3. Редагування офіційної відповіді

5002


походження


Чому виключити основну автентифікацію HTTP? Він може працювати в форматах HTML через Ajax: peej.co.uk/articles/http-auth-with-html-forms.html - system PAUSE
HTTP Basic Auth має властивість бути (порівняно) важко заблокувати браузер. Це також жахливо небезпечно, якщо ви не використовуєте його за допомогою протоколу SSL для захисту з'єднання (наприклад, HTTPS). - Donal Fellows
Я думаю, варто було б говорити про сесії (включаючи фіксацію та викрадення) файли cookie (безпечні та лише http-прапори) SSO на базі HTTP - symcbean
Супер корисний HttpOnly Флаг cookie, який перешкоджає крадіжці файлів cookie на основі JavaScript (підмножину атак XSS), слід також згадати де-небудь. - Alan H.
Ого. Довгі відповіді, десятки варіантів для деяких з них, однак ніхто не згадує про загальну помилку подання форм реєстрації через HTTP. Я навіть стверджував з людьми, які сказали ", але це подає на https: // ...", і я отримав лише порожні зірки, коли я запитав, чи вони впевнені, що зловмисник не переписав незашифровану сторінку, яку подано за формою . - dzuelke


Відповіді:


Частина I: Як ввійти

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

HTTPS або не HTTPS?

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

По суті справи практичний Спосіб захисту від прослуховування / шифрування пакетів під час входу в систему - це використання протоколу HTTPS або іншої схеми шифрування на основі сертифікатів (наприклад, TLS) або перевіреною та перевіреною схемою відповідей на виклик-реакцію (наприклад, Діффі-Хелманна основі SRP). Будь-який інший спосіб можна легко обійти підозрюваним нападником.

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

(Не треба) Перемістити власний JavaScript шифрування / хешування

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

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

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

CAPTCHAS проти людства

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

Знайте, що реалізація CAPTCHA не створюється однаково; вони часто не вирішені людьми, більшість з них фактично неефективні проти ботів, всі вони неефективні проти дешевої робочої сили третього світу (згідно з OWASP, поточний курс sweatshop становить 12 доларів за 500 тестів), а деякі реалізації можуть бути технічно незаконними в деяких країнах (див Cheat Sheet для автентифікації OWASP) Якщо ви повинні використовувати CAPTCHA, використовуйте Google reCAPTCHA, оскільки за визначенням він може бути OCR-твердим (оскільки він використовує вже скановані книги, не класифіковані OCR), і намагається дуже важко бути зручним для користувача.

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

Зберігання паролів / перевірка логінів

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

Отже, якщо ви не можете зберегти пароль, як перевірити, чи правильна кодова логін + пароль POSTed з форми входу? Відповідь - це хешування за допомогою a ключ деривації функції. Кожного разу, коли створюється новий користувач або пароль змінюється, ви отримуєте пароль і запускаєте його через KDF, наприклад, Argon2, bcrypt, scrypt або PBKDF2, перетворюючи пароль cleartext ("correcthorsebatterystaple") у довгу, випадково виглядаючу ланцюжок , що набагато безпечніше зберігати у вашій базі даних. Щоб перевірити вхід, ви виконуєте ту ж хеш-функцію на введеному паролі, пропустіть цей час у солі та порівняйте отриманий хеш-рядок із значенням, збереженим у вашій базі даних. Argon2, bcrypt і scrypt зберігають сіль з хешем вже. Перевірте це стаття на sec.stackexchange для більш детальної інформації.

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

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

Дані сеансу - "Ви ввійшли як Spiderman69"

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

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

Якщо взагалі можливо, переконайтеся, що файли cookie сеансу мають безпечний набір і прапори HTTP Only під час надсилання в браузер. Прапор httponly забезпечує деякий захист від файлу cookie, який читається за допомогою атаки XSS. Захищений прапор гарантує, що файли cookie відправляються лише через HTTPS, і тому захищає від атак мережевої нюху. Значення файлу cookie не повинно бути передбачуваним. Там, де представлений файл cookie, що посилається на неіснуючий сеанс, його значення слід негайно замінити, щоб запобігти фіксація сесії.

ЧАСТИНА II: Як залишитись увійти в систему - позначка "Запам'ятати мене"

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

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

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

Якщо ви вирішите запровадити постійні файли cookie для входу, це так:

  1. По-перше, займе якийсь час, щоб прочитати Стаття "Ініціативи" Paragon на цю тему. Вам потрібно буде отримати цілий ряд елементів правильно, і ця стаття робить чудову роботу з пояснення кожного.

  2. І щоб повторювати одне з найпоширеніших підводних каменів, НЕ ЗБЕРІГАЙТЕ ПОСТІЙНИЙ ЛОГІН КУКИ (TOKEN) ВАШИЙ БАЗИ ДАНИХ, ТІЛЬКИ ХАШЕ З НЬОГО! Логін для входу є еквівалентним паролем, тому, якщо зловмисник отримав руки в своїй базі даних, вони могли б використовувати токени, щоб увійти в будь-яку обліковий запис, так само, якби вони являли собою комбінації явних кодів логіну. Тому використовуйте хешування (відповідно до https://security.stackexchange.com/a/63438/5002 слабкий хеш буде робити це добре для цієї мети) при зберіганні стійких векселів входу.

ЧАСТИНА III: Використання секретних питань

Не виконуйте "секретні запитання". Функція "секретні запитання" - анти-шаблон безпеки. Прочитайте статтю з посилання №4 з списку "ПОВИННІ-ЧИТАЙТЕ". Ви можете попросити Сари Пейлін про те, що вона, після її Yahoo! Електронна пошта була зламана під час попередньої президентської кампанії, оскільки відповідь на її питання безпеки ... "Wasilla High School"!

Навіть із заданими користувачем питаннями, дуже ймовірно, що більшість користувачів вибере:

  • Таємне "стандартне" питання, як дівоче прізвище матері або улюблене тварина

  • Простий шматочок дрібниці, які хтось міг вивести з свого блогу, профілю LinkedIn або подібного

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

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

Справжня причина того, чому питання безпеки навіть існують в дикій природі, полягає в тому, що вони зручно заощаджують вартість кількох дзвінків підтримки від користувачів, які не можуть отримати доступ до їх електронної пошти, щоб отримати код для повторного активації. Це за рахунок безпеки і репутації Сари Пейлін. Варто це? Напевно ні.

ЧАСТИНА IV: Функціональність забутого пароля

Я вже згадав, чому ти повинен це зробити Ніколи не використовуйте питання безпекидля обробки забутих / втрачених паролів користувача; це також, зрозуміло, не повинно ніколи повідомляти користувачам свої фактичні паролі. Існує щонайменше ще два надзвичайно поширені підводні камені, які потрібно уникнути в цій галузі:

  1. Не треба скинути забутий пароль для автоматично створений сильний пароль - такі паролі, як відомо, важко запам'ятати, що означає, що користувач повинен або змінити його, або записати його - скажімо, на яскраво-жовтому Post-It на краю монітора. Замість того, щоб встановити новий пароль, просто дозвольте користувачам одразу вибрати одне - саме це вони хочуть в будь-якому випадку. (Виключення з цього може бути, якщо користувачі універсально використовують менеджер паролів для зберігання паролів, які зазвичай неможливо запам'ятати, не записуючи їх).

  2. Завжди хеш втраченого коду пароля / токену в базі даних. НАЗАД, цей код є ще одним прикладом еквівалентного пароля, тому він повинен бути хешуванням у випадку, якщо зловмисник отримав руки на вашу базу даних. Коли запитується код втраченого пароля, надішліть код звичайного тексту на адресу електронної пошти користувача, потім його хеш, збережіть хеш у вашій базі даних, - і викиньте оригінал. Так само, як пароль або постійний токен входу.

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

Частина V: перевірка сили пароля

По-перше, ви хочете прочитати цю маленьку статтю для перевірки дійсності: 500 найпоширеніших паролів

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

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

Щоб запобігти цьому, потрібно розрахувати ентропію пароля, а потім застосувати порогове значення. Національний інститут стандартів і технологій (NIST) Спеціальна публікація 800-63 має набір дуже хороших пропозицій. Це, коли поєднується з аналізом розкладу словника та клавіатури (наприклад, 'qwertyuiop' - це поганий пароль), може відхилити 99% всіх погано обраних паролів на рівні 18 біт ентропії. Просто розрахунок сили пароля і показник візуальної сили користувачеві добре, але недостатньо. Якщо це не буде застосовано, багато користувачів, швидше за все, ігнорують його.

А для освіжаючого прийняти зручність у використанні паролів з високою ентропією, Рендалл Мунро Сила пароля xkcd настійно рекомендується.

ЧАСТИНА VI: Багато чого іншого - Або: Запобігання спробам швидкого спрощення входу

По-перше, подивіться на номери: Швидкість відновлення пароля - скільки часу займе ваш пароль

Якщо у вас немає часу, щоб переглянути таблиці в цьому посиланні, ось список їх:

  1. Це займає практично немає часу щоб зламати слабкий пароль, навіть якщо ви розбиваєте його з абакою

  2. Це займає практично немає часу щоб зламати буквено-цифровий 9-значний пароль, якщо це є регістр нечутливий

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

  4. Тим не менш, займе надто багато часу, щоб зламати навіть 6-значний пароль, якщо ви були обмежені однією спробою в секунду!

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

Взагалі кажучи, у вас є три варіанти, які ефективні проти атак грубої сили (і словникові атаки, але оскільки ви вже використовуєте сильну політику паролів, вони не повинні бути проблемою):

  • Подаруй а CAPTCHA після N невдалих спроб (дратує, як пекло, і часто неефективний - але я повторюю себе тут)

  • Блокування облікових записів і вимагає перевірки електронної пошти після N невдалих спроб (це є DoS атака очікується)

  • І, нарешті, Логічне дроселювання: тобто встановлення часу затримки між спробами після невдалих спроб N (так, атаки DoS все ще можливі, але, принаймні, вони є набагато менш ймовірними та набагато складнішими для зняття).

Краща практика # 1: Невелика затримка, яка збільшується з кількістю невдалих спроб, наприклад:

  • 1 невдала спроба = без затримки
  • 2 невдалих спроб = затримка 2 сек
  • 3 невдалих спроб = затримка 4 сек
  • 4 невдалих спроб = затримка 8 сек
  • 5 невдалих спроб: затримка 16 сек
  • тощо.

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

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

Краща практика № 2: Затримка середньої довжини, яка набуває чинності після спроб невдалого спроби, наприклад:

  • 1-4 невдалих спроб = без затримки
  • 5 невдалих спроб = затримка 15-30 хвилин

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

Краща практика №3: Поєднання двох підходів - або фіксована, і коротка затримка часу, яка набуває чинності після спроб невдалого спроби, наприклад:

  • 1-4 невдалих спроб = без затримки
  • 5 + невдалих спроб = затримка 20 сек

Або зростаюча затримка з фіксованою верхньою межею, наприклад:

  • 1 невдала спроба = затримка 5 сек
  • 2 невдалих спроб = 15 секунд затримки
  • 3+ невдалих спроб = затримка 45 сек

Ця остаточна схема була взята з пропозицій найкращої практики OWASP (посилання 1 з списку "ПОВИННИЙ"), і вона повинна розглядатися як найкраща практика, навіть якщо вона, здається, є обмежувальною.

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

DoS, що нападає на цю остаточну схему входу в систему, буде такою дуже непрактично. І, як остаточний дотик, завжди дозволяйте пройти через стійкі (файли cookie) логіни (і / або форму реєстрації, підтвердженої CAPTCHA), так що законним користувачам навіть не буде затримано поки атака триває. Таким чином, дуже непрактичний DoS атака стає надзвичайно непрактична атака

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

ЧАСТИНА VII: Розподілені атаки грубої сили

Більше просунуті атакуючі, на відміну від них, намагатимуться уникнути втручання в логін шляхом "розповсюдження своєї діяльності":

  • Розподіл спроб на ботнеті запобігти позначенню IP-адреси

  • Замість того, щоб вибирати одного користувача та намагатися 50 000 найпоширеніших паролів (які вони не можуть, через наше дротяння), вони виберуть найпоширеніший пароль і спробують його скоріше замість 50 000 користувачів. Таким чином, вони не тільки обіймають такі заходи, як CAPTCHA та вхідні дротилінг, але їх шанси на успіх також зростають, оскільки найпоширеніший пароль № 1 є набагато більш імовірним, ніж номер 49.995.

  • Розмістіть запити на вхід для кожної облікового запису користувача, скажімо, за 30 секунд, щоб проникнути під радар

Тут найкраща практика ведення журналу кількості невдалих імен, загальносистемних, а також використання середнього значення частоти поганого входу вашого сайту в якості основи для верхньої межі, яку ви накладете на всіх користувачів.

Занадто абстрактний? Дозвольте мені перефразировать:

Скажімо, ваш сайт протягом останніх 3 місяців мав в середньому 120 непотрібних журналів на день. Використовуючи це (середнє значення), ваша система може встановити глобальну межу в 3 рази, тобто. 360 невдалих спроб протягом 24 годин. Тоді, якщо загальна кількість невдалих спроб у всіх облікових записах перевищуватиме це число протягом одного дня (а точніше, відстежувати швидкість прискорення та спрацьовування за розрахунковим порогом), він активує загальний масштаб реєстрації входу - це означає короткі затримки для ВСЕХ користувачів (все-таки, за винятком логінів файлів cookie та / або резервних копій CAPTCHA логінів).

Я також розмістив запитання з більше деталей та дуже гарна дискусія про те, як уникнути складних пітфалів в боротьбі з розподіленими атаками грубої сили

Частина VIII: Двофакторні автентифікатори та постачальники аутентифікації

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

Аутентифікація може бути повністю делегована службі єдиного входу, де інший провайдер керує збиранням облікових даних. Це підштовхує проблему до довіреної третьої сторони. Google і Twitter також надають послуги SSO на базі стандартів, тоді як Facebook надає подібне фірмове рішення.

ДОВІДКОВІ ПОСИЛАННЯ Про веб-аутентифікацію

  1. OWASP Посібник для автентифікації / Cheat Sheet для автентифікації OWASP
  2. Дози та недопущення аутентифікації клієнтів в Інтернеті (дуже читабельний науковий документ MIT)
  3. Вікіпедія: HTTP файли cookie
  4. Питання особистого знання для автентифікації за замовчуванням: питання безпеки в епоху Facebook (дуже читабельний дослідницький документ Берклі)

3498



Що ж, я не зовсім згоджуюсь з частиною Captcha, так що Captchas дратує, і вони можуть бути порушені (крім recaptcha, але це ледве вирішується людьми!), Але це точно так само, як кажуть, не використовуйте спам-фільтр, тому що він має менш ніж 0,1% помилкових негативів .. саме цей сайт використовує Captchas, вони не є ідеальними, але вони скорочують значну кількість спаму, і їх немає просто хорошої альтернативи - Waleed Eissa
@Jeff: Мені дуже шкода, що у вас є проблеми з моєю відповіддю. Я не знав, що про цю відповідь була дискусія щодо Meta, я б із задоволенням відредагував це, якщо б ви запитали мене. І видаливши мої публікації, видалили 1200 репутації з мого облікового запису, що завдає шкоди :( - Jens Roland
"Після відправки токенів автентифікації система потребує способу пам'ятати, що ви були автентифіковані - цей факт слід зберігати лише в серверних даних в даних сесії. Файл cookie може використовуватися для посилання на дані сеансу". Не зовсім. Ви можете (і треба, для серверів без державних!) Використовувати криптографічно підписаний cookie. Це неможливо підробити, не прив'язує ресурси сервера і не потребує липких сеансів або інших шпіонів. - Martin Probst
"настільний ПК може шукати FULL KEYSPACE до 7 символів менше, ніж за 90 днів". Машина з недавнім графічним процесором може шукати повну 7-символьну клавіатуру менш ніж за 1 день. Верхня частина лінії GPU може управляти 1 мільярдом хешей в секунду. golubev.com/hashgpu.htm  Це призводить до деяких висновків щодо зберігання паролів, які безпосередньо не розглядаються. - Frank Farmer
Я здивований захист CSRF не згадується ... - Flukey


Остаточна стаття

Відправка повноважень

Єдиним практичним способом надійного надсилання сертифікатів на 100% є використання SSL. Використання JavaScript для хешу пароля не безпечно. Поширені помилки для хешування паролем на стороні клієнта:

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

Існує ще один безпечний метод, який називається SRP, але це запатентовано (хоча це і є вільно ліцензований), і існує декілька хороших реалізацій.

Зберігання паролів

Ніколи не зберігайте паролі як відкритий текст у базі даних. Навіть якщо ви не дбаєте про безпеку власного сайту. Припустимо, що деякі з ваших користувачів повторно використовувати пароль свого онлайн-рахунку. Таким чином, зберігайте хеш-пароль і викиньте оригінал. І переконайтеся, що пароль не відображається в журналах доступу або журналах програм. OWASP Рекомендується використовувати Argon2 як ваш перший вибір для нових додатків. Якщо це недоступне, замість нього слід використовувати PBKDF2 чи скрипт. І, нарешті, якщо жоден з перелічених вище варіантів не доступний, скористайтеся bcrypt.

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

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

Питання безпеки

Питання безпеки є небезпечними - не використовуйте їх. Чому? Що завгодно для безпеки, пароль стає кращим. Читайте ЧАСТИНА III: Використання секретних питань в @ Йенс Роланд відповісти тут у цій вікі.

Сесійні файли cookie

Після входу користувача сервер надсилає користувачеві файл cookie сеансу. Сервер може отримати ім'я користувача чи ідентифікатор файлу cookie, але ніхто інший не може генерувати такий файл cookie (TODO explain mechanisms).

Файли cookie можуть бути викрадені: вони настільки ж безпечні, як решта машини клієнта та інші комунікації. Їх можна читати з диска, нюхати в мережевому трафіку, підняти через міжсистемну атаку на скрипти, зафіксована від отруєної DNS, і клієнт надсилає їх куки на неправильні сервери. Не надсилайте постійні файли cookie. Cookie повинні закінчуватися в кінці сеансу клієнта (браузер закривається або залишає ваш домен).

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

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

Список зовнішніх ресурсів


387



З огляду на недавню вразливість MITM навколо підписаних сертифікатів SSL (blog.startcom.org/?p=145), то, мабуть, краще рішення - комбінація SSL та певна автентифікація відповідей на виклик (існують альтернативи SRP). - Kevin Loney
багато цього матеріалу є ситуативним. Я не схильний використовувати сеансові файли cookie взагалі. Файли cookie, які отримують викрадення, майже завжди є помилками серверів. людина в середині / пакет, що нюхає, аж ніяк не загальний - Shawn
BCrypt Nuget package: nuget.org/List/Packages/BCrypt - Fabian Vilers
Примітка 1 щодо цієї відповіді: це проект, який слід редагувати як вікі. Якщо ви можете відредагувати це, ви можете. - Peter Mortensen


По-перше, сильне застереження, що ця відповідь не найкраще підходить для цього конкретного питання. Напевно, це не найкраща відповідь!

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

Я підсуму так саме:

  1. Mozilla неприбуткова організація цінності що добре узгоджується з пошуком гарних рішень цієї проблеми.
  2. Сьогодні реальність полягає в тому, що більшість веб-сайтів використовують автентифікацію на основі форм
  3. Аутентифікація на основі форми має великий недолік, що є підвищеним ризиком фішинг. Користувачам пропонується ввести конфіденційну інформацію в область, керовану віддаленим об'єктом, а не територією, контрольованою їх User Agent (браузер).
  4. Оскільки браузери неявно довіряють (вся ідея користувача агента полягає в тому, щоб діяти від імені Користувача), вони можуть допомогти покращити цю ситуацію.
  5. Основною силою, що зупиняє прогрес тут, є тупик розгортання. Рішення повинні бути розбиті на етапи, які надають певну додаткову користь самостійно.
  6. Найпростішим децентралізованим методом вираження ідентичності, який вбудований в інфраструктуру Інтернету, є доменне ім'я.
  7. Як другий рівень вираження ідентичності, кожен домен керує власним набором облікових записів.
  8. Форма "рахунок@домен "короткий і підтримується широким діапазоном протоколів та схем URI. Такий ідентифікатор, звичайно, найбільш загально визнається як електронна адреса.
  9. Постачальники електронної пошти вже є де-факто основними постачальниками ідентифікаторів в Інтернеті. Поточні потоки скидання паролів зазвичай дозволяють контролювати обліковий запис, якщо ви можете довести, що ви керуєте пов'язаною електронною адресою цієї облікового запису.
  10. Протокол підтвердженого електронного листа був запропонований для забезпечення безпечного методу, заснованого на криптографії відкритого ключа, для спрощення процесу підтвердження домену B, що у вас є обліковий запис у домені A.
  11. Для веб-переглядачів, які не підтримують протокол підтвердженого електронного листа (наразі всі вони), Mozilla забезпечує шифрування, яке реалізує протокол у коді JavaScript на стороні клієнта.
  12. Для служб електронної пошти, які не підтримують протокол підтвердженого електронного листа, протокол дозволяє третім сторонам діяти як довірений посередник, заявляючи, що вони підтвердили право власності на обліковий запис користувача. Небажано мати велику кількість таких третіх осіб; ця можливість призначена лише для того, щоб дозволити шлях оновлення, і набагато краще, щоб служби електронної пошти самі надавали ці твердження.
  13. Mozilla пропонує свої послуги, щоб виступати в якості такої довіреної третьої сторони. Постачальники послуг (тобто перевіряючі сторони), що впроваджують протокол перевірки електронної пошти, можуть довіряти твердженням Mozilla чи ні. Служба Mozilla перевіряє права власності на обліковий запис користувачів, використовуючи звичайні способи надсилання електронного листа з посиланням на підтвердження.
  14. Сервіс-провайдери, звичайно, можуть запропонувати цей протокол як варіант, на додаток до будь-яких інших методів аутентифікації, які вони можуть запропонувати.
  15. Великою перевагою користувацького інтерфейсу, яку шукають тут, є "select selector". Коли користувач відвідує сайт та обирає автентифікацію, у веб-переглядачі відображається вибір адреси електронної пошти ("персональний", "робота", "політична активність" тощо), який вони можуть використовувати для ідентифікації себе на сайті.
  16. Ще одна велика перевага для користувальницького інтерфейсу, яку шукають, - це частина цих зусиль допомагаючи браузеру більше дізнатися про сеанс користувача - хто вони ввійшли в поточний час, перш за все, тому він може відображати його в браузері chrome.
  17. Через розподілену природу цієї системи він уникає замикання на основні сайти, такі як Facebook, Twitter, Google тощо. Будь-яка особа може володіти своїм власним доменом і тому діяти як власний постачальник ідентифікаційних даних.

Це не суто "автентифікація на основі форм для веб-сайтів". Але це спроба перейти від поточної норми автентифікації на основі форм до чогось більш безпечного: аутентифікація, підтримувана браузером.


146



BrowserID-посилання мертві - Mehdi
Схоже, що цей проект був пробитий ... див en.wikipedia.org/wiki/Mozilla_Persona - Jeff Olson


Я просто подумав, що поділився цим рішенням, який, на мою думку, працював просто чудово.

Я називаю це Манекен Філд (хоча я і цього не винайшов, тому не кредитуйте мене).

Коротше кажучи: ви просто повинні вставити це в свій <form> і перевірте, щоб воно було порожнім при перевірці:

<input type="text" name="email" style="display:none" />

Хитрість полягає в тому, щоб обдурити бота, думаючи, що він повинен вставити дані в потрібне поле, тому я назвав вхід "email". Якщо у вас вже є поле, яке називається електронною поштою, яку ви використовуєте, слід намагатись назвати поле "Манекен" чимось іншим, як "компанія", "телефон" або "emailaddress". Просто знайдіть те, що ви знаєте, що вам не потрібне, і що звучить як щось, що, як правило, було б логічно, щоб заповнити веб-форму. Тепер приховати input поле використовуючи CSS або JavaScript / jQuery - все, що підходить вам найкраще - просто ні встановити вхід type до hidden або бот не потрапить на це.

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

Приклад:

У випадку з людиною: Користувач не побачить поле "Малюнок" (у моєму випадку має назву "email") і не намагатиметься його заповнити. Тому значення поля манекена повинно бути порожнім, коли форма була відправлена.

У випадку з ботом: Бот побачить поле, тип якого text і ім'я email (або будь-що, що його назвали), і логічно намагатиметься заповнити його відповідними даними. Вам не подобається, якщо ви впорядкували форму введення з деякими привабливими CSS, веб-розробники роблять це постійно. Якою б цінністю не було в манекенному полі, нам все одно, коли це більше, ніж 0 персонажів.

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

Я вважаю, що це також може бути використано просто з формою логіну / автентифікації.

УВАГА: Звичайно, цей метод не є доказом 100% дурня. Боти можна запрограмувати, щоб ігнорувати поля введення стилем display:none звернувся до нього. Ви також повинні думати про людей, які використовують певну форму автоматичного завершення (як і більшість браузерів мають вбудований!), Щоб автоматично заповнити всі поля форми для них. Вони можуть так само підібрати манекенне поле.

Ви також можете трохи змінювати це, залишаючи видиме манекенне поле, але поза межами екрану, але це повністю залежить від вас.

Будь креативним!


120



Це корисний антиспамовий трюк, але я б рекомендував використовувати ім'я поля, відмінне від "email", або ви можете побачити, що автозаповнення веб-переглядача заповнюється ним, випадково блокуючи справжніх користувачів вашого сайту. - Nico Burns
У мене також є декілька з них visibility:hidden а також position:absolute;top:-9000px Ви також можете це зробити text-indent а також z-index на деяких з цих елементів і помістити їх у стиснуті імена файлів CSS з незрозумілими іменами - боти можуть виявляти 1display: none`, і вони зараз перевіряють набір комбінацій - я насправді використовую ці методи, і вони старі трюки торгівлі . +1 - TheBlackBenzKid
Що трапляється, коли користувач з порушенням зору використовує програму зчитування екрана для навігації по формі? - gtcharlie
Ця техніка має назву: honeypot en.wikipedia.org/wiki/Honeypot_(комп'ютер) - pixeline
Немає необхідності в стильному стилі. Просто додайте клас до поля (можливо, використовуйте дивне слово, яке ніколи не може означати щось для бота), і приховати його через файл CSS сайту. Люблю: <input type="text" name="email" class="cucaracha"> і у вашому CSS: .cucaracha { display:none; }. - Ricardo Zea


Я не думаю, що наведена вище відповідь є "неправильною", але є великі області аутентифікації, які не стосуються (або, скоріше, акцент робиться на "як реалізувати сеансів cookie", а не на "які варіанти доступні і якими є торгівля офф ".

Мої запропоновані зміни / відповіді

  • Проблема більше полягає в налаштуванні облікового запису, ніж у перевірці пароля.
  • Використання двофакторної аутентифікації набагато безпечніше, ніж більш розумне засіб шифрування паролем
  • НЕ намагайтеся впровадити власну реєстраційну форму або збереження паролів бази даних, якщо тільки дані, що зберігаються, не мають цінності при створенні облікових записів і самогенерованих (тобто стилі Web 2.0, як Facebook, Flickrі т. д.)

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

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

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

Так ...

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

Це дуже важка частина. The тільки гідне рішення - це мережа довіри. Наприклад, ви приєднуєтеся до лікарні як лікар. Ви створюєте веб-сторінку, розташовану де-небудь із фотографією, номером свого паспорта та відкритим ключем, і хешуватимете їх усіма закритим ключем. Потім ви відвідаєте лікарню, і системний адміністратор переглядає ваш паспорт, бачить, чи збігається з вашою фотографією, а потім хешиме хеш веб-сторінки / фото з літнім ключем лікарні. Відтепер ми можемо безпечно обмінювати ключі та жетони. Як може хтось, хто довіряє лікарні (є таємний соус BTW). Системний адміністратор також може надати вам RSA ключ або інша двофакторна аутентифікація.

Але це є багато неприємностей, і не дуже веб 2.0. Однак це єдиний безпечний спосіб створити нові облікові записи, які мають доступ до цінної інформації, яка не створюється самостійно.

  1. Kerberos і SPNEGO - єдині знаки на механізмах з надійною третьою стороною - в основному користувач перевіряє надійний третій стороні. (NB це ні в якому разі не можна довіряти OAuth)

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

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

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


71



Важко сказати, на яку відповідь ви говорите: "Я не думаю, що відповідь вище" неправильна " - Davorak


Під час хешування не використовуйте швидкі хеш-алгоритми, такі як MD5 (існують багато реалізацій обладнання). Використовуйте щось на зразок SHA-512. Для паролів кращі хеші повільніше.

Чим швидше ви можете створювати хеші, тим швидше може працювати будь-яка перевірка грубої сили. Тому повільніші хеші призведуть до повільного примусу. Повільний хеш-алгоритм змусить грубу примусувати довші паролі (8 цифр +)


48



SHA-512 також швидко, тому вам потрібні тисячі ітерацій. - Seun Osewa
"Не використовуйте швидкі алгоритми хешу ... більш повільні хеші краще" - Пояснення? Документація? - one.beat.consumer
Пояснення: чим швидше ви можете створювати хеші, тим швидше може працювати будь-яка перевірка грубої сили. Тому повільніші хеші призведуть до повільного примусу. Повільний хеш-алгоритм змусить грубу примусувати довші паролі (8 цифр +) - NickG
Більше схоже на щось на кшталт bcrypt, який призначений для хешування повільно. - Fabian Nicollier


Хороша стаття про реальну оцінку сили пароля:

Tech Blog "Dropbox" »Архів блогу» zxcvbn: реалістична оцінка сили пароля


46





Моє улюблене правило щодо систем аутентифікації: використовуйте паролі, а не паролі. Легко пам'ятати, важко тріснути. Більше інформації: Кодування жахів: паролі проти паролів


41