Являются ли частные, не угадываемые URL-адреса эквивалентными аутентификации на основе пароля?

128

Я хочу выставить ресурс в сети. Я хочу защитить этот ресурс: убедиться, что он доступен только определенным лицам.

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

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

С точки зрения злодея, который хочет получить доступ к этому ресурсу, эти подходы эквивалентны? Если нет, то чем они отличаются? А что касается ремонтопригодности, есть ли плюсы и минусы любого из подходов, о которых я должен знать, прежде чем применять один или другой?

GladstoneKeep
источник
45
Этот подход обычно используется только без аутентификации для таких вещей, как сброс пароля. Срок действия неосуществимой ссылки обычно истекает в течение короткого периода времени, и его может использовать только кто-то, кто уже полу-аутентифицирован (т.е. веб-сайт уже знает адрес электронной почты, на который была отправлена ​​ссылка).
Роберт Харви
6
Связанное обсуждение по security.SE: security.stackexchange.com/q/58215/37496
Марк
9
@MonkeyZeus это не безопасность через неизвестность. Секрет, который обычно является паролем, в данном случае является URL.
Davidmh
16
@MonkeyZeus: «Безопасность через неизвестность» означает сохранение секретности реализации механизма, а не использование неясных ключей. Если неопровержимые URL-адреса являются безопасными из-за неясности, то и надежные пароли тоже.
JacquesB
1
@GladstoneKeep помните о сокращениях URL. Как только кто-то из злоумышленников воспользуется одним из них, ссылку будет намного легче угадать / записать.
RookieTEC9

Ответы:

203

Частный URL-адрес несколько слабее, чем аутентификация с использованием учетных данных, даже если размер URL-адреса в битах такой же, как у учетных данных. Причина в том, что URL может легче «просочиться». Кэшируется в браузере, регистрируется на сервере и так далее. Если у вас есть исходящие ссылки, частный URL может отображаться в заголовке реферера на других сайтах. (Это могут также видеть люди, просматривающие ваше плечо.)

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

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


Информационная безопасность связана с темой: действительно ли случайные URL-адреса являются безопасным способом защиты фотографий профиля ? - один ответ разделяет эту историю: Dropbox отключает старые общие ссылки после того, как налоговые декларации попадают в Google . Так что это не просто теоретический риск.

JacquesB
источник
7
Незначительный спор, но «обычно используемый только для однократных операций» кажется чрезмерным утверждением, учитывая, что Dropbox (и, возможно, другие облачные сервисы) используют их для «защиты» доступа к файлам.
Стив Джессоп
4
Я бы добавил, что пользователей с ограниченным успехом учат защищать свои пароли, а не защищать свои URL-адреса.
Свавил
1
Следует добавить, что многие технические проблемы можно устранить с помощью параметра в частном URL-адресе, например xzy.com/myDoc?auth=8502375, и автоматического перенаправления на простой URL-адрес после проверки подлинности. - Но это не решает все возможные проблемы
Falco
3
TL; DR - такого понятия, как секретный URL, не существует. Существует текущая атака, которая выставляет URL-адреса злоумышленнику в точках доступа Wi-Fi, даже если вы обычно отправляете URL-адрес по HTTPS. Атака нарушает автоматическое обнаружение веб-прокси (WPAD), заставляя ваш браузер отправлять все ваши URL-адреса злоумышленнику. См. (Например) arstechnica.com/security/2016/07/…
Харальд
5
@JacquesB Разве некоторые риски, которые вы определили, не были уменьшены путем помещения частной части в фрагмент фрагмента URL-адреса (т. Е. После «#», как, например, Stack Exchange для своих ответов аутентификации Oauth)? Например, заголовок реферера не может включать фрагмент .
Джейсон C
48

Примечание:

Многие люди путают «частный» 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, чтобы поделиться им с ними. Однако, если ресурс можно использовать для кражи личных данных или скомпрометировать их учетные записи с другими поставщиками услуг, вам, вероятно, будет гораздо важнее ограничить доступ к этому ресурсу.

Чарльз Аддис
источник
4
Если бы я хотел поделиться секретным рецептом кока-колы с моей командой разработчиков продукта, это потребовало бы чего-то отличного от того, что я хотел бы поделиться рецептом картофельного салата, который я подавал соседям во время барбекю-вечеринки по соседству. Опять контекст. :-)
CVn
7
@ MichaelKjörling Я не уверен, что кто-то может отличить меня от моего поста. Я совершенно ясно заявил, что разные ресурсы требуют разных уровней аутентификации. Рецепт кока-колы гораздо ценнее, чем рецепт бабушкиного печенья.
Чарльз Аддис
9
@CharlesAddis Очевидно, вы никогда не пробовали печенье моей бабушки!
Брайан
1
Я думаю, что, хотя я могу ошибаться, то, что @ Michael говорит, что ваше пятизначное описание свойств, которые должен иметь секретный URL, уже излишне для того, чтобы поделиться секретным рецептом с друзьями. Создание каждого отдельного использования (и, следовательно, отдельного URL-адреса для каждого друга, который обращается к рецепту), в частности, вызывает большие трудности из-за незначительной выгоды, особенно если есть также время истечения срока действия. Я прочитал ваш ответ, чтобы означать, «допустимо использовать частный URL, но частные URL должны иметь эти 5 свойств», и IMO это немного неправильно.
Стив Джессоп
1
@BenjaminHodgson, именно это является причиной для пункта № 5 =>, если ссылка / URL попадает в чужие руки, она не должна пропускать какую-либо информацию о пользователе, который ее запросил.
Чарльз Аддис
8

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

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

