Являются ли частные, не угадываемые 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-адреса пользователю таким образом, чтобы его можно было считать полуавторизованным. Это может быть электронная почта, SMS и т. Д.

Случайно сгенерированный / частный URL обычно имеет несколько свойств:

1. Это должно истечь через разумное количество времени
2. Это должен быть одноразовый URL: IE должен истечь после первого обращения к нему.
3. Он должен отложить аутентификацию пользователя до некоторой другой сущности, которой он доверяет для безопасной аутентификации пользователя. (Отправив ссылку по электронной почте или SMS и т. Д.)
4. Для современного компьютера должно быть невозможным грубое форсирование URL-адреса в период времени, предшествующий истечению срока действия, - либо путем ограничения скорости API, предоставляющего ресурс, либо путем создания конечной точки URL с достаточной энтропией, такой, что ее невозможно угадать.
5. Не должно быть утечки информации о пользователе. IE: если страница предназначена для сброса пароля: страница не должна отображать информацию учетной записи запрашивающих. Если Алиса запрашивает ссылку для сброса пароля, а Боб каким-то образом угадывает URL, Боб не должен знать, чей пароль он сбрасывает.
6. Если это действительно утечка информации о пользователе, она должна использоваться поверх традиционной аутентификации, например, страница может считать пользователя аутентифицированным, если у него есть набор файлов cookie или если их session_id все еще действителен.

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

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

Некоторые более продвинутые протоколы (например, OAUTH, Kerberos, ...) позволяют вам доказать, что вы знаете секрет, фактически не передавая секрет. Это важно, потому что есть и другие способы получить «неузнаваемый» секрет, кроме как его угадать.

Я мог бы сидеть в том же интернет-кафе, что и вы, подслушивая ваше WiFi-соединение, когда вы набираете свой «неузнаваемый» 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 бит (т.е. guid). Кроме того, давайте предположим, что ваш генератор случайных чисел действительно силен и что вы генерируете эти биты единообразным способом. Угадать 128-битное число очень сложно и может занять много времени - ваш URL эффективно защищен 128-битным ключом.

Затем, давайте предположим, что кто-то поделился этим URL на Google URL сокращении. Сегодня этот сервис генерирует 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- шесть символов-короткие ссылки рассмотренного безвреден-для-облачных услуг /