По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
В больших корпоративных сетях могут использоваться несколько протоколов внутренней маршрутизации. Такая практика часто встречается при слиянии двух компаний. Чтобы компьютеры в одном домене маршрутизации (далее просто «домен») видели хосты в другом домене применятся так называемая редистрибуция. Эта функция позволяет маршрутизатору выбрать маршрут, выученный через один протокол маршрутизации, например, EIGRP и добавить в его в список анонсируемых сетей в другой, например, OSPF. Эта операция выполняется на маршрутизаторах, который смотрят в обе сети и называются точкой редистрибуции (Redistirbution Point). Маршрутизаторы, которые занимаются анонсированием сетей из одного домена в другой используют для этого таблицу маршрутизации. Другими словами, если маршрутизатор не найдет путь до какой-то сети в своей таблице, то он не будет анонсировать его в другой домен. Схема сети Для построения отказоустойчивой сети обычно применяются два или более маршрутизатора, которые занимаются перебросом маршрутной информации с одного домена в другой. В такой ситуации может образоваться так называемая петля маршрутизации. Поясним на рисунке: В данном случае пакеты из маршрутизатор 2, чтобы добраться до сети Х, которая находится в том же домене делает круг через RD1 > R1 > RD2 > Subnet X. Это происходит потому, что маршрут, объявленный RD1 в Домен маршрутизации 2, имеет меньшее административное расстояние (Administrative Distance, AD), чем маршруты, объявленные роутерами из того же домена. Далее рассмотрим в каких случаях возможно такое. Как избежать петель? Один из самых лёгких методов для избегания петель маршрутизации это при добавлении маршрутов из одного домена в другой более высокой метрики. В данном случае маршрутизаторы RD1 и RD2 при анонсировании маршрутов, выученных протоколом RIP в домен OSPF, назначают им метрику 500. И наоборот, из домена OSPF в домен RIP маршруты анонсируются с метрикой 5. Второй способ – это административное расстояние. Любой маршрут, который добавляется в таблицу маршрутизации роутера, сопоставляется с административным расстоянием. Если роутер получил несколько маршрутов в одну и ту же сеть с одной и той же длиной префикса, то в таблицу попадают маршруты с меньшим AD. Маршрутизатор не учитывает метрику. Вместе с этим, AD – это локальное значение для каждого роутера и не объявляется соседним маршрутизаторам. В таблице ниже приведены административные расстояния для всех типов маршрутов на роутерах Cisco. Тип маршрутаАдминистративное расстояниеConnected (подключённый)0Static (Статический)1EIGRP Summary route5eBGP (external BGP)20EIGRP (internal)90IGRP100OSPF110IS-IS115RIP120EIGRP (external)170iBGP (internal BGP)200 Настройки AD по умолчанию для протокола EIGRP при анонсировании маршрутов в OSPF и RIP предотвращают образование петель маршрутизации. На рисунке выше подсеть 172.16.35.0/24 анонсируется через RD1 в домен OSPF. Маршрутизатор R2 в свою очередь анонсирует выученную через external OSPF сеть роутеру RD2. Но RD2 уже выучил маршрут до сети 35.0 через EIGRP, у которого административное расстояние равно 90, что меньше чем AD OSFP, которое равно 110. Таким образом RD2 не добавит маршрут, полученный у R2 с AD 110 в таблицу маршрутизации и соответственно не будет редистрибутировать обратно в EIGRP. Таким образом логику работы маршрутизатора RD2 можно сформулировать следующим образом: RD2 считает маршрут, полученный по EIGRP лучшим, так как у него меньшее административное расстояние, и добавляет его в таблицу маршрутизации. RD2 не будет анонсировать маршрут, полученный через OSPF, так как его нет в таблице маршрутизации. В силу своей специфик, протокол EIGRP также предотвращает образование петель маршрутизации при редистрибуции из OSPF и RIP. Как было указано на таблице выше, внешние маршруты в EIGRP имеют административное расстояние равным 170. В данном случае маршрутизатор RD2 выучил два маршрута в сеть 192.168.11.0/24. Один через R2 в домене OSPF с AD равным 110, второй через R1 в домене EIGRP с административным расстоянием равным 170-ти. Действуя по указанной выше логике, RD2 добавит в таблицу маршрутизации сеть 11.0 выученный у роутера R2 предотвращая таким образом образование петли. Если в случае EIGRP-OSPF, EIGRP-RIP нам удалось без особых усилий предотвратить петлю маршрутизации, то в случае OSPF-RIP всё немного сложнее. Так как OSPF для всех типов маршрутов использует один показатель AD – 110, то при редистрибуции между RIP и OSPF избежать петель удается только изменение административного расстояния протоколов маршрутизации. Делается это командой distance. Для изменения показателя AD для внешних маршрутов, в интерфейсе настройки OSPF прописываем команду distance external ad-value. Значение, указанное параметром должно быть больше, чем у RIP (120). Но не редки случаи, когда в сети работают более двух протоколов маршрутизации. В таких случаях значения AD по умолчанию не помогают. На рисунке ниже сеть 172.20.0.0/16 выучена протоколом EIGRP как внешний через RIP с АР (Административное Расстояние) равным 170. В свою очередь RD1 анонсирует данную сеть в домен OSPF с АР равным 110. RD2 же вместо маршрута с АР 170, полученного из домена EIGRP в таблицу добавляет маршрут с АР 110, полученный из домена OSPF. При таком раскладе маршрутизатор R4 получает два маршрута в одну и ту же сеть с одним и тем же АР. И в случае если метрика RD2 лучше, то R4 отправке пакетов в сеть 172.20 будет использовать более длинный путь. Нужно заметить, что это только в том случае, когда домены расположены именно в указанном порядке. В таких случаях применяется настройка административного расстояния в зависимости от маршрута. Как было указано выше, для изменения АР используется команда distance. Эта команда принимает несколько параметров: distance distance ip-adv-router wc-mask [ acl-number-or-name ] В данной команде обязательным параметром является IP соседнего маршрутизатора. Если IP адрес анонсирующего маршрутизатора совпадёт с указанными в команде, то для маршрутов, полученных от этого соседа данный роутер назначит указанный в команде АР. Рассмотрим указанный случай на практике. Детальная топология сети, показанная выше, указана на рисунке, а конфигурацию можете скачать по ссылке ниже: Скачать файлы конфигрурации Для начала просмотрим с каким АР RD1 выучил маршрут до сети 172.20: Как видим, RD1 добавил в таблицу маршрутизации маршрут, выученный через OSPF, вместо EIGRP, так как АР у OSPF меньше. Теперь изменим поведение маршрутизатора и посмотрим, как это повлияет на таблицу маршрутизации. ip access-list standard match-172-20 permit host 172.20.0.0 router ospf 2 distance 171 1.1.1.1 0.0.0.0 match-172-20 P.S. В GNS скорее всего придётся выключить, затем включить интерфейс, смотрящий в OSPF домен, чтобы изменения применились. В реальной сети всё работает правильно. Поясним, что мы написали выше. Со стандартным списком доступа всё понятно. Команде distance параметром задали 171 – административное расстояние. Затем идет router id маршрутизатора, который анонсирует сеть 172.20. В нашем случае это маршрутизатор RD1. Таким образом, OSPF посмотрит полученный LSA и, если там увидит идентификатор маршрутизатора RD1, а также сеть, которая указана разрешённой в списке доступа, то применит этому маршруту расстояние 171. Отметим, что указанную конфигурацию нужно сделать на всех роутерах, которые занимается распределением маршрутов и для всех сетей их третьего домена.
img
REST API – один из самых распространенных типов доступных веб-сервисов, но проектировать их сложно. Они позволяют разным клиентам, включая браузер, настольные приложения, мобильные приложения и практически любое устройство с подключением к Интернету, взаимодействовать с сервером. Именно поэтому очень важно правильно проектировать REST API, чтобы в будущем не было проблем. Создание API с нуля может оказать непосильной задачей из-за большого количества вещей, которые необходимо учесть – от базовой безопасности до использования правильных методов HTTP, реализации аутентификации, определения того, какие запросы и ответы среди многих других принимаются и возвращаются. В этой статье я очень постарался сжать материал в 15 пунктов с важными рекомендациями, которые позволят создать хороший API. Все рекомендации никак не зависят от языка, поэтому потенциально применимы к любой платформе или технологии. 1. Обязательно используйте имена существительные в названиях путях к конечным точкам Вам всегда следует использовать имена существительные, которые обозначают объект, который вы извлекаете или которым вы манипулируете. В качестве имени пути всегда предпочтительнее использовать множественное число. Избегайте использования глаголов в названиях путях к конечным точкам, потому что наш метод HTTP-запроса уже является глаголом и по сути не добавляет никакой новой информации. Действие должно быть произведено с помощью методов HTTP-запроса. Наиболее распространенными являются методы GET, POST, PATCH, PUT и DELETE. GET извлекает ресурсы POST отправляет новые данные на сервер PUT/PATCH модифицируют уже существующие данные DELETE удаляет данные Глаголы сопоставляются с функциями CRUD (Create, read, update и delete). Помня об этих принципах, мы должны создавать маршруты типа GET /books для получения списка книг, а не GET /get-books или GET /book. Аналогично, POST /books - для добавления новой книги, PUT /books/:id - для модификации полных данных книги с заданным идентификатором (id), а PATCH /books/:id обновляет частичные изменения в книге. И наконец, DELETE /books/:id предназначен для удаления существующей книги в заданным идентификатором. 2. JSON как основной формат отправки и получения данных Несколько лет назад прием и ответы на запросы API выполнялись в основном в XML. Но сейчас «стандартным» форматом для отправки и получения данных API в большинстве приложений стал JSON. Поэтому наш второй пункт рекомендует убедиться, что конечные точки возвращают формат данных JSON в качестве ответа, а также при приеме информации через полезную нагрузку HTTP-сообщений. Несмотря на то, что FormData хорошо подходит для отправки данных от клиента, особенно если нам нужно отправлять файлы, они не очень подходят для текста и чисел. Нам не нужны FormData для их передачи, так как в большинстве фреймворков можно передавать JSON непосредственно на стороне клиента. При получении данных от клиента нам необходимо убедиться, что клиент правильно интерпретирует данные JSON, и для этого при выполнении запроса в заголовке ответа Content-Type должен быть установлен на application/json. Стоит еще раз упомянуть исключение, когда мы пытаемся отправлять и получать файлы между клиентом и сервером. В этом конкретном случае нам необходимо обрабатывать файл ответа и отправлять FormData с клиента на сервер. 3. Используйте коды состояний HTTP Коды состояний HTTP всегда полезно использовать для того, чтобы указать на выполнение или невыполнение запроса. Не используйте слишком много кодов состояний и всегда используйте одни и те же коды для одних и тех же результатов в API. Вот некоторые примеры: 200 – общее выполнение 201 – успешное создание 400 – неверные запросы от клиента, такие как неверные параметры 401 – несанкционированные запросы 403 – отсутствие прав доступа к ресурсам 404 – отсутствуют ресурсы 429 – слишком много запросов 5хх – внутренние ошибки (их следует избегать насколько это возможно) В зависимости от ситуаций их может быть и больше, но ограничение количества кодов состояний помогает клиенту использовать более предсказуемый API. 4. Возвращайте стандартизированные сообщения Помимо использования кодов состояния HTTP, которые указывают на результат запроса, всегда используйте стандартизированные ответы для аналогичных конечных точек. Пользователи могут всегда рассчитывать на одинаковую структуру и действовать соответственно. Это также относится к статусу, указывающему на выполнение запроса, и сообщениях об ошибках. В случае выборки коллекций придерживайтесь определенного формата, независимо от того, включает ли тело ответа массив данных, подобный этому: [ { bookId: 1, name: "The Republic" }, { bookId: 2, name: "Animal Farm" } ] или вот такой комбинированный ответ: { "data": [ { "bookId": 1, "name": "The Republic" }, { "bookId": 2, "name": "Animal Farm" } ], "totalDocs": 200, "nextPageId": 3 } Здесь рекомендация заключается в том, чтобы быть последовательным независимо от того, какой подход вы выберете для этого. Аналогичное поведение должно быть реализовано при извлечении объекта, а также при создании и модификации ресурсов, которым обычно рекомендуется возвращать последний экземпляр объекта. // Ответ после успешного вызова POST /books { "bookId": 3, "name": "Brave New World" } Хоть это и никак не навредит, но все же излишнем будет включать универсальное сообщение, например, «Книга успешно создана», так как это уже следует из кода состояния HTTP. И последнее, но не менее важное: при наличии стандартного формата ответа коды ошибок также важны (и даже более важные). Это сообщение должно включать информацию, которую клиент может использовать для представления ошибок конечному пользователю, а соответственно, это должно быть не общее предупреждение, такое как «то-то пошло не так», которого следует избегать, насколько это возможно. Вот пример: { "code": "book/not_found", "message": "A book with the ID 6 could not be found" } Опять же, нет необходимости включать код состояния в содержимое ответа, но полезно определить набор кодов ошибок, таких как book/not_found, чтобы пользователь мог сопоставить их с разными строками и создать свое собственное сообщение об ошибке для конечного пользователя. В частности, для сред разработки или промежуточных сред может показаться правильным также включить стек ошибок в ответ с целью помочь в отладке ошибок. Но не включайте те, что находятся в промышленной эксплуатации, так как это создаст угрозу безопасности, раскрывая незапланированную информацию. 5. Используйте разбиение на страницы, фильтрацию и сортировку при выборе коллекций записей Как только будет создана конечная точка, которая возвращает список элементов, необходимо будет установить разбиение на страницы. Обычно коллекции со временем растут, поэтому важно всегда следить за тем, чтобы возвращалось ограниченное и контролируемое количество элементов. Справедливо будет позволить пользователям API выбирать, сколько объектов получить, но всегда полезно заранее определить число и установить для него максимум. Основная причина, почему нужно это сделать, заключается в том, что для возврата огромного массива данных потребуется очень много времени и большая пропускная способность. Для реализации нумерации страниц есть два хорошо известных способа: skip/limit или keyset. Первый вариант обеспечивает более удобный для пользователя способ извлечения данных, но обычно он менее эффективен, так как базы данных сканируют множество документов для извлечения нужных записей. Мне больше нравится второй вариант. Разделения на страницы с помощью keyset получает идентификатор (id) в качестве ссылки для «вырезания» коллекции или таблицы с условием без сканирования записей. Также API должны предоставлять фильтры и возможности сортировки, которые упрощают способы получения данных. Частью решения повышения производительности являются индексные базы данных, которые позволяют максимизировать производительность при помощи шаблонов доступа, которые применяются с фильтрами и параметрами сортировки. При проектировании API эти свойства разбиения на страницы, фильтрации и сортировки определяются как параметры запроса в URL-адресе. Например, если вы хотим получить информацию о первых 10 книгах, принадлежащих к категории «роман», то наша конечная точка будет выглядеть вот так: GET /books?limit=10&category=romance 6. PATCH вместо PUT Маловероятно, что необходимо будет сразу полностью обновить всю запись, обычно есть конфиденциальные или полные записи, которые следует уберечь от манипуляций пользователя. Именно поэтому для выполнения частичных обновлений ресурса следует использовать PATCH, а вот PUT полностью меняет существующий ресурс. Они оба должны использовать тело запроса для передачи информации, подлежащей модификации. Разница лишь в том, что для PATCH это поля, а для запроса PUT – полный объект. Тем не менее, стоит отметить, что ничто не мешает нам использовать PUT для частичной модификации, нет никаких «ограничений на передачу по сети», которые бы это подтверждали. Это просто факт, которого стоит придерживаться. 7. Предоставьте более подробные ответы Шаблоны доступа являются ключевыми при создании доступных ресурсов API и возвращаемых данных. Когда система растет, то и свойства записи также растут, но не всегда все эти свойства нужны клиентам для работы. Именно в таких ситуациях становится полезным предоставление возможности возвращать сокращенные или полные ответы для одной и той же конечной точки. Если пользователю нужны только некоторые поля, то упрощенный ответ помогает снизить расход трафика и потенциально сложность получения других вычисляемых полей. Простой способ реализовать – предоставить дополнительный параметр запроса, чтобы включить или отключить предоставление более подробного ответа. GET /books/:id { "bookId": 1, "name": "The Republic" }GET /books/:id?extended=true { "bookId": 1, "name": "The Republic" "tags": ["philosophy", "history", "Greece"], "author": { "id": 1, "name": "Plato" } } 8. Обязанность конечной точки Принцип единственной обязанности фокусируется на концепции удержания функции, метода или класса на одной обязанности, которую они выполняют хорошо. Мы можем сказать, что это наш API - хороший API, если он выполняет одну конкретную вещь и никогда не меняется. Это помогает пользователям лучше понять наш API и сделать его более предсказуемым, что облегчит общую интеграцию. Лучше всего расширить список доступных конечных точек, а не создавать очень сложные конечные точки, которые пытаются решить множество задач одновременно. 9. Предоставьте полную документацию по API Пользователи вашего API должны понимать, как использовать доступные конечные точки и чего ожидать. Это возможно только при наличии хорошей и подробной документации. Обратите внимание на следующие аспекты, чтобы ваша документация была полной. Доступные конечные точки с описанием их назначения Права доступа, необходимые для выполнения конечной точки Примеры вызовов и ответов Сообщения о предполагаемых ошибках Немаловажным является постоянное обновление документации после внесения изменений и дополнений в систему. Лучший способ для этого – сделать документацию по API неотъемлемой частью разработки. Двумя хорошо известными инструментами в данном вопросе являются Swagger и Postman – они доступны для большинства сред разработки API. 10. Используйте SSL для обеспечения безопасности и настройте CORS Безопасность – еще одно очень важной свойство, которым должен обладать наш API. Настройка SSL путем установки действительного сертификата на сервер обеспечит безопасную связь с пользователями и предотвратит некоторые виды потенциальных атак. CORS (Cross-origin resource sharing – Обмен ресурсами с запросом происхождения) – это функция безопасности браузера, которая ограничивает HTTP-запросы из различных источников, которые инициируются сценариями, запущенными в браузере. Если ресурсы вашего REST API получают непростые HTTP-запросы из разных источников, то вам нужно включить поддержку CORS для того, чтобы пользователи работали соответствующим образом. Протокол CORS требует, чтобы браузер отправил предварительный запрос на сервер и дождался утверждения (или запрос учетных данных) с сервера перед отправкой фактического запроса. Запрос предварительной проверки отображается в API как HTTP-запрос, использующий метод OPTIONS (среди других заголовков). Значит, для поддержки CORS в ресурсе REST API необходимо реализовать метод OPTIONS, который будет отвечать на предварительный запрос, по крайней мере, со следующими заголовками ответа, предусмотренными стандартом Fetch: Access-Control-Allow-Methods Access-Control-Allow-Headers Access-Control-Allow-Origin Какие значения назначать этим ключам, зависит от того, настолько открытым и гибким должен быть наш API. Мы можем назначить определённые методы и известные источники или использовать специальные символы, чтобы иметь открытые ограничения CORS. 11. Управление версиями API В процессе разработки конечные точки начинают меняться и перестраиваться. Но мы должны, насколько это возможно, избегать внезапного изменения конечных точек для пользователя. Рекомендуется рассматривать API как ресурс с обратной совместимость, в котором новые и обновленные конечные точки должны быть доступны, но не должны влиять на предыдущие стандарты. Вот где управление версиями API приходит на помощь – когда клиенты должны иметь возможность выбирать, к какой версии подключаться. Есть несколько способов описать управление версиями API: Добавление нового заголовка x-version=v2 Наличие параметра запроса ?apiVersion=2 Версия как часть URL: /v2/books/:id 12. Кэшируйте данные для повышения производительности Чтобы повысить производительность нашего API, полезно следить за данными, которые редко меняются и к которым часто обращаются. Для таких данных мы можем рассмотреть возможность использования базы данных в памяти или кэш-памяти, которая избавит от доступа к основной базе данных. Главная проблема здесь заключается в том, что данные могут устареть, поэтому следует решить вопрос с внедрением последней версии. Использование кэшированных данных будет полезным для пользователей для загрузки конфигураций и каталогов информации, которые не предназначены для постоянного изменения в течение долгого времени. При использовании кэширования не забудьте включить Cache-Control в заголовки. Это поможет пользователям эффективно использовать систему кэширования. 13. Используйте даты в формате UTC Сложно представить системы, которые в какой-то момент перестает работать из-за дат. На уровне данных важно быть логичным в том, как даты отображаются на клиентских приложениях. ISO 8601 – это международный стандартный формат данных для даты и времени. Данные должны быть в формате Z или UTC, для которых пользователи могут могли бы выбрать часовой пояс в случае, если такая дата должны отображаться при любых условиях. Вот пример того, как должны выглядеть даты: { "createdAt": "2022-03-08T19:15:08Z" } 14. Конечная точка проверки работоспособности Может произойти ситуация, когда наш API перестанет работать, и для его запуска потребуется время. При таких обстоятельствах клиенты хотят знать, что службы недоступны, и быть в курсе ситуации. Для этого предоставьте конечную точку (например, GET /health), которая бы определяла работоспособность API. Эта конечная точка может вызываться и другими приложениями, такими как балансировщики нагрузки. Можно продвинуться еще дальне и сообщать о периодах технического обслуживания или работоспособности частей API. 15. Разрешите аутентификацию по ключу API Аутентификация с помощью ключей API даст возможность сторонним приложениям легко создавать интеграцию с нашим API. Эти ключи API следует передавать с помощью пользовательского заголовка HTTP (например, Api-Key или X-Api-Key). Ключи должны иметь дату окончания срока действия, и должна быть возможность их отозвать с целью признания недействительными по соображениям безопасности.
img
В этой статье расскажем что такое хеш, хеширование и рассмотрим какие есть алгоритмы хеширования. Что такое хеширование? Хеширование означает использование некоторой функции или алгоритма для сопоставления данных объекта с некоторым репрезентативным целочисленным значением. Результат этой функции известен как хеш-значение или просто хэш (hash). Хорошая хеш-функция использует алгоритм одностороннего хеширования, или, другими словами, хэш нельзя преобразовать обратно в исходный ключ. Обеспечение того, чтобы данные не изменялись (модифицировались) во время передачи, очень важно, и чтобы помочь нам определить, сохраняется ли целостность сообщения, мы можем использовать алгоритмы хеширования. Алгоритмы хеширования предназначены для получения входных данных, например, строки текста или файла, а затем использования односторонней функции для создания дайджеста. Дайджест (digest) - это хеш-представление ввода, и его нельзя отменить. Каждый уникальный файл или сообщение генерирует уникальное хеш-значение (дайджест). Это означает, что, если данные каким-либо образом изменены, значение хеш-функции будет однозначно другим. На следующем рисунке показан процесс одностороннего хеширования: Как этот процесс работает между устройствами? Представьте, что отправитель, хост A, хочет отправить сообщение на устройство назначения, хост B. Вместо того, чтобы хост A отправлял сообщение как есть, хост A создаст дайджест сообщения. Как только в дайджесте будет создано сообщение, хост A отправит и сообщение, и дайджест хосту B. На следующем рисунке показано, что хост A отправляет сообщение с дайджестом хосту B: Когда хост B получает сообщение от источника, он также создает дайджест сообщения и сравнивает его с дайджестом, полученным от хоста A. Если оба значения хеш-функции (дайджесты) совпадают, это означает, что сообщение не было изменено во время передачи. Однако, если значения дайджеста различаются, это означает, что где-то по пути сообщение было изменено и, следовательно, содержимое сообщения не совпадает. Возможно ли, что два разных файла будут иметь одинаковое хеш-значение? Хотя алгоритмы хеширования предназначены для создания уникального дайджеста для каждого уникального файла, в прошлом были случаи, что у двух разных файлов одно и то же значение хеш-функции. Это известно, как хэш-коллизия. Если произошла коллизия хеширования, это означает, что алгоритм хеширования, используемый во время процесса, уязвим, и ему не следует доверять. Однако некоторые из самых популярных алгоритмов хеширования, которые используются в настоящее время, подвержены коллизии хеширования. Алгоритмы хеширования Message Digest 5 (MD5) - это алгоритм хеширования, который создает 128-битный дайджест. Алгоритм MD5 был реализован во многих системах на протяжении многих лет и работал хорошо до тех пор, пока не произошла коллизия хеширования. Это сделало MD5 уязвимым алгоритмом хеширования, который больше не рекомендуется. На следующем рисунке представлен процесс хеширования MD5: Как показано на предыдущей диаграмме, сообщение отправляется алгоритму MD5, который затем преобразуется в 128-битный дайджест. Хотя MD5 все еще используется во многих системах, рекомендуется использовать более безопасную функцию, такую как Secure Hashing Algorithm 2 (SHA-2). Еще одна хорошо известная функция хеширования - это Secure Hashing Algorithm 1 (SHA-1). Этот алгоритм хеширования был создан еще в 1990-х годах Национальным институтом стандартов и технологий (NIST). NIST разработал этот алгоритм с функциями, аналогичными MD5. Одним из основных преимуществ использования SHA-1 для проверки целостности является то, что он создает 160-битный дайджест любого сообщения или файла. На следующем рисунке представлена функция SHA-1: Хотя SHA-1 считается лучше, чем MD5, так как создает более крупный дайджест, он работает медленнее, чем MD5, и содержит уязвимости в самом алгоритме. Однако NIST разработал более новую версию, известную как SHA-2. SHA-2 позволяет создавать дайджест с использованием битов большого размера, таких как: SHA-224 (224 bit) SHA-256 (256 bit) SHA-384 (384 bit) SHA-512 (512 bit) Имейте в виду, что даже если вы знаете, что для проверки целостности сообщения использовалось хеширование, оно все равно уязвимо для атаки MiTM. Представьте, что источник отправляет сообщение с хеш-значением. Злоумышленник может перехватить сообщение, изменить его содержимое и пересчитать новый хэш перед его отправкой адресату. Чтобы помочь получателю проверить подлинность источника, нам нужно применить Hash Message Authentication Code (HMAC) к нашему процессу хеширования. Чтобы добавить аутентификацию источника во время процесса хеширования, добавляется HMAC. HMAC - это секретный ключ, который объединяет входное сообщение с алгоритмом хеширования, таким как MD5 или SHA-1, для создания уникального дайджеста. На следующем рисунке показано использование HMAC с функцией хеширования: Поскольку этот секретный ключ (HMAC) используется только отправителем и предполагаемым получателем, значение выходного дайджеста будет просто зависеть от фактического входного сообщения (данных) и секретного ключа, используемого для применения дополнительного уровня безопасности для аутентификации источника. Поскольку источник и место назначения будут единственными сторонами, которые знают секретный ключ (значение HMAC), атака MiTM не будет успешной с точки зрения нарушения целостности любых сообщений, которые проходят через сеть. На следующем скриншоте показан секретный ключ (HMAC), примененный к строке текста: Как показано на предыдущем рисунке, текстовая строка (сообщение) была объединена с секретным ключом и обработана с использованием алгоритма хеширования MD5 и SHA-1 для создания уникального дайджеста.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59