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

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

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

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

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

122 голоса | спросил GladstoneKeep 26 J000000Tuesday16 2016, 18:24:00

7 ответов


201

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

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

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


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

ответил JacquesB 26 J000000Tuesday16 2016, 19:18:29
48

Примечание:

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

ответил Charles Addis 26 J000000Tuesday16 2016, 18:52:44
8

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

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

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

ответил james large 26 J000000Tuesday16 2016, 20:21:22
3

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

  

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

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

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

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

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

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

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

ответил JesseM 27 J000000Wednesday16 2016, 01:12:52
1

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

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

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

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

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

ответил meriton 27 J000000Wednesday16 2016, 00:24:32
1

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

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

ответил Paddy 29 J000000Friday16 2016, 13:49:07
0

Есть еще один аспект, который я еще не видел - URL-сокращения.

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

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

Затем предположим, что кто-то поделился этим URL-адресом в URL-адресе URL-адреса google. Сегодня эта служба испускает идентификатор длиной 10 символов, состоящий из букв и цифр. (26 + 10) & le; 10 ~ 3,6 * 10 & 2 ^ 52 - так что мы эффективно вдвое сократили силу ключа с 128 бит до 52 бит.

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

Оригинальная статья: http://arxiv.org/pdf/1604.02734v1.pdf
Сообщение в блоге, в котором суммируется статья (автор): https://freedom-to-tinker.com/blog/vitaly/gone-in-six-characters-short-urls-considered-harmful-for-cloud-services/

ответил Ran Biron 28 J000000Thursday16 2016, 21:26:19

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132