Что значит обеспечить аутентификацию в криптографии
Что такое Аутентификация: Методы и Элементы
Узнайте больше о том, для чего нужна аутентификация, и ознакомьтесь с её методами
Аутентификация (англ. authentication) — это основа безопасности любой системы, которая заключается в проверке подлинности данных о пользователе сервером.
Она не тождественна идентификации и авторизации. Эти три термина являются элементами защиты информации. Первая стадия — идентификация. На ней происходит распознавание информации о пользователе, например, логин и пароль. Вторая стадия — аутентификация. Это процесс проверки информации о пользователе. Третья стадия — авторизация. Здесь происходит проверка прав пользователя и определяется возможность доступа.
Содержание
Зачем нужна аутентификация
Аутентификация нужна для доступа к:
Элементы аутентификации
Методы аутентификации
Парольные
Самый распространенный метод. Аутентификация может проходить по одноразовым и многоразовым паролям. Многоразовый пароль задает пользователь, а система хранит его в базе данных. Он является одинаковым для каждой сессии. К ним относятся PIN-коды, слова, цифры, графические ключи. Одноразовые пароли — разные для каждой сессии. Это может быть SMS с кодом.
Комбинированные
Этот метод говорит сам за себя. Аутентификация происходит с использованием нескольких методов, например, парольных и криптографических сертификатов. Он требует специальное устройство для считывания информации.
Биометрические
Это самый дорогостоящий метод аутентификации. Он предотвращает утечку или кражу персональной информации. Проверка проходит по физиологическим характеристикам пользователя, например, по отпечатку пальца, сетчатке глаза, тембру голоса и даже ДНК.
Информация о пользователе
Она используется для восстановления логина или пароля и для двухэтапной аутентификации, чтобы обеспечить безопасность. К этому методу относится номер телефона, девичья фамилия матери, год рождения, дата регистрации, кличка питомца, место проживания.
Пользовательские данные
Этот метод основывается на геоданных о местоположении пользователя с использованием GPS, а также использует информацию о точках доступа беспроводной связи. Недостаток заключается в том, что с помощью прокси-серверов можно подменить данные.
Классификация видов аутентификации
В зависимости от количества используемых методов
В зависимости от политики безопасности систем и уровня доверия
Чтобы защитить владельца сайта от злоумышленников, используют криптографические протоколы аутентификации.
Типы протоколов обусловлены тем, где происходит аутентификация — на PC или в сети.
Аутентификация на PC
Аутентификация в сети
Ресурсы
Также искали с «Аутентификация»
Оценка: 4 / 5 (19)
Начните пользоваться сервисом SendPulse прямо сегодня
Если вам интересно, что такое «✅ Аутентификация: Определение, Методы, Виды», вам может быть интересен наш сервис рассылок.
Безопасная аутентификация между клиентом и сервером без ввода логина и пароля
Недавно, при разработке распределенного анализатор трафика, у меня появилась задача спроектировать систему аутентификации между клиентом и сервером. Причем необходимо было спроектировать систему для двух разных ситуаций:
В отличие от локальное сети, где для проведения атаки злоумышленнику каким-либо образом необходимо подсоединиться к ней (а если такой сетью управляют хорошие сисадмины, то это достаточно проблематично сделать), при взаимодействии клиента и сервера через незащищенную сеть нельзя быть уверенным, что никто не прослушивает трафик. Поэтому здесь требуется алгоритм аутентификации, отличающийся от алгоритма для взаимодействия в локальной сети.
Аутентификация на основе общего секретного ключа с использованием HMAC
Данный вид аутентификации подразумевает наличие у клиента и сервера некоего секретного ключа, который известен только им двоим. Мы такой ключ сгенерировали с помощью алгоритма Диффи-Хеллмана.
HMAC (сокращение от англ. hash-based message authentication code, хеш-код идентификации сообщений). То есть это механизм, который использует криптографические хеш-функции в сочетании с секретным ключом.
Последовательность аутентификации протокола выглядит следующим образом:
Nк, Nс — 128 битное число, выбранное случайным образом клиентом и сервером по отдельности;
К, С — идентификаторы клиента и сервера (например, IP адрес);
HMAC — хэш код идентификации сообщения;
Ks — общий секретный ключ.
На первом шаге клиент посылает случайно выбранное число серверу, чтобы он мог зашифровать его общим для них ключом, и тем самым подтвердить, что он на самом деле является сервером, а не злоумышленником, который притворяется им (хотя как мы увидим далее, в нашем примере это число не шифруется, а преобразуется вместе с другими данными в хэш, что не меняет сути процесса).
На втором шаге сервер отправляет клиенту случайное число Nс, а также хэш HMAC, образованный путем хэширования значений Nк, Nс, К, С и Кs при помощи HMAC-функции. Т.к. клиент знает Nк, Nс, К, С и Кs, то он может сформировать свой хэш HMAC, и сравнить его с пришедшим от сервера. Если хэши будут совпадать, то сервер является тем, за кого себя выдает. В тоже время злоумышленник не мог бы сформировать хэш HMAC( Nк, Nс, К, С, Кs), т.к. он как минимум не должен знать секретного ключа Ks.
На третьем шаге пришла очередь клиента подтвердить свою «личность». Процесс осуществляется по аналогии со вторым шагом.
Аутентификация с помощью шифрования открытого ключа
Данный вид аутентификации используется, когда и клиент, и сервер имеют сертификаты. Последовательность шагов данного вида аутентификации изображена ниже.
Nк, Nс — 128 битное число, выбранное случайным образом клиентом и сервером по отдельности;
К, С — идентификаторы клиента и сервера (например, IP адрес);
Ks — общий секретный ключ;
Ec, Eк — открытые ключи сервера и клиента соответственно, которые передаются в виде сертификатов.
Сначала клиент запрашивает открытый ключ сервера (Ес) у центра сертификации. Затем он шифрует с помощью него случайно выбранное число и свой идентификатор (шаг 3). Только настоящий сервер может расшифровать это сообщение. Поэтому сервер, получая данное сообщение, расшифровывает его, и шифрует с помощью открытого ключа клиента (который он получает у центра сертификации) случайное число клиента, свое случайное число, и общий секретный ключ (шаг 6). Далее, если клиент является тем, за кого себя выдает, расшифровывает сообщение сервера, узнает общий секретный ключ, и для подтверждения, что он смог расшифровать сообщение сервера, отсылает серверу случайно число Nc, зашифровав его общим секретным ключом (шаг 7).
При проектировании системы аутентификации, в отличии от стандартного протокола, предполагается, что клиенты не будут иметь свой сертификат, а будут отсылать свой открытый ключ серверу, зашифровав его предварительно открытым ключом сервера, полученного с помощью сертификата. Это позволит избежать необходимости получения множества сертификатов для каждого клиента, что повлекло бы необходимость пользователю этого клиента отвлекаться на его настройку, что противоречит ограничениям системы.
Дополнительная защита обеспечивается сменой общего секретного ключа (Ks) через случайный промежуток времени (Tk). Подробнее об этом написано в разделе «Анализ системы на защищенность от атак»
Алгоритм системы аутентификации
Далее все этапы установления соединения были описаны с помощью блок-схем.
Алгоритм системы аутентификации со стороны клиента выглядит следующим образом:
Со стороны сервера:
После успешной аутентификации можно передавать зашифрованный трафик. Предполагается, что трафик будит шифроваться с помощью алгоритма AES, используя секретный ключ Ks. Почему AES? Потому что это наилучший на сегодняшний день симметричный алгоритм шифрования. Подробнее о нем можно узнать в интернете.
Анализ системы на защищенность от атак
Далее я смоделировал различные ситуации, которые могут произойти, и проанализировал устойчивость системы к ним.
Уязвимость алгоритма Диффи-Хеллмана к MITM атакам
Это, пожалуй, главный недостаток данного алгоритма. Если допустить, что злоумышленник выдает себя за сервер клиенту, и за клиент серверу (например, используя ARP-spoofing), то весь трафик будит проходить через злоумышленника.
Защититься от такого рода атак можно только грамотно продумав сетевую архитектуру и правила ИБ предприятия. Например, можно установить ПО по обнаружению ARP-spoofinga и подобных атак.
Подключение клиентов к серверу без необходимости
Что может произойти, если кто-то получит клиент нашего анализатора?
С одной стороны, т.к. сервер не передает никакую важную информацию клиенту (только команды), а клиент в свою очередь никак не может получить доступ к важным данным сервера и только отсылает трафик, это не вызовет никаких серьезных неудобств.
Единственное, что может причинить неудобства, БД сервера может неприлично увеличиться, но это забота сервера и администратора отключать ненужные клиенты от работы сети (т.к. для заполнения БД требуется достаточно много времени).
С другой стороны, клиент может устроить DOS атаку, отсылая множество запросов на установление общего ключа, затем удаляя полученный ключ и отсылая новый запрос на получение секретного ключа.
Здесь можно просто напросто банить на время таких клиентов. Также клиент не может инициализировать обновление секретного ключа. Единственный, кто знает время действия общего секретного ключа — это сам сервер. И только он может посылать запрос на обновление общего секретного ключа.
Получение злоумышленником секретного ключа клиента и трафика этого клиента
В данной ситуации предполагается, что злоумышленник заполучил секретный ключ и трафик клиента.
m — сетевой пакет (сообщение), который шифруется секретным ключом.
Как говорилось ранее, установление общего секретного ключа между агентом и сервером в доверенной зоне происходит с помощью алгоритма Диффи-Хеллмана. В отличие от стандартного Диффи-Хеллмана, в моем случае предполагается смена общего ключа (Ks) через случайный промежуток времени, который лежит на интервале времени (Tmin, Tmax), где Tmin и Tmax устанавливаются в настройках серверной части приложения.
Данный способ позволяет частично обеспечить forward secrecy (секретность будущих сообщений) и backward secrecy (секретность прошлых сообщений). То есть если допустить, что находящийся внутри предприятия злоумышленник имеет записанный ранее трафик, и при этом ему удалось получить текущий общий секретный ключ Ks(i), он сможет расшифровать только такой трафик, который был передан на интервале (Tmin(i), Tmax(i)), где i — текущий номер сгенерированного общего секретного ключа.
Заключение
В данной статье было описано проектирование системы аутентификации на основе широко известных протоколов аутентификации. Было приведено краткое описание протокола аутентификации на основе общего секретного ключа с использованием HMAC, и протокола аутентификации с помощью шифрования с открытым ключом.
В конце был проведен краткий анализ подверженности спроектированной системы к компьютерным атакам.
Ликбез по основам безопасности и криптографии
Криптография
Три кита криптографии — хеш, шифрование симметричное, шифрование асимметричное (с открытым ключом). Основываются криптографические алгоритмы на сложности вычисления больших чисел, но подробнее об этом, если вас конкретно интересует «начинка», стоит читать не в общих обзорах, именуемых ликбезом. Здесь же содержится простое изложение, без лишних заморочек, то есть поверхностное.
Хеш — функция, функция «в одну сторону», так как восстановить данные, из которых путем хеширования получен хеш (результат хеш-функции), невозможно. На вход подается информация, на выходе имеем её отпечаток, строку фиксированной длины. Подобрать входные данные, которые дадут такой же результат должно быть сложной задачей. Отсюда следствие — если у вас есть проверенный хеш образа диска, документа и т.п., то вы можете вычислить хеш полученного файла и сравнить — если совпадут, значит это то самое. Подобным же образом обходятся зачастую с паролями — если хеш полученного пароля совпадет с имеющимся (в /etc/shadow к примеру), то проверка пройдена успешно.
Шифрование симметричное — шифрование в котором используется, соответственно, симметричный ключ. Это говорит о том, что если вы что то архиважное зашифровали один ключом, то обратную операцию надо проделать им же. Также может использоваться при проверке знания секрета — шифруем некую информацию этим самым секретом, или его хешем, передаем результат второй стороне. Вторая сторона, которая как предполагается знает секрет, расшифровывает данные, их дополняет, шифрует, пересылает обратно. Первая сторона, получив ответ опять же его расшифровывает и смотрит правильно ли вторая сторона изменила данные. Понятно, что если вторая или первая сторона подсовывает неверный секрет, процесс сорвется. Это было весьма общее описание процессов происходящих в протоколе Kerberos.
Шифрование асимметричное — шифрование в котором используются, два ключа, которые обычно называют приватный (секретный) и публичный (известен всем). Зашифровав что либо одним из пары ключей, обратно расшифровать можно только вторым. Таким образом проверить ваше знания приватного ключа достаточно просто — шифруем некую информацию вашим публичным ключом и, если вы знаете приватный, вы легко её прочитаете. На шифровании с асимметричными ключами построено много систем, к примеру это PGP и PKI. Также каждый из вас пользовался этим видом криптографии когда обращался на адреса вида https: //.
Аутентификация и авторизация
Аутентификация это процесс установления личности. Когда вы вводите пароль на Хабр, вы аутентифицируетесь. Никаких прав вы при этом не получаете.
Авторизация это процесс, в котором проверяются права пользователя на выполнение каких либо действий в системе. Например по умолчанию вы имеете право писать в личный блог, но система не даст вам опубликовать хабратопик в коллективный блог, если у вас будет мало кармы. Здесь авторизация на совершение какого либо действия производится по количеству кармы, в файловых системах вам выдают право на совершение действий через ACL, членство в группе и так далее.
Еще раз — через процесс аутентификации получить право на выполнение чего либо нельзя, этим занимается процесс авторизации, а аутентификация только устанавливает личность.
Аутентификация, немного о криптографической стороне дела
Зачастую аутентификация основывается на проверке знания секрета. Самый простой способ это получить от вас пароль в чистом виде (!) и сравнить с хранящимся в базе. Тут есть вариант — проверять хеш пароля, что позволит не знать пароль серверу, а хранить его хеш. Но заметьте — пароль проходит в открытом виде по сети! Второе — вы не знаете кому отправили свой пароль, сервер может быть подставным. Обходной маневр — использовать только в связке с SSL/TLS, но в таком случае у сервера должен быть корректный, не просроченный сертификат, выданный доверенным центром, а не как обычно.
Второй вариант — сервер знает секрет, вы его знаете — используется метод, описанный в абзаце по симметричному шифрованию. Это лучше чем сравнение с запомненным хешем — пароль по сети не бегает вообще, сервер так же не получает ваш секрет — вы проводите с сервером взаимную аутентификацию. На этом методе вырос весьма серьезный протокол — Kerberos, с одним нюансом — пароли знают только выделенные сервера в сети. Kerberos используется в Microsoft Active Directory, в качестве примера привожу как самый известный продукт — все таки у нас ликбез.
Третий вариант, сложный, PKI. За рамки ликбеза его описание выходит, интересно — почитайте сами. По сути схож с Kerberos — есть центр, но основан на асимметричном шифровании.
Kerberos
Алгоритм описан с некоторыми отступлениями, для улучшения восприятия. Если вам потребуется точное описание работы, не для общего сведения, советую почитать более серьезную литературу
Каждый день, работники корпоративного сектора активнейшим образом используют квинтэссенцию криптографической мысли — протокол Kerberos, бороздя просторы корпоративной же сети построенной на базе решений от Microsoft, ведь все процессы идентификации пользователей и компьютеров сервисами (IMAP,SMTP, доступ к файлам) он берет на свои плечи.
Протокол Kerberos это протокол аутентификации использующий хеш-функции и симметричные шифры. Как ни удивительно, но Kerberos это не очередное порождения Microsoft в стремлении «чтобы свое, и чтобы ни с чем не совместимо, и чтобы они нам душу отдали за спецификации», создан протокол в стенах массачусетского технологического института — MIT, где активно используется все эти годы в кампусной сети ВУЗа.
Перечитайте описание симметричных шифров, в конце там есть пример. Так вот в чем недостаток решения, предложенного в том абзаце? А получается, что пароли надо размещать на каждом сервере сети, да еще каждой службе надо будет иметь к ним доступ, к незашифрованым паролям, да еще на каждый сервер эти пароли надо внести. Выглядит это несколько дыряво.
В протоколе Kerberos для хранения паролей выделен отдельный сервер — Key Distribution Center (сервер распределения ключей), ключи есть у каждого участника процесса — и у пользователей и у сервисов. Ключ получается из пароля путем хеширования, так как пользователь не сможет запомнить требуемое для алгоритма шифрования количество символов. Хеширование возвращает всегда строку фиксированной длины, что как раз подходит для алгоритмов шифрования с симметричным ключом.
Когда пользователю надо получить доступ к HTTP серверу (портал там лежит корпоративный, к примеру), он обращается к KDC (ну понятно, что обращается библиотека) с просьбой предоставить ключ для доступа к HTTP серверу. У KDC есть ключи пользователя и сервера
KDC генерирует случайный, симметричный ключ и делает достаточно сложную конструкцию, называемую билетом, которую лучше посмотреть на картинке:
Итак, имеем матрешку, но разбирается она достаточно просто. Пользователь, получив ответ, расшифровывает его свои ключом, получает сгенерированный ключ и шифрованный ключом сервера пакет. Так вот этот пакет пользователь отсылает уже HTTP серверу, который расшифровывает его и тоже получает тот же самый сгенерированный ключ.
Теперь у обоих есть общий ключ. И вот теперь можно аутентифицировать друг друга, способ уже описан — шифруем полученным от KDC, сгенерированным ключом имя пользователя, IP адрес, время и отсылаем серверу. Сервер расшифровывает, и получив ожидаемое имя пользователя признает в нем Пупкина. Теперь очередь сервера представиться — он прибавляет к полученному времени 1 (единицу) и, зашифровав все обратно, отсылает пакет пользователю. Ясно, что если в полученном пакете, после дешифрации будет обнаружена та же временная метка, которую пользователь отсылал, но увеличенная на единицу, то сервер признается подлинным.
А вот про время я упомянул не зря. Доступ выдается на определенное время (часто на 10 часов), время проставляется в билете, и по истечении срока действия билет считается просроченным — сервер больше такой билет не примет, что впрочем не смертельно — получите новый. Гораздо печальнее будет, если время на вашем ПК разойдется более чем на 5 минут с KDC — войти в систему не сможете, так как протокол Kerberos требует от участников процесса синхронного времени — чтобы билеты истекали на всех машинах сети одновременно, и не было возможности использовать просроченный билет для доступа куда либо.
Итак, билет действует 10 часов, не требуя больше ввода пароля, для обращения к серверу. Но ведь так утомительно вводить пароль на каждый сервер в сети, тем более, что вы могли заметить — никто так не делает, после одного ввода пароля при логине в Windows вы больше не вводите пароли на доступ к расшареным сетевым папкам. А все от того, что получать билеты ведь тоже можно по билету! Подобная конструкция называется TGT — билет для получения билетов. Тут все так же как и было показано, получаем билет на доступ к сетевой службе, выдающей билеты (TGS — Ticket-Granting Service), которая признает Пупкина Пупкиным. А раз Пупкин это Пупкин, то можно ему выдавать билеты на Пупкина для доступа к различным серверам сети.
Таким образом, в течении действия TGT вы можете получать билеты на доступ к сетевым службам без повторного ввода пароля. Удобно работает, правда?
Заметьте, что Kerberos выдает билеты на доступ к любой службе сети, есть ли у вас право ей пользоваться или нет, протоколу аутентификации безразлично — его дело удостоверить вашу личность, а правами занимаются совсем другие механизмы.
Криптографические методы защиты информации
7 Лекция. Аутентификация. Криптографические методы аутентификации.
Аутентификация
Аутентификация (Authentication) — проверка принадлежности субъекту доступа по предъявленному им идентификатору (пароль, ключ и т.д.); подтверждение подлинности.
Рис. Методы аутентификации
Аутентификация по многоразовым паролям
Используется один пароль многократно.
Хотя аутентификация может использоваться не только к удаленным системам, методы аутентификации будем рассматривать сразу на примерах к удаленным системам
Протоколы аутентификации
PAP (Password Authentication Protocol)
Недостатки и пути решения:
Решение проблемы «подбора паролей» :
Почему эти пароли плохие:
Наиболее хорошим вариантом являются пароли построенные на фразах:
Рис. Хорошие пароли
Решение проблемы «просмотра паролей в системе» :
Рис. Пароли не хранятся в системе, а хранятся их хэши
Пароли в системе не хранятся, при этом пользователь проходит аутентификацию по паролю.
В большинстве современных систем именно так и сделано. Не только в ОС, но и в СУБД, форумах, сайтах и т.д.
Решение проблемы «перехвата паролей при передачи»:
Рис. Шифрование передаваемых паролей
В настоящее время чаще всего для шифрования паролей используется протокол SSL ( Secure Sockets Layer — уровень защищённых сокетов, http://ru.wikipedia.org/wiki/SSL).
Протоколы аутенти фикации вызов-ответ
CHAP (Challenge Handshake Authentication Protocol)
Основан на вычислении имитовставки по алгоритму HMAC, роль симметричного ключа выполняет пароль.
Рис. Протокол CRAM
В CRAM вместо пароля на сервере может хранится хэш.
Digest access authentication (DIGEST-MD5)
Схема аналогичная CHAP.
HA1 = MD5( «Mufasa:testrealm@host.com:Circle Of Life» )
= 939e7578ed9e3c518a452acee763bce9
HA2 = MD5( «GET:/dir/index.html» ) = 39aff3a2bab6126f332b942af96d3366
Response = MD5( «939e7578ed9e3c518a452acee763bce9:\
dcd98b7102dd2f0e8b11d0f600bfb0c093:\
00000001:0a4f113b:auth:\
39aff3a2bab6126f332b942af96d3366″ )
Взаимная аутентификация
Т.к. сервер может быть ложным, необходимо провести взаимную аутентификацию.
Рис. Протокол взаимной аутентификации
Аутентификация по одноразовым паролям (One-time password)
Различные подходы к созданию одноразовых паролей:
Одноразовые пароли клиент может получать:
Рис. пример банковской карты
Многофакторная аутентификация
Иногда используются сразу несколько методов аутентификации.
Например: электронный ключ и логин.
При использовании SIM-карт в мобильных телефонах. Субъект вставляет свою SIM-карту в телефон и при включении вводит свой PIN-код (пароль).
В случае банковской карты. Субъект вставляет свою банковскую карту в банкомат и вводит свой PIN-код (пароль).