Нещодавно у мене з'явився час знову подумати над тим, як повинна працювати функція безпечного скидання пароля, спочатку коли я вбудовував цю функціональність , а потім колись допомагав зробити щось подібне іншій людині. У другому випадку я хотів надати йому посилання на канонічний ресурс з усіма подробицями безпечної реалізації функції скидання. Однак проблема в тому, що такого ресурсу не існує, принаймні такого, в якому описується все, що мені здається важливим. Тож я вирішив написати його сам.
Чи бачите, світ забутих паролів насправді досить загадковий. Існує безліч різних, цілком прийнятних точок зору та купа досить небезпечних. Є можливість, що з кожною з них ви багато разів стикалися як кінцевий користувач; тому я спробую скористатися цими прикладами, щоб показати, хто робить все правильно, а хто ні, і на чому потрібно зосередитись для правильної реалізації функції у своєму додатку.
Зберігання паролів: хешування, шифрування та (ох!) простий текст
Ми не можемо обговорювати, що робити із забутими паролями, перш ніж не обговоримо спосіб їх зберігання. У базі даних паролі зберігаються в одному з трьох основних видів:
- Простий текст. Є стовпець із паролем, який зберігається у звичайному текстовому вигляді.
- Зашифрований. Зазвичай за допомогою симетричного шифрування (один ключ використовується і для шифрування і для дешифрування), а зашифровані паролі зберігаються в одному стовпці.
- Хешований. Односторонній процес (пароль можна хешувати, але не можна дехешувати); пароль, хотілося б сподіватися, Супроводжується сіллю, і кожен з них знаходиться у власному стовпці.
Давайте відразу розберемося з найпростішим питанням: ніколи не зберігайте паролі у простому тексті! Ніколи. Одна єдина вразливість до , одна необачно зроблена резервна копія або одна з десятків інших простих помилок - і все, геймовер, всі ваші паролі - тобто, вибачте, паролі всіх ваших клієнтів стануть громадським надбанням. Зрозуміло, це означатиме величезну ймовірність того, що громадським надбанням стануть від усіх їхніх облікових записів інших системах. І це буде вашою провиною.
Шифрування краще, але має слабкі сторони. Проблема шифрування - у дешифруванні; можна взяти ці шифри, що шалено виглядають, і перетворити їх назад у простий текст, а коли це відбудеться, ми повернемося до ситуації з читаними паролями. Як це відбувається? Невелика вада проникає в код, що займається дешифруванням пароля, роблячи його публічно доступним - це один із способів. Доступ до машини, де зберігаються зашифровані дані, отримують зломщики — це другий спосіб. Ще один спосіб знову-таки полягає в тому, що викрадають резервну копію бази даних, і хтось отримує ключ шифрування, які часто зберігаються дуже ненадійно.
І це призводить до хешування. Ідея хешування полягає в тому, що воно виконується в один бік; єдиний спосіб порівняння введеного користувачем пароля з його хешованої версією - хешування введеного та їх порівняння. Щоб запобігти атакам за допомогою інструментів на кшталт «райдужних таблиць», ми за допомогою солі додаємо до процесу випадковість (для повноти картини прочитайте мій про криптографічне зберігання). Зрештою, при правильній реалізації ми можемо з великою впевненістю вважати, що хешовані паролі більше ніколи не стануть простим текстом (про переваги різних алгоритмів хешування я розповім в іншому пості).
Короткий аргумент про хешування та шифрування: єдина причина, через яку вам коли-небудь потрібно зашифрувати, а не хешувати пароль - це коли вам потрібно побачити пароль у простому тексті, а вам цього ніколи не повинно хотітисяпринаймні у ситуації зі стандартним веб-сайтом. Якщо вам це потрібно, то швидше за все ви робите щось не так!
Увага!
Трохи нижче в тексті посту є частина екрана порнографічного веб-сайту AlotPorn. Він акуратно обрізаний, і так немає нічого такого, чого не можна побачити на пляжі, але якщо це все одно може спричинити якісь проблеми, то не прокручуйте сторінку вниз.
Завжди скидайте пароль, ніколи його не нагадуйте
Вас колись просили створити функцію нагадування пароля? Зробіть крок назад і подумайте про це прохання у зворотний бік: навіщо потрібне це «нагадування»? Тому що користувач забув пароль. Що ми насправді хочемо зробити? Допомогти йому знову увійти до системи.
Я розумію, слово «нагадування» використовується (часто) у розмовному сенсі, але насправді ми намагаємося безпечно допомогти користувачеві знову бути онлайн. Оскільки нам потрібна безпека, є дві причини, через які нагадування (тобто відправка користувачеві його пароля) не підходить:
- Електронна пошта – небезпечний канал. Так само, як ми не стали б передавати нічого конфіденційного по HTTP (ми б використовували HTTPS), не варто передавати нічого електронною поштою, тому що її транспортний шар небезпечний. Насправді це набагато гірше, ніж проста передача інформації по незахищеному транспортному протоколу, тому що пошта часто зберігається на накопичувачі, доступна системним адміністраторам, пересилається і поширюється, доступна шкідливому ПЗ, і так далі. Незашифрована пошта – надзвичайно незахищений канал.
- Ви не повинні мати доступ до пароля. Перечитайте попередній розділ про зберігання - у вас повинен бути хеш пароля (з гарною стійкою сіллю), тобто ви не повинні мати можливості витягнути пароль і відправити його поштою.
Дозвольте мені продемонструвати проблему на прикладі : Ось типова сторінка логіна:
Очевидно, перша проблема полягає в тому, що сторінка входу в систему не завантажується по HTTPS, але сайт ще й пропонує відправити пароль («Send Password»). Можливо, це приклад згаданого вище розмовного застосування даного терміну, тому зробимо ще один крок і подивимося, що відбудеться:
Виглядає не набагато краще, на жаль; та електронна пошта підтверджує наявність проблеми:
Це говорить нам про два важливі аспекти usoutdoor.com:
- Сайт не хешує паролі. У кращому випадку, вони шифруються, але цілком імовірно, що вони зберігаються в текстовому вигляді; свідчень протилежного ми не бачимо.
- Сайт відправляє довготривалий пароль (ми можемо повертатися і використовувати його знову і знову) незахищеним каналом.
Розібравшись із цим, нам потрібно перевірити, чи виконується процес скидання безпечним чином. Насамперед для цього потрібно переконатися, чи має запитувач право на виконання скидання. Іншими словами, перед цим нам потрібна перевірка ідентифікації; давайте поглянемо, що відбувається, коли особистість підтверджується без попередньої перевірки того, що запитувач дійсно є власником облікового запису.
Перелік імен користувачів та його вплив на анонімність
Цю проблему краще проілюструвати візуально. Проблема:
Бачите? Зверніть увагу на повідомлення «Те, що не реєструється з цим електронним листом» («Користувач з такою адресою електронної пошти не зареєстрований»). Проблема, очевидно, виникає, якщо подібний сайт підтверджує наявність зареєстрованого з такою адресою електронної пошти користувача. Бінго - ви щойно виявили порно-фетиш вашого чоловіка/начальника/сусіда!
Зрозуміло, порно - досить канонічний приклад важливості конфіденційності, проте небезпека зіставлення особистості з певним веб-сайтом набагато ширше, ніж описана вище потенційно незручна ситуація. Одна з небезпек – соціальний інжиніринг; якщо нападник зможе зіставити людину з сервісом, то в неї з'явиться інформація, яку вона здатна почати використовувати. Наприклад, він може зв'язатися з людиною, видаючи себе за представника веб-сайту, і запросити додаткову інформацію, намагаючись зробити .
Подібні практики також викликають небезпеку «перерахування імен користувачів», при якому можна перевірити існування на веб-сайті цілої колекції імен користувачів або адрес пошти простими груповими запитами та вивченням відповідей на них. Ви маєте список адрес електронної пошти всіх співробітників і кілька хвилин на написання скрипта? Тоді ви бачите, у чому проблема!
Яка ж альтернатива? Насправді вона досить проста, і чудово реалізована на :
Тут Entropay зовсім нічого не розкриває про існування в системі адреси електронної пошти тому, хто не володіє цією адресою. Якщо ви володієте цією адресою і вона не існує в системі, то ви отримаєте подібний електронний лист:
Зрозуміло, можливі прийнятні ситуації, у яких хтось думає, що зареєструвався на веб-сайті але це не так, або зробив це з іншої адреси пошти. Наведений вище приклад успішно справляється з обома ситуаціями. Очевидно, якщо адреса збіглася, то ви отримаєте лист, що спрощує скидання пароля.
Тонкість обраного Entropay рішення в тому, що перевірка ідентифікації виконується за електронній пошті до будь-якої онлайн-перевірки. Деякі сайти запитують у користувачів відповідь на секретне запитання (докладніше про це нижче) до того, як зможе розпочатися скидання; однак, проблема цього в тому, що потрібно відповісти на питання, надавши при цьому будь-який вид ідентифікації (пошту або ім'я користувача), через що майже неможливо відповісти інтуїтивно зрозуміло, не розкриваючи існування облікового запису анонімного користувача.
За такого підходу є невелике зниження юзабіліті, тому що у разі спроби скидання неіснуючого облікового запису немає миттєвого зворотного зв'язку. Зрозуміло, у цьому є весь сенс відправки електронного листа, але з погляду справжнього кінцевого користувача, якщо він запровадить неправильну адресу, то вперше дізнається про це тільки при отриманні листа. Подібне може спричинити певну напруженість з його боку, але це невелика плата за такий рідкісний процес.
Ще одна примітка, що трохи відхиляється від теми: функції допомоги входу в систему, що розкривають правильність імені користувача або адреси електронної пошти, мають ту саму проблему. Завжди відповідайте користувачеві повідомленням "Неправильне поєднання імені користувача та пароля", а не підтверджуйте явним чином існування ідентифікаційної інформації (наприклад, "ім'я користувача правильне, але пароль введено неправильно").
Надсилання пароля скидання проти відправки URL скидання
Наступна концепція, яку нам потрібно обговорити, пов'язана із способом скидання пароля. Існує два популярні рішення:
- Генерація нового пароля на сервері та його відправлення електронною поштою
- Надсилання електронного листа з унікальним URL, що спрощує процес скидання
Незважаючи на , перший пункт ніколи використовувати не варто. Його проблема в тому, що це означає наявність пароля, що зберігається, До якого можна повернутися і знову використовувати в будь-який момент; він був переданий незахищеним каналом і залишається у ваших вхідних. Є ймовірність, що вхідні синхронізуються з мобільними пристроями та клієнтом електронної пошти, плюс вони можуть зберігатись онлайн у веб-сервісі електронної пошти дуже довгий час. Сенс у тому, що поштову скриньку не можна розглядати як надійний засіб для довготривалого зберігання.
Але, крім цього, у першого пункту існує ще одна серйозна проблема — він максимально спрощує блокування облікового запису зі злим наміром. Якщо я знаю адресу пошти того, хто володіє обліковим записом на веб-сайті, я можу заблокувати його в будь-який момент часу, просто скинувши його пароль; це атака типу «відмова в обслуговуванні», викладена на блюдечку з блакитною облямівкою! Саме тому скидання має виконуватися тільки після успішної перевірки у запитуючого права на нього.
Коли ми говоримо про URL скидання, то маємо на увазі адресу веб-сайту, який є унікальним для цього конкретного випадку процесу скидання. Зрозуміло, він повинен бути випадковим, його не повинно легко розгадати і він не повинен містити ніяких зовнішніх посилань на обліковий запис, що спрощує скидання. Наприклад, URL скидання не повинно бути просто шляхом на кшталт «Reset/?username=JohnSmith».
Ми хочемо створити унікальний токен, який можна буде відправити поштою як URL скидання, а потім звірити його із записом на сервері з обліковим записом користувача, підтвердивши таким чином, що власник облікового запису і справді та сама людина, яка намагається скинути пароль . Наприклад, токен може мати вигляд "3ce7854015cd38c862cb9e14a1ae552b" і зберігатися в таблиці разом з ID користувача, що виконує скидання, і часом генерації токена (докладніше про це трохи нижче). При надсиланні листа він містить URL на кшталт "Reset/?id=3ce7854015cd38c862cb9e14a1ae552b", а коли користувач завантажує його, сторінка запитує існування токена, після чого підтверджує інформацію користувача і дозволяє змінити пароль.
Зрозуміло, оскільки описаний вище процес (будемо сподіватися) дозволяє користувачеві створити новий пароль, потрібно гарантувати завантаження URL за HTTPS. Ні, , цей URL з токеном повинні використовувати безпеку транспортного шару, щоб на форму введення нового пароля неможливо було здійснити атаку і створений користувачем пароль передавався по захищеному з'єднанню.
Також для URL скидання потрібно додати ліміт часу токена, щоб процес скидання можна було виконати протягом певного інтервалу, скажімо, в межах години. Це гарантує, що вікно часу скидання буде мінімальним, щоб цей URL скидання міг діяти тільки в рамках цього дуже маленького вікна. Зрозуміло, що нападник може знову розпочати процес скидання, але йому знадобиться отримати ще один унікальний URL-адрес скидання.
Зрештою, нам потрібно забезпечити одноразовість цього процесу. Після завершення процесу скидання токен необхідно видалити, щоб URL скидання більше не було працюючим. Попередній пункт потрібен для того, щоб у нападника було дуже мале вікно, протягом якого він може маніпулювати URL-адресу скидання. Плюс, звичайно, після успішного завершення скидання токен більше не потрібний.
Деякі з цих кроків можуть здатися надмірними, але вони зовсім не заважають юзабіліті та насправді підвищують безпеку, хоч і в ситуаціях, які, ми сподіваємось, будуть рідкісними. У 99% випадків користувач буде задіяти скидання протягом дуже короткого проміжку часу і не скидатиме пароль знову в найближчому майбутньому.
Роль CAPTCHA
О, CAPTCHA, засіб захисту, який ми всі так любимо ненавидіти! Насправді, CAPTCHA засіб не стільки захисту, скільки ідентифікації – людина ви чи робот (або автоматизований скрипт). Її сенс у тому, щоб уникнути автоматичного відправлення форм, яке, зрозуміло, може застосовуватися як спроба злому захисту. У контексті скидання паролів CAPTCHA означає, що функцію скидання неможливо буде зламати грубим перебором, щоб або потім спамити користувачеві, або спробувати визначити існування облікових записів (що, зрозуміло, буде неможливо, якщо ви наслідували поради з розділу про перевірку ідентифікації).
Зрозуміло, сама собою CAPTCHA неідеальна; існує безліч прецедентів її програмного «зламування» та досягнення достатніх показників успіху (60-70%). Крім того, існує рішення, показане в моєму посту про , при якому можна платити людям частки центу для вирішення кожної CAPTCHA та отримання показника успіху у 94%. Тобто вона вразлива, проте (трохи) підвищує вхідний бар'єр.
Давайте подивимося на приклад PayPal:
В даному випадку процес скидання просто не може початися до рішення CAPTCHA, тому теоретично автоматизувати процес неможливо. Теоретично.
Однак для більшості веб-застосунків це буде перебором і абсолютно точно є зниження юзабіліті — люди просто не люблять CAPTCHA! Крім того, CAPTCHA — це така річ, до якої можна буде легко повернутися. Якщо сервіс починає нападати (тут знадобиться логінг, але докладніше про це пізніше), то додати CAPTCHA легше нікуди.
Секретні питання та відповіді
При всіх розглянутих нами способах ми мали можливість скинути пароль, лише маючи доступ до облікового запису електронної пошти. Я говорю «лише», але, зрозуміло, незаконне отримання доступу до чужого облікового запису пошти має бути складним процесом. Однак .
Насправді, наведене вище посилання про злом облікового запису Сари Пейлін на Yahoo! служить двом цілям; по-перше, вона ілюструє, наскільки легко можна зламувати (деякі) поштові облікові записи, по-друге, вона показує, як можна зі злим наміром використовувати погані секретні питання. Але ми повернемося до цього згодом.
Проблема зі скиданням паролів із стовідсотковою залежністю від електронної пошти полягає в тому, що цілісність облікового запису сайту, пароль якого ви намагаєтеся скинути, стає стовідсотково залежним від цілісності облікового запису електронної пошти. Будь-хто, хто має доступ до вашої електронної пошти, має доступ до будь-якого облікового запису, який можна скинути простим отриманням електронного листа. Для таких облікових записів електронна пошта є «ключом від усіх дверей» вашого життя онлайн.
Один із способів зниження цього ризику – реалізація патерну секретного питання та відповіді. Без сумніву, ви вже бачили їх: вибираєте питання, на яке тільки ви повинні знати відповідь, після чого при скиданні пароля вам її задають. Це додає впевненості в тому, що людина, яка намагається виконати скидання і справді є власником облікового запису.
Повернемося до Сарри Пейлін: помилка була в тому, що відповіді на її секретне питання/питання легко можна було знайти. Зокрема, коли ти така значуща громадська постать, інформація про дівоче прізвище матері, історію навчання або про те, де хтось міг жити в минулому, не така вже й секретна. Насправді, більшу її частину можна знайти практично будь-яким. Так і сталося із Сарою:
Хакер Девід Кернелл отримав доступ до облікового запису Пейлін, знайшовши подробиці її біографії, такі як її вуз і дату народження, а потім використавши функцію відновлення забутих паролів до облікових записів Yahoo!.
Насамперед це помилка проектування з боку Yahoo! — вказавши такі прості питання, компанія, по суті, саботувала цінність секретного питання, а отже, і захист своєї системи. Зрозуміло, скидання паролів до облікового запису електронної пошти завжди складніше, адже ви не можете підтвердити її володіння, відправивши власнику електронний лист (не маючи другої адреси), але, на щастя, сьогодні для створення такої системи не так багато способів застосування.
Повернімося до секретних питань - існує варіант надати користувачеві можливість створення власних питань. Проблема в тому, що в результаті виходитимуть жахливо очевидні питання:
Який колір неба?
Питання, що ставлять людей у незручне становище, коли для ідентифікації секретне питання використовує людина (наприклад, у кол-центрі):
З ким я переспав на Різдво?
Або відверто дурні питання:
Як пишеться "пароль"?
Коли справа стосується секретних питань, користувачів потрібно врятувати від себе! Іншими словами, секретне питання має визначати сам сайт, а ще краще, ставити серію секретних питань, із яких може обирати користувач. І не просто вибирати один; в ідеалі користувач повинен вибрати два або більше секретних питань у момент реєстрації облікового запису, які потім використовуватимуться як другий канал ідентифікації. Наявність кількох питань підвищує ступінь впевненості в процесі перевірки, а також дає можливість додавання випадковості (не завжди показувати однакове питання) плюс забезпечує трохи надмірності на випадок, якщо справжній користувач забув пароль.
Яким же має бути хороше секретне питання? На це впливає кілька факторів:
- Він повинен бути коротким — питання має бути чітким та недвозначним.
- Відповідь має бути конкретним — нам не потрібне питання, на яке одна людина може відповісти по-різному
- Можливі відповіді мають бути різноманітними — питання про чиїсь улюблені кольори дає дуже мале підмножина можливих відповідей
- Пошук відповіді має бути складним - якщо відповідь з легкістю може знайти будь (Згадаймо про людей, які займають високе становище), то він поганий
- Відповідь має бути постійним у часі — якщо питати чийсь улюблений фільм, то через рік відповідь може бути іншою.
Як це буває, існує веб-сайт, присвячений добрим питанням, який називається . Частина питань здається цілком непоганою, інші не проходять частину описаних вище тестів, особливо перевірку простоти пошуку.
Дозвольте мені продемонструвати, як секретні питання реалізовані в PayPal і, зокрема, які зусилля сайт докладає для ідентифікації. Вище ми бачили сторінку початку процесу (з CAPTCHA), а тут ми покажемо, що відбувається після того, як ви вводите адресу пошти та вирішуєте CAPTCHA:
В результаті користувач отримує такий лист:
Поки що все цілком звичайно, але ось що ховається за цим URL скидання:
Отже, у справу входять секретні питання. Насправді, PayPal також дозволяє скинути пароль, підтвердивши номер кредитної картки, тому існує додатковий канал, до якого немає доступу безліч сайтів. Я просто не можу змінити пароль, не відповівши на обидва секретні питання (або не знаючи номер картки). Навіть якщо хтось захопить мою електронну пошту, він не зможе скинути пароль PayPal, якщо не знає про мене трохи більше особистої інформації. Якої інформації? Ось варіанти секретних питань, які пропонує PayPal:
Питання про школу і лікарні може бути трохи сумнівним з погляду простоти пошуку, але інші не такі погані. Однак для підвищення безпеки PayPal вимагає додаткової ідентифікації для зміни відповідей на секретні питання:
PayPal - досить утопічний приклад безпечного скидання пароля: він реалізує CAPTCHA для зниження небезпеки грубого перебору, вимагає два секретних питання, а потім вимагає ще один вид зовсім іншої ідентифікації тільки для зміни відповідей - і це після того, як користувач уже виконав вхід. Зрозуміло саме цього ми і чекали б від PayPal; це фінансова організація, яка з великими сумами грошей. Це не означає, що кожне скидання пароля має дотримуватися цих етапів — здебільшого це перебір — проте це добрий приклад для випадків, коли безпека — серйозний бізнес.
Зручність системи секретних питань у цьому, що й не реалізували її одночасно, її можна додати пізніше, якщо цього вимагає рівень захисту ресурсу. Хорошим прикладом цього служить Apple, яка тільки недавно реалізувала цей механізм [стаття написана у 2012 році]. Почавши одного разу оновлювати програму на iPad, я побачив наступний запит:
Потім я побачив екран, на якому можна було вибрати кілька пар секретних питань та відповідей, а також рятувальна адреса електронної пошти:
Що стосується PayPal, то питання обрано заздалегідь і деякі з них насправді досить непогані:
Кожна з трьох пар запитань і відповідей представляє окреме безліч можливих питань, тому є достатньо способів конфігурування облікового запису.
Ще одним аспектом, який слід розглянути щодо відповіді на секретне питання, є зберігання. Знаходження в ДБ простого тексту становить майже ті ж загрози, що й у разі пароля, а саме — розкриття бази даних миттєво розкриває значення і наражає на ризик не тільки додаток, але й потенційно зовсім інші додатки, які використовують ті ж секретні питання (це знову ). Одним із варіантів є безпечне хешування (стійкий алгоритм і криптографічно випадкова сіль), проте на відміну від більшості випадків зберігання паролів, тут може бути поважною причиною видимості відповіді як простого тексту. Типовим сценарієм є перевірка особи живим оператором по телефону. Зрозуміло, в цьому випадку хешування теж застосовується (оператор може просто ввести названу клієнтом відповідь), але в найгіршому випадку секретна відповідь повинна бути на якомусь рівні криптографічного сховища, навіть якщо це просто симетричне шифрування. Підведемо підсумок: звертайтеся з секретами як із секретами!
І останній аспект секретних питань та відповідей — вони більш уразливі для соціального інжинірингу. Намагатися безпосередньо випитувати пароль до чужого облікового запису - це одна справа, а зав'язати розмову про його освіту (популярне секретне питання) - зовсім інше. Насправді ви цілком реально можете спілкуватися з кимось про багато аспектів його життя, які можуть представляти секретне питання, і не викликати при цьому підозр. Зрозуміло, сама суть секретного питання в тому, що воно пов'язане з чиїмось життєвим досвідом, тому воно запам'ятовується, і саме в цьому полягає проблема. люди люблять розповідати про свій життєвий досвід! З цим мало що можна вдіяти, тільки якщо вибрати такі варіанти секретних питань, щоб їх з меншою Імовірністю можна було б витягнути соціальним інжинірингом.
[Далі буде.]На правах реклами
В.Д.Сіна пропонує надійні , кожен сервер підключений до інтернет-канала в 500 мегабіт і безкоштовно захищений від DDoS-атак!
Джерело: habr.com
