По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Большинство приложений и веб-администраций привыкли к тому, то клиенты вспоминают и вводят свои пароли каждый раз при входе в систему. Помимо того, что это тяготит клиентов, такой подход представляет угрозу безопасности, так как клиенты часто выбирают ненадежные пароли и повторно используют из во многих других администрациях. Эти проблемы решаются на основе проверки на основе токенов (или токенов). Как насчет того, чтобы посмотреть, как это помогает?
Определение токена
Мы должны начать с точных значений «токенов», которые в основном представляют собой измененные формы паролей или выражений, которые используются для проверки символов.
Когда происходят какие-то обмены данных в Интернете, токены аутентификации являются очень полезными инструментами для демонстрации своей личности во время входа в систему, обновлений, покупок и других процессов. Интересным в токенах является то, что они могут быть последовательными, как при входе в систему, или могут быть более «фиктивными», требуя «контакта» (дополнительного подтверждения или физического присутствия), чтобы гарантировать, что вы тот, за кого себя выдаете, и что вам действительно можно войти.
Токены более безопасны, так как они не должны содержать информацию о клиенте и создаются путем вычислений или выполнения программы. Это существенно лучше в сравнении с тем, что некоторые организации используют индивидуальные данные клиентов в качестве своего регистрационного номера, что позволяет злоумышленникам без особых усилий использовать в своих целях еще больше пользователей. Клиенты, которые используют некоторые частные данные для своих паролей, беспомощны против тех, кто без особых усилий нашел их, просматривая страницы в социальных сетях этих клиентов.
Аутентификация на основе токенов
Токены можно использовать для многофакторной аутентификации (MFA - multi-factor authentication) и серверных протоколов, которые соединяют приложения, API и веб-сайты.
Важность аутентификации на основе токена
Отойдите в сторону от технологий для того, чтобы рассмотреть проблему, которую вы пытаетесь решить. Вы просите законных пользователей подтвердить свою личность, чтобы не пропустить злоумышленников в вашу сеть (где они могут украсть данные, установить программы-вымогатели и т.д.). Так как токен основан на закрытом ключе устройства, то, когда мы используем токен из приложения, такого как PingID, брелка или ключа, который мы подключаем к нашему компьютеру, мы предотвращаем вмешательство внешних субъектов. «Зачем» заключается в том, чтобы выбрать решение для аутентификации на основе токенов, которое проверяет пользователей, не создавая конфликтов и безвыходных положений. Пользователи довольны, а данные в безопасности, когда процесс проходит гладко.
Аутентификация на основе токена в действии
Клиентам могут быть предоставлены токены подтверждения различными способами, включая токены на базе оборудования, одноразовые пароли (обычно предоставляемые с помощью мобильных телефонов) и токены, созданные с помощью программирования на основе стандарта JWT.
Все токены хранят характеристики и информацию о клиенте в безопасном виде. С учетом такого бесчисленного количества правил защиты информации, имеющимися на сегодняшний день, токен также может проверять, что информация достоверна и не была изменена, что является основным условием безопасности. Они также расширяют возможности клиентов, позволяя им входить в систему, не запоминая пароли.
Подтверждение на основе токена обычно происходит в четыре этапа:
Требование – клиент требует доступ к защищенному ресурсу, который его интересует. Клиент изначально должен как-то отличиться без использования токена, например, воспользовавшись именем пользователя или секретной фразой.
Подтверждение – проверка гарантирует, что сертификаты клиента являются действительными и что клиент имеет соответствующие полномочия в указанной инфраструктуре.
Токены – токен выдается инфраструктурой и передается клиенту. Этот процесс включает в себя предоставление токенов клиенту за счет токена оборудования. Это происходит «за кулисами» при генерации токенов, так как взаимодействие клиента происходит с сервером.
Определение – токен фактически хранится у клиентов, будь то в их программе или на их мобильном телефоне. Это дает им возможность в будущем проходить проверку без использования сертификатов.
Преимущества и недостатки аутентификации на основе токена
У такой процедуры есть свои преимущества и недостатки, как и у любого другого подхода или метода.
Преимущества
Эффективность. Программные токены более эффективны и универсальны, чем фактические Токены. Сервер может создавать и проверять сколько угодно токенов в зависимости от ситуации, что упрощает масштабирование количества клиентов, обращающихся к вашему сайту или веб-приложению. Они также не предполагают, что организации будут предоставлять своим клиентам фактические токены.
Адаптивность. Программные токены являются гибкими в том смысле, что они могут быть задействованы на нескольких серверах и одновременно проверять различные сайты и приложения. Они часто используются для реализации системы единого входа (SSO - single sign-on), что упрощает работу клиентов, а также повышает безопасность.
Безопасность. Токены JWT не фиксирует свое текущее состояние и должны быть подтверждены, когда закрытый ключ получен приложением на стороне сервера, которое их создало. Поэтому они считаются надежным и безопасным методом проверки.
Недостатки
Скомпрометированный секретный ключ. Наличие всего одного ключа является существенным недостатком в стандарте JWT. В случае, если за ключом, как предполагалось, не следят проектировщики и администраторы сайта, и он вдруг перехватывается злоумышленниками, то конфиденциальная информация может быть раскрыта. Это может позволить злоумышленникам имитировать клиентов и перехватывать встречи с клиентами, что трудно определить и остановить.
Служебная информация. JWT намного больше стандартного токена встреч и заполняется по мере добавления дополнительной информации о клиенте. Добавление дополнительной информации к маркеру может увеличить время загрузки страницы за счет увеличения времени, необходимого для организации встречи с клиентом.
Долговременная аутентификация не идеальна. Системы, позволяющие клиентам оставаться в системе в течение длительного периода времени, не очень хороши. Эти токены требуют постоянной повторной проверки, что может раздражать клиентов. Хорошей альтернативой в этом случае является использование токенов обновления и их правильное хранение. Клиенты могут использовать токены обновления, чтобы оставаться в сети в течение более длительных периодов времени без необходимости повторного подтверждения.
Насколько безопасна аутентификация на основе токена?
Так как киберпреступность не стоит на месте, а развивается, то специалистам по управлению следует постоянно обновлять свои стратегии и механизмы обеспечения безопасности. Участись атаки с использованием фишинга, физических сил и слов-ссылок с целью получения доступа. Теперь пароли не подходят для подтверждения.
Проверка на основе токенов, в сочетании с другими стратегиями проверки, может стать еще более сложным препятствием, которое не позволит даже опытным хакерам воспользоваться взломанными паролями. Токены должны быть извлечены из устройства, которое их создало (например, мобильного телефона или генератора ключей), что делает их на сегодняшний день исключительно хорошей стратегией подтверждения.
Хотя этапы проверки токенов имеют массу преимуществ, обычно это очень затратный процесс. Токены, хранящиеся в сотовых телефонах, можно использовать, но они могут оказаться бесполезными из-за каких-либо дефектов гаджета. Токены можно спокойно перехватить, если предположить, что они были отправлены через сообщение. Злоумышленник может получить токены, хранящиеся на устройстве, если оно было потеряно или украдено.
Тем не менее, стоит помнить, что нельзя полагаться на стратегию однократной проверки. Проверка токена должна использоваться для двухфакторного или многофакторного подтверждения.
Типы токенов
1. Аппаратный ключ (токен) (USB-ключ)
Токены оборудования – это реальные устройства, которые после утверждения позволяют клиентам получать доступ к защищенным сетям. Иначе их называют токенами проверки или безопасности. Токен оборудования используется для добавления дополнительного уровня безопасности посредством двухфакторной или многофакторной проверки (2FA или MFA). Владелец такого токена подключает его к системе или администрации, которую будет использовать.
Для того, чтобы обеспечить превосходное обслуживание клиентов и возможность адаптироваться, токены оборудования поставляются различных форм и размеров. Самые известные токены – USB-ключи или удаленные токены.
2. JWT – JSON веб-токен
Этот тип является открытым стандартом для обработки данных JSON (RFC 7519). Он подразумевает определенную бесплатную методологию для безопасной передачи данных между сторонами. Для передачи данных между сторонами стандарт JWT использует объекты JSON. Эти токены можно использовать для подтверждения, а также для перемещения дополнительных данных о клиенте или записи.
JWT могут быть отправлены в виде URL-адресов, ограничений POST или заголовков HTTP и могут быть быстро переданы ввиду их небольшого размера. Чтобы избежать различных информационных индексных запросов, JWT содержит всю основную информацию о компоненте. Чтобы подтвердить токен, получателю JWT не нужно обращаться к серверу.
JWT состоит из трех частей:
Заголовок, содержащий информацию о типе токена и использованном методе шифрования.
Полезная нагрузка, содержащая возможности подтверждения наряду с дополнительной информацией о клиенте или записи.
Отпечаток, объединяющий криптографический ключ, который можно использовать для подтверждения полезности полезной нагрузки.
3. Токен одноразового пароля (OTP - One-Time Password)
Это защищенное оборудование или программное устройство, которое генерирует одноразовые пароли. Чаще всего используются индивидуальные идентификационные номер (PIN), которые представляют собой числовые коды от 4 до 12 цифр.
Одноразовые пароли в большинстве случаев создаются и получаются с помощью мобильных телефонов. После подтверждения владения телефоном клиент может использовать приложение-аутентификатор для создания одноразовых паролей. В этом случае телефон выступает в роли генератора кода. OTP также можно отправлять с устройства через SMS.
Объединяя созданные системы проверок, одноразовые пароли дополняют проверку пользователей и паролей. Токены OTP создают PIN-коды одновременно или нет, в зависимости от сервера.
Одновременные токены создают одноразовый пароль, используя ваш закрытый ключ и текущее время, а то время как неодновременный использует механизм аутентификации «запрос-ответ» (CRAM - Challenge Response Authentication Mechanism), набор соглашений, в которых сервер задает вопрос, а токендолжен дать правильный ответ.
4. Токен API
Этот тип токена служит полезным идентификатором для приложений, запрашивающих доступ к вашей администрации. Приложение в этот момент использует токен API, созданный вашей администрацией, чтобы запросить доступ к вашей администрации. Токен API сравнивается с тем, который вы сохранили для проверки и предоставления доступа. Время от времени можно использовать идентификатор сессии, но это отдельный случай.
Токен программного интерфейса становятся все более безопасным вариантом, в отличие от отправки набора имени пользователя и пароля по HTTP. OAuth2 – это одно из наиболее широко используемых на сегодняшний день соглашений о безопасности API.
Bellman-Ford - один из наиболее простых для понимания протоколов, поскольку он обычно реализуется путем сравнения недавно полученной информации о пункте назначения с существующей информацией о том же пункте назначения. Если вновь обнаруженный маршрут лучше, чем известный в настоящее время, маршрут с более высокой стоимостью просто заменяется в списке путей - в соответствии с правилом кратчайшего пути для поиска путей без петель в сети. Таким образом, перебирая всю топологию, можно найти набор кратчайших путей к каждому месту назначения. Рисунок 7 используется для иллюстрации этого процесса.
Примечание. Хотя Bellman-Ford в основном известен своим распределенным вариантом, реализованным в широко распространенных протоколах, таких как Routing Information Protocol (RIP), он изначально был разработан как алгоритм поиска, выполняемый в единой структуре, описывающей топологию узлов и ребер. Беллман-Форд рассматривается здесь как алгоритм.
Алгоритм Bellman-Ford
Bellman-Ford рассчитывает Shortest Path Tree к каждому достижимому пункту назначения в наихудшем случае O (V * E), где V - количество узлов (вершин) в сети, а E - количество каналов (ребер). По сути, это означает, что время, необходимое Bellman-Ford для работы с топологией и вычисления Shortest Path Tree, линейно зависит от количества устройств и каналов. Удвоение количества любого из них удвоит время, необходимое для выполнения. Удвоение обеих одновременно увеличит время работы в 4 раза.
Таким образом, алгоритм Bellman-Ford является умеренно медленным при использовании против более крупных топологий, когда узлы в таблице топологии начинаются в порядке от самого дальнего от корня до ближайшего к корню. Если таблица топологии отсортирована от ближайшего к корню до самого дальнего, Bellman-Ford может завершить работу за O(E), что намного быстрее. В реальном мире трудно обеспечить любой порядок, поэтому фактическое время, необходимое для построения Shortest Path Tree, обычно находится где-то между O(V * E) и O(E).
Bellman-Ford - это greedy алгоритм, предполагающий, что каждый узел в сети, кроме локального, доступен только по бесконечным стоимостям, и заменяющий эти бесконечные стоимости фактическими стоимостями по мере прохождения топологии. Предположение, что все узлы бесконечно удалены, называется ослаблением вычислений, так как он использует приблизительное расстояние для всех неизвестных пунктов назначения в сети, заменяя их реальной стоимостью после ее расчета.
Фактическое время выполнения любого алгоритма, используемого для расчета Shortest Path Tree, обычно ограничивается количеством времени, требуемым для передачи информации об изменениях топологии по сети. Реализации всех этих протоколов, особенно в их распределенной форме, будут содержать ряд оптимизаций, чтобы сократить время их выполнения до уровня, намного меньшего, чем наихудший случай, поэтому, хотя наихудший случай дается в качестве контрольной точки, он часто имеет мало влияющие на производительность каждого алгоритма в реальных развернутых сетях.
Чтобы запустить алгоритм Bellman-Ford в этой топологии, ее необходимо сначала преобразовать в набор векторов и расстояний и сохранить в структуре данных, такой как показано в Таблице 1.
В этой таблице девять записей, потому что в сети девять звеньев (граней). Алгоритмы кратчайшего пути вычисляют однонаправленное дерево (в одном направлении вдоль графа). В сети на рисунке 7 показано, что SPT берет начало в узле 1, а расчет показан удаленным от узла 1, который будет точкой, из которой будут выполняться вычисления. Алгоритм в псевдокоде следующий:
// создаем набор для хранения ответа, по одной записи для каждого узла
// первый слот в результирующей структуре будет представлять узел 1,
// второй узел 2 и т. д.
define route[nodes] {
predecessor // как узел
cost // как целое число
}
// установите для источника (меня) значение 0
// позиция 1 в массиве - это запись исходной точки.
route[1].predecessor = NULL
route[1].cost = 0
// таблица 1, приведенная выше, содержится в массиве под именем topo
// Обходим таблицу вершин (граней) один раз для каждой записи в маршруте
// (результаты) таблица, замены более длинных записей на более короткие
i = nodes
while i > 0 {
j = 1
while j <= nodes { // перебирает каждую строку в топологии
table
source_router = topo[j].s
destination_router = topo[j].d
link_cost = topo[j].cost
if route[source_router].cost == NULL {
source_router_cost = INFINITY
} else {
source_router_cost = route[source_router].cost
}
if route[destination_router].cost == NULL {
destination_router_cost = INFINITY
} else {
destination_router_cost = route[destination_router].cost
}
if source_router_cost + link_cost <= destination_router_cost {
route[destination_router].cost = source_router_cost + link_
cost
route[destination_router].predecessor = source_router
}
j = j + 1 //or j++ depending on what pseudocode this is
representing
}
i = i - 1
}
Этот код обманчиво выглядит сложнее, чем есть на самом деле. Ключевой строкой является сравнение if route [topo [j] .s] .cost + topo [j] .cost route [topo [j] .d] .cost. Полезно сосредоточиться на этой строке в примере. При первом прохождении внешнего цикла (который выполняется один раз для каждой записи в таблице результатов, здесь называется маршрутом):
Для первой строки topo-таблицы:
j равно 1, поэтому topo[j] .s - это узел 6 (F), источник вектора в таблице граней
j равно 1, поэтому topo[j] .d - это узел 7 (G), адресат вектора в таблице граней.
route[6].cost = infinity, topo[1].cost = 1, and route[7].cost = infinity (где infinity - бесконечность)
infinity + 1 == infinity, поэтому условие не выполняется и больше ничего не происходит
Любая запись в topo-таблице с исходной стоимостью infinity даст тот же результат, что и infinity + все, что всегда будет равно infinity. Остальные строки, содержащие источник со стоимостью infinity, будут пропущены.
Для восьмой строки topo-таблицы (восьмая грань):
j равно 8, поэтому topo[j].s - это узел 1 (A), источник вектора в таблице граней
j равно 8, поэтому topo[j].d - это узел 2 (B), место назначения вектора в таблице граней.
route [1].cost = 0, topo[8].cost=2 и route[2].cost = infinity.
0 + 2 = infinity, поэтому условие выполняется
route[2].predecessor установлен на 1, а route [2].cost установлен на 2
Для девятой строки topo -таблицы (девятая грань):
j равно 9, поэтому topo[j].s - это узел 1 (A), источник вектора в таблице граней
j равно 9, поэтому topo[j].d - это узел 3 (C), место назначения вектора в таблице граней.
route[1].cost=0, topo[9].cost=1 и route[3].cost = infinity.
0 + 1 = infinity, поэтому условие выполняется
route[3].predecessor установлен на 1, а route[3].cost установлен на 1
Во втором прогоне внешнего цикла:
Для пятой строки topo-таблицы (пятая грань):
j равно 5, поэтому topo[j].s - это узел 2 (B), источник вектора в таблице граней
j равно 5, поэтому topo[j].d - это узел 6 (F), место назначения вектора в таблице граней.
route[2].cost=2,topo[5].cost=1 и route[6].cost = infinity.
2 + 1 = infinity, поэтому условие выполняется
route[6].predecessor установлен на 2, а route[6].cost установлен на 3
Для шестой строки topo -таблицы (шестая грань):
j равно 6, поэтому topo[j].s равно 2 (B), источник вектора в таблице граней
j равно 6, поэтому topo[j].d равно 5 (E), место назначения вектора в таблице граней
route[2].cost=2, topo[6].cost=2 и route[5].cost = infinity.
2 + 2 = infinity, поэтому условие выполняется
route[5].predecessor установлен на 2, а route[5].cost установлен на 4
Окончание этого прогона показан в Таблице 2.
В третьем прогоне внешнего цикла узел 8 представляет особый интерес, поскольку есть два пути к этому месту назначения. Для второй строки topo -таблицы (вторая грань):
j равно 2, поэтому topo[j].s - это узел 5 (E), источник вектора в таблице граней
j равно 2, поэтому topo[j].d - это узел 8 (H), место назначения вектора в таблице граней
route[5].cost=4, topo[2].cost=1 и route[8].cost = infinity.
4 + 1 = infinity, поэтому условие выполняется
route[8].predecessor установлен на 5, а route[8].cost установлен на 5
Для третьей строки topo -таблицы (третья грань):
j равно 3, поэтому topo[j].s - это узел 4 (D), источник вектора в в таблице граней
j равно 3, поэтому topo[j].d - это узел 8 (H), источник вектора в таблице граней
route[4].cost=2,topo[3].cost=2 и route[8].cost = 5.
2 + 2 = 4, поэтому условие выполняется
route[8].predecessor установлен на 4, а route[8].cost установлен на 4
Интересным моментом в третьем цикле в topo-таблице является то, что запись для грани [5,8] обрабатывается первой, которая устанавливает передатчик 8 (H) на 5 и стоимость на 5. Однако когда обрабатывается следующая строка в таблице topo [4,8], алгоритм обнаруживает более короткий путь к узлу 8 и заменяет существующий. Таблица 2 показывает состояние таблицы маршрутов при каждом проходе через таблицу topo.
В таблице 2 верхняя строка представляет запись в таблице маршрутизации и узел, доступный в сети. Например, A (1) представляет лучший путь к A, B (2) представляет лучший путь к B и т. д. Столбец P представляет предшественника или узел, через который A должен пройти, чтобы достичь указанного пункта назначения. C представляет собой стоимость достижения этого пункта назначения. Рассмотренный пример сети может быть завершен за три цикла, если алгоритм настроен так, чтобы обнаруживать завершение дерева. Псевдокод, как показано, не имеет никакого теста для этого завершения и в любом случае будет выполнять полные 8 циклов (по одному для каждого узла).
Теперь почитайте про алгоритм диффузного обновления DUAL.
Данная статья будет посвящена еще одному проприетарному протоколу компании Cisco Systems - VTP (VLANTrunkingProtocol), который призван решать возможные проблемы в среде коммутации в случае расширения парка оборудования организации.
Для начала вспомним что же такое VLAN. VLAN – это Virtual Local Area Network, что дословно переводится как “виртуальная локальная сеть”. При создании VLAN’а хосты физической сети, объединенные общей функцией, выделяются в логическую виртуальную сеть, при этом их физическое местонахождение не имеет значения. Обычно VLAN настраивается на сетевом коммутаторе, по средствам добавления портов, за которыми находятся хосты подлежащие объединению, в группу. Выглядит это примерно так:
На слайде приведен случай, когда на коммутаторе настроено два VLAN’a. Порты с 1 по 3 принадлежат VLAN’у 10, а порты с 6 по 8 находятся во VLAN’е 20.
Команды, которые вводил администратор для такой конфигурации, примерно такие:
Создание VLAN 10
Switch(config)# vlan 10
Switch(config)# interface range fa0/1 - 3
Switch(config-if)# switchport mode access
Switch(config-if)# switchport access vlan 10
Создание VLAN 20
Switch(config)# vlan 20
Switch(config)# interface range fa0/5 - 8
Switch(config-if)# switchport mode access
Switch(config-if)# switchport access vlan 20
Как видите набор команд довольно простой, но администратор вводил их на единственном коммутаторе. Хосты реальных VLAN’ов могут быть рассредоточены по сети и находиться за разными устройствами, как показано на рисунке:
Как видно из рисунка хосты принадлежащие VLAN 10 рассредоточены по сети, они находятся как за коммутатором 1 так и за коммутатором 3. Для того, чтобы они могли корректно взаимодействовать, администратору вручную придется создавать VLAN на каждом устройстве и добавлять в них порты. Реальные сети могут содержать ещё больше VLAN сетей и каждую необходимо прописать вручную, в следствие чего растет вероятность допущения ошибок в конфигурации, которая может привести перекрестному соединению и многочисленным несогласованностям.
Для того чтобы исключить вероятность таких ошибок и был разработан протокол VTP, который позволяет устройствам автоматически делиться информацией о настроенных на них VLAN’ах и самостоятельно вносить изменения в конфигурацию.
Режимы работы VTP
VTP коммутатор имеет два режима работы:
Server
В этом режиме можно создавать новые и вносить изменения в существующие VLAN’ы.
Коммутатор будет обновлять свою базу VLAN’ов и сохранять информацию о настройках во Flashпамяти в файле vlan.dat.
Генерирует и передает сообщения как от других коммутаторов, работающих в режиме сервера, так и от клиентов
Client
Коммутатор в этом режиме будет передавать информацию о VLAN’ах полученную от других коммутаторов и синхронизировать свою базу VLANпри получении VTPобновлений. Настройки нельзя будет поменять через командную строку такого устройства. 3) Transparent
В данном режиме коммутатор будет передавать VTPинформацию другим участникам, не синхронизируя свою базу и не генерируя собственные обновления. Настройки VLAN можно поменять лишь для локального коммутатора.
Типы сообщений VTP
В VTPсуществует три типа сообщений:
Advertisement requests
Представляет из себя запрос от клиента к серверу на оповещение SummaryAdvertisement
Summary advertisements
Данное сообщение по умолчанию сервер отправляет каждые 5 минут или сразу же после изменения конфигурации.
Subset advertisements
Отправляется сразу же после изменения конфигурации VLAN, а также после запроса на оповещение.
Стоит отметить, что VTPкоммутатор, который получает информацию о новых VLAN’ах, внесет ее в свою конфигурацию только в том случае, если сообщение пришло от коммутатора с большим номером ревизии.
Номер ревизии это некий идентификатор “свежести” базы VLAN. Коммутатор воспринимает базу с наивысшим номером ревизии как самую “свежую” и вносит изменения в свою конфигурацию.
Протокол VTPявляется проприетарным, т.е закрытым. Он сильно облегчает жизнь администраторам, работающим с оборудованием Cisco.
Для оборудования других производителей существует аналогичный открытый стандарт - GVRP (GARP VLAN Registration Protocol).