URL-адрес защищенного токена - насколько это безопасно? Прокси-аутентификация в качестве альтернативы?

Я знаю это как URL-адрес защищенного токена, мала, есть другое имя. Но я думаю, вы все это знаете.

Это текниук, который в основном применяется, если вы хотите ограничить доставку контента определенному клиенту, которому вы заранее передали конкретный URL.

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

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

Эта технология используется Amazon (S3 и Cloudfront), CDN уровня 3, Rapidshare и многими другими. Это также основная часть аутентификации дайджеста http, хотя есть еще один шаг вперед - аннулирование ссылок и другие вещи.

Вот ссылка на документы Amazon , если вы хотите узнать больше.

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

Или, что еще хуже, в случае Amazon, получить доступ к вашим услугам в административной области.

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

Поэтому атаки грубой силы для взлома sha1 / md5 или любого другого хеш-кода довольно сложны. Но протокол открыт, поэтому вам нужно только заполнить пробел, где находится секретный токен, и заполнить остальное данными, известными из запроса. И сегодня оборудование потрясающее и может вычислять md5 со скоростью несколько десятков мегабайт в секунду. Атака такого типа может быть распространена на вычислительное облако, и вы не ограничены чем-то вроде «10 попыток в минуту сервером входа в систему или около того», что делает подходы к хешированию, как правило, довольно безопасными. А теперь с amazon EC2 вы даже можете арендовать оборудование на короткое время (победите их их же оружием, ха-ха!)

Так что вы думаете? Есть ли у моих опасений основание или я параноик?

Однако

в настоящее время я проектирую облако хранилища объектов для особых нужд (интегрированное транскодирование мультимедиа и специальные методы доставки, такие как потоковая передача и т. Д.).

Теперь level3 представил альтернативный подход к защите URL-адресов токенов. В настоящее время это бета-версия, и она открыта только для клиентов, которые ее специально запросили. Они называют это «прокси-аутентификацией».

Что происходит, так это то, что сервер доставки контента делает запрос HEAD серверу, указанному в ваших (клиентских) настройках, и имитирует запрос пользователя. Таким образом, передается тот же путь GET и IP-адрес (как x_forwarder). Вы отвечаете кодом состояния HTTP, который сообщает серверу, нужно ли ему заняться доставкой контента или нет.

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

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