Чи приватні непридатні URL-адреси еквівалентні автентифікації на основі пароля?

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

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

По черзі я можу просто використовувати приватну URL-адресу . Тобто, я міг би просто розмістити ресурс на якомусь неможливо здогадатися шляху, наприклад https://example.com/23idcojj20ijf..., який обмежує доступ до тих, хто знає точний рядок.

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

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

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

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

На інформаційній безпеці є відповідна нитка: Чи є випадкові URL-адреси безпечним способом захисту фотографій профілю ? - Ця історія ділиться однією відповіддю: Dropbox вимикає старі спільні посилання після того, як податкові декларації потрапляють у Google . Тож це не просто теоретичний ризик.

Примітка:

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

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

Приватні / важко здогадатися URL-адреси не еквівалентні автентифікації на основі пароля. За своєю природою приватні URL-адреси взагалі не є приватними - вони є загальнодоступними ресурсами. Я думаю, що термін "приватна" URL-адреса є помилковим, скоріше вони "незрозумілі" URL-адреси.

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

Деякі місця, якими я часто бачив "приватні" URL-адреси, є:

1. Скидання пароля електронної пошти
2. Електронні листи з генерацією сертифікатів
3. Електронні листи для підтвердження облікового запису / електронної пошти
4. Доставка придбаного контенту (електронні книги тощо)
5. Інші речі, такі як реєстрація на рейс, друкований талон, використовують приватні URL-адреси на додаток до традиційної автентифікації

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

Як зазначав Роберт Харві, єдиний спосіб безпечного використання випадкової / приватної URL-адреси - це динамічно генерувати сторінку та надсилати URL-адресу користувачеві таким чином, що користувач може вважатися напіваутентифікованим. Це може бути електронна пошта, SMS тощо.

URL-адреса, що генерується випадковим чином / приватно, зазвичай має кілька властивостей:

1. Термін дії повинен закінчитися через розумну кількість часу
2. Це має бути URL-адреса для одноразового використання: IE має закінчитися після першого доступу до нього.
3. Він повинен відкласти автентифікацію користувача на якусь іншу сутність, якій він довіряє для надійної автентифікації користувача. (Надіславши посилання електронною поштою чи SMS тощо)
4. Сучасний комп’ютер повинен бути неможливим примусово застосовувати URL-адресу у часовому інтервалі, що передує закінченню, - або обмеженням швидкості API, який відкриває ресурс, або створенням кінцевої точки URL-адреси з достатньою ентропією, щоб її не можна було здогадатися.
5. Він не повинен просочувати інформацію про користувача. IE: Якщо на сторінці потрібно скинути пароль: на цій сторінці не повинно відображатися інформація про обліковий запис запитувачів. Якщо Аліса вимагає посилання для скидання пароля, і Боб якось здогадується URL, Боб не повинен знати, чий пароль він скидає.
6. Якщо вона пропускає інформацію про користувача, її слід використовувати поверх традиційної аутентифікації, наприклад, сторінка може вважати аутентифікованого користувача, якщо у них встановлений файл cookie або якщо їх session_id все ще дійсний.

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

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

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

Я міг би сидіти в тому ж Інтернет-кафе, що і ви, підслуховуючи ваше Wi-Fi, коли ви вводите свою "непридатну" URL-адресу. У той момент, якщо ви не використовували SSL або якщо я можу використовувати останню нову помилку у вашій реалізації SSL, я б також знав ваш секрет.

У цій темі вже багато хороших відповідей, але безпосередньо вирішити питання:

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

Дозвольте встановити визначення. "Автентифікація" - це надання повноважень для підтвердження претензії на особу. Контроль доступу зазвичай базується на ідентифікації користувача.

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

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

Ім'я користувача / пароль дає вам набагато більш детальний контроль доступу.

Контроль доступу дозволяє особі (суб'єкту) отримати доступ до ресурсу (об'єкта). У прикладі вашої URL-адреси особа - це "кожен, хто коли-небудь отримує URL-адресу будь-якими способами".

Перейдіть з ім'ям користувача / паролем, якщо можете. URL-адреси витікають різними несподіваними способами з часом.

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

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

Так само HTTP-проксі зазвичай не реєструє паролі, тоді як URL-адреси зазвичай реєструються.

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

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

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

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

Є ще один аспект, про який я ще не бачив згадування - скорочувачі URL-адрес.

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

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

Тоді, припустимо, хтось поділився цією URL-адресою в уріжувачі URL-адрес google. Сьогодні ця служба висилає ідентифікатор довжиною 10 символів, складений з букв та цифр. (26 + 10) ^ 10 ~ = 3,6 * 10 ^ 15 <2 ^ 52 - тому ми ефективно вдвічі зменшили потужність ключа з 128 біт до 52 біт.

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

Оригінальна стаття: http://arxiv.org/pdf/1604.02734v1.pdf
Публікація в блозі, яка резюмує статтю (автором): https://freedom-to-tinker.com/blog/vitaly/gone-in- шість знаків-коротких URL-адрес - вважаються шкідливими для хмарних служб /