Я мог бы сидеть в том же интернет-кафе, что и вы, подслушивая ваше WiFi-соединение, когда вы набираете свой «неузнаваемый» URL. В этот момент, если вы не используете SSL или если я смогу использовать последнюю новую ошибку в вашей реализации SSL, тогда я буду знать и ваш секрет.

Соломон Медленный
источник
1
Чтобы быть справедливым, это также относится к аутентификации или любому общению.
Энди
«Подслушивание вашего Wi-Fi-соединения» работает на все: URL-адреса, CSRF-защищенные файлы <form>, зашифрованные данные военного уровня JavaScript (возможно, потребуется активный сниффинг). Это легко исправить: используйте HTTPS.
Густаво Родригес
@GustavoRodrigues Прежде всего, если подслушивание действительно «работает на что-либо », то оно будет работать на HTTPS. Иначе, что означает «что-нибудь»? Или, как вы думаете, какая магия в HTTPS, которая ставит его выше всего остального?
Соломон Слоу
2
... но это волшебство , которое подопечные от прослушки: Это шифрование с открытым ключом. Вот простой пример: служба отправляет мне запрос, содержащий случайное число и метку времени. Я подписываю запрос своим закрытым ключом и возвращаю его. Если они могут подтвердить мой ответ моим зарегистрированным открытым ключом, то это доказывает, что я знаю секрет (секрет - мой закрытый ключ), но я доказал это, даже не раскрывая его потенциальному подслушивающему. Это не поможет перехватчику переиграть мой ответ, потому что служба никогда не отправит один и тот же вызов дважды.
Соломон Слоу
HTTPS (то есть HTTP поверх SSL) использует криптографию с открытым ключом, но FYI, самые популярные реализации SSL, имеют историю ошибок, которые позволяли злоумышленникам взломать даже несмотря на криптографию. Новые ошибки (также известные как «эксплойты»), по-видимому, обнаруживаются два или три раза в год, и всем разработчикам всех продуктов, использующих SSL, приходится бегать с горящими волосами, пока не будет исправлен последний эксплойт. (Не спрашивайте меня, откуда я знаю!)
Соломон Медленный
3

Много хороших ответов уже в этой теме, но для прямого решения вопроса:

С точки зрения злодея, который хочет получить доступ к этому ресурсу, эти подходы эквивалентны? Если нет, то чем они отличаются?

Позвольте мне установить определение. «Аутентификация» - это предоставление учетных данных, подтверждающих личность. Контроль доступа обычно основан на идентификации пользователя.

Ваш секретный URL не привязан к конкретному пользователю. Как отмечали другие, он может оказаться в лог-файле прокси-сервера, или в поисковом запросе, который индексируется Google, или во многих других случаях утечки.

С другой стороны, пароль привязан к уникальной учетной записи пользователя. У вас есть возможность сбросить его или разрешить его использование только из домашнего местоположения пользователя, известного IP-адреса или любого другого количества элементов управления.

Имя пользователя / пароль дает вам гораздо более детальный контроль доступа.

Контроль доступа позволяет идентифицировать (субъект) доступ к ресурсу (объекту). В вашем примере с URL-адресом указывается «любой, кто когда-либо получит URL-адрес любым способом».

Идите с именем пользователя / паролем, если можете. С течением времени URL-адреса просачиваются всевозможными неожиданными способами.

JesseM
источник
1

Секретный URL так же безопасен, как и секретный пароль. Однако пароли легче хранить в секрете, чем URL-адреса, потому что все и их программы знают, что пароли должны оставаться секретными.

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

Аналогично, прокси-серверы HTTP обычно не регистрируют пароли, а URL-адреса обычно регистрируются.

Использование URL-адресов для проверки подлинности также означает, что совместное использование URL-адресов совместно использует проверку подлинности, что затрудняет индивидуальный отзыв (или запись) доступа.

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

Meriton
источник
3
Этот ответ делает много предположений, которые ошибочны. Если вы войдете на сайт с HTTPS и введете свое имя пользователя и пароль, промежуточные переходы и прокси не будут знать ваш пароль.
Питер Б
Под «перехватить ваше общение» я имел в виду способность реконструировать его содержание. Это может или не может быть предотвращено HTTPS. В частности, доверяя одному неверному сертификату (например, корпоративному HTTPS-прокси, который использует один и тот же закрытый ключ для всех установок), злоумышленник может получить посреднический HTTPS-трафик.
меритон
2
но, кодируя секрет в URL, вы в основном делаете HTTPS совершенно непригодным для использования. Каждый прыжок между клиентом и сервером имеет секрет. Никаких скомпрометированных сертификатов не требуется.
Питер Б
4
Бред какой то; в HTTPS URL-адрес передается только в зашифрованном потоке. Вы должны путать его с доменом или IP-адресом, которые отображаются в полях DNS-поиска и IP-заголовка соответственно.
меритон
1

Еще один пункт, который нигде не отмечен, - это подавление «догадок». Для большинства систем аутентификации по паролю вы получаете ограниченное количество попыток угадать пароль для пользователя, прежде чем дальнейшие попытки аутентификации будут либо заблокированы, либо ограничены.

Хотя вы могли бы сделать нечто подобное с «угадыванием» для вашей схемы URL, это было бы несколько сложнее реализовать. Если в создании вашего URL-адреса есть узнаваемый шаблон, то может быть трудно остановить кого-то, настраивающего свой путь через ваше «случайное» пространство URL-адресов.

Пэдди
источник
0

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

Ран Бирон
источник
2
Ну, да, но можно было бы надеяться, что любой, кто использует такие сервисы для конфиденциальных данных, будет знать лучше, чем публиковать URL-адреса в любом месте , в том числе в сокращающем сервисе. На самом деле это ничем не отличается от того, чтобы сказать, что Gah! My password/private key is too long and complex. I know! I'll just write it in a text document and put that in a zip file with an easier password.оба являются прозрачными ошибками, что можно надеяться на то, что люди не будут достаточно глупы. Но да, на самом деле, к сожалению, ваше предупреждение, вероятно, необходимо;)
underscore_d
@underscore_d да, конечно - если вы знаете эту тему достаточно подробно, чтобы комментировать, то это не достойный внимания блог.
Роберт Грант