Загадочное слово — идентификация! Как можно сказать проще? Например, представление. В цифровом мире каждый субъект, будь то человек, машина или устройство должен назвать себя — указать, кто он такой, зачем пришел в инфраструктуру и хочет работать с ресурсами.
Идентификатор (англ. identifier — опознаватель) — уникальный код или номер, присвоенный объекту в определенной системе и далее применяемый для идентификации этого объекта (человека, машины, устройства или даже файла). Он обычно создается автоматически при появлении нового фигуранта информационной инфраструктуры. Однако в некоторых случаях может быть задан вручную.
Чаще всего идентификаторы состоят из набора символов и цифр. Они всегда являются уникальными для конкретных систем или приложений. Это важное требование контролируется специальными механизмами определения уникальности. Примеры идентификаторов: RA87756, K_700005648764, 564875#675 и т.п.
С аналогичными ограничениями на максимально допустимую длину и набор символов могут столкнуться и идентификаторы, что вызывает сложности в их использовании. Например, ограничения по длине могут приводить к совпадению для разных объектов системы, поэтому приходится предпринимать многократные попытки выбрать наименование.
Помните, что учетные данные должны быть не только уникальными, но и легко запоминаемыми для вас. Рекомендуем внести информацию о них в надежное специализированное хранилище или в другое недоступное для общей публики поле.
Требования могут незначительно отличаться в зависимости от конкретной системы, веб-сайта или приложения. Несколько общих правил, которые важно соблюдать:
2. Допустимые символы. Имя может содержать только определенные знаки. Обычно разрешены буквы (как заглавные, так и строчные), цифры и некоторые специальные символы — подчеркивание (_) или дефис (-). Обязательно обращайте внимание на требования разных систем, поскольку очень легко запутаться.
4. Исключение специальных символов. Чтобы предотвратить возможные проблемы с безопасностью или технические сложности, некоторые системы исключают использование определенных знаков. Например, иногда запрещаются символы, которые фигурируют в кодировании URL.
Это общие требования, которые могут варьироваться в зависимости от системы или платформы. При создании рекомендуется следовать указаниям, предоставляемым при регистрации на конкретном веб-сайте, программе или приложении.
Для аутентификации может быть использован пароль — набор символов, который вводит пользователь для подтверждения своей легитимности. Первоначально код может быть задан вручную или сгенерирован в автоматическом режиме системой. После стартового входа его рекомендуется сменить.
Каждый пользователь должен знать, зачем создавать надежный пароль и какую роль он играет. Неосведомленность ведет к неминуемым рискам кибератак и утечке данных.
Примеры компрометации учетных данных:
Кража учетных данных
Безусловно, борьба с кражей учетных сведений должна быть приоритетной задачей для служб безопасности. Нелегитимное использование украденных данных привилегированных пользователей, обладающих расширенными правами, может привести к катастрофическом последствиям для компании любого масштаба.
Учетные данные могут быть получены из хранящихся в файлах хэшей. Злоумышленники научились восстанавливать пароли из хэшированных функций, если не применяются сложные современные алгоритмы, например, с добавлением соли (модификаторов входа).
Также для получения учетных данных используют социальную инженерию, например, фишинг, поскольку это не очень дорого и эффективно. К тому же, происходит взаимодействие с людьми, а их очень часто удается поймать на обман. Злоумышленники, нацеленные на кражу корпоративных учетных данных, часто используют социальные сети для получения контактной информации о сотрудниках компании. Далее в ход идут фишинговые письма — послания, имитирующие реальные корпоративные сообщения или приложения. Они детально разработаны, поэтому становятся неплохим инструментом в руках мошенников.
Также учетные данные можно угадать или подобрать случайным образом. А еще они часто становятся рассекречены в результате утечки информации.
2. Имена и фамилии. Такие данные опасно использовать, поскольку они известны многим людям. Тем более, что распространенные имена и фамилии часто совпадают с другими пользователями.
4. Общие распространенные слова. При создании наименований не вдохновляйтесь словарями. И тем более не делайте выбор в пользу банальных «password», «welcome», «123456». Это небезопасно — киберпреступники могут получить информацию путем словарных атак и легко подобрать ключ к вашему личному кабинету.
7. Символы и символьные комбинации. Их часто включают в учетные записи, но можно использовать далеко не все. Требования зависят от конкретной системы, потому обязательно убедитесь, что не нарушаете правила. Использование нежелательных символов неминуемо провоцирует проблемы с безопасностью или технические сложности.
Пример надежного login и password
Важно знать, как создать хороший пароль. В этом примере использованы следующие принципы:
4. В пароле фигурируют различные типы символов: знаки, цифры, буквы. Они удачно скомбинированы относительно друг друга, поэтому код считается устойчивым к взлому и надежным.
Важно помнить, что это всего лишь пример. По факту информационная безопасность зависит от многих факторов. Поэтому обязательно внедрите дополнительные меры защиты, например, двухфакторную аутентификацию.
Не забывайте про регулярное обновление паролей. Постарайтесь использовать для каждой учетной записи свой уникальный код. Когда везде один и тот же пароль, злоумышленникам намного проще добраться до личных кабинетов в разных системах.
Способы защиты учетных данных
Одним из перспективных и новых методов обеспечения кибербезопасности (в том числе защиты учетных данных) является непрерывная аутентификация. Это метод проверки подлинности пользователя, который проводится не один раз при подключении к ресурсу, а на протяжении всего сеанса работы.
Непрерывная аутентификация базируется на проверке личности без прерывания рабочего процесса и реализуется с использованием машинного обучения. Она включает множество факторов, в том числе поведенческие модели и биометрические данные.
Непрерывная аутентификация востребована там, где требуются повышенные меры безопасности. Например, при работе с конфиденциальной и критически важной для бизнеса информацией.
Как работает непрерывная аутентификация
Чтобы получить корректные результаты проверки, необходимо постоянно собирать информацию о действиях пользователя и создавать определенные шаблоны его обычного поведения. Это позволит впоследствии выявлять различные несостыковки. Если будет наблюдаться аномальное поведение, система отреагирует дополнительными проверками личности.
На основе анализа поведения пользователя может быть предоставлен или продлен доступ к системе или приложению. Если выявится компрометация, сеанс работы немедленно прервется.
Помимо поведения юзера исследуются и его физиологические характеристики. Например, черты лица, сила нажатия на клавиши, положение глаз, размер зрачка, частота моргания и другие признаки пользователя. В совокупности с действиями физиологические характеристики дают системе понимание, кто именно в данный момент участвует в сеансе.
В рамках непрерывной аутентификации существуют разные технологии:
Возможности и ограничения непрерывной аутентификации
Пример инцидента — сотрудник отвлекся, отошел от рабочего места, оставив сеанс работы с системой незавершенным. В этот момент доступом воспользовался другой работник, похитив информацию в корыстных целях или внеся несанкционированные изменения. Также внезапно может произойти фишинговая атака, повлекшая утечку учетных данных.
Непрерывная аутентификации находится только на пути развития и внедрения. Пока такая технология возможна для отдельных систем и приложений. К сожалению, комплексно она пока не используется.
Кроме того, остро стоят вопросы этического и юридического характера, поскольку не каждый работник захочет находиться под постоянным контролем. Пока нет четких нормативных требований, которые бы регулировали данный аспект.
Сам инструмент надежно защищен с помощью мастер-пароля, который используется для доступа к менеджеру. Некоторые продвинутые механизмы также предусматривают дополнительную защиту в виде двухфакторной аутентификации. Такие программы на данный момент считаются самыми безопасными и востребованными.
Менеджеры паролей бывают различных типов:
Удобные инструменты, которые позволяют исполнять парольную политику компании
Многие решения по управлению доступом включают механизмы, взаимодействующие с паролями. Например, Solar inRights обладает специальным модулем, отвечающим за исполнение парольной политики компании. Удобство в том, что все подключенные к решению системы могут подчиняться единым централизованным требованиям. При необходимости разрешено ввести исключение по некоторым системам и приложениям.
Solar inRights включает очень широкий набор параметров по управлению парольной политикой. Все инструменты отвечают высоким стандартам безопасности и могут варьироваться в зависимости от требований и стандартов организации.
Если речь идет о привилегированном доступе, то такая система, как Solar SafeInspect решает вопросы по управлению паролями для привилегированных учетных записей. Подстановка данных позволяет держать сведения в секрете не только от третьих лиц, но и даже от самих привилегированных пользователей, например администраторов.
Сотрудники входят в систему под обычной социальной учеткой и используют свой пароль, а далее система автоматически подставляет данные для доступной привилегированной учетной записи. Все это происходит на основании введенных в систему требований.
Такой механизм позволяет защитить учетные данные от атак злоумышленников. Кроме того, есть возможность настроить любую необходимую периодичность автоматической смены пароля привилегированной учетной записи, вплоть до манипуляций после каждого сеанса работы.
Все учетные данные привилегированных пользователей базируются в специальном зашифрованном хранилище системы Solar SafeInspect. Это также позволяет повысить возможности безопасной работы с критически важными ресурсами компании.
Как придумать надежный пароль и логин?
Пароли, пароли, пароли – в Интернете они нужны повсюду. Каждый раз приходится думать, какой поставить пароль, чтобы его не смогли взломать. Итак, какой должен быть пароль?
Признаки надежного пароля
Старайтесь периодически обновлять и использовать разные пароли на всех сайтах и форумах.
Как придумать сложный пароль?
Есть несколько эффективных способов придумать надежный пароль:
Сложновато? Зато пароль, который Вы придумаете таким способом, будет надежным.
Если придумать пароль не получается, воспользуйтесь генераторами паролей:
Как придумать логин
Полезные статьи по теме:
Приветствую, друзья! В прошлой статье я предлагал на обсуждение какой-то бред, за который теперь стыдно черновик нового протокола аутентификации на сайтах. И хотя сейчас я значительно его переработал (с учетом ваших замечаний) и готовлю новую версию, я решил что стоит предварительно опубликовать несколько статей, которые будут раскрывать мотивы технических решений, закладываемых в новый протокол. А эта статья посвящается проблемам и техникам безопасной передачи и хранения сайтами ваших паролей.
Я приведу несколько реально используемых схем на практике. Буду приводить схемы авторизации в порядке от простого к сложному, показывая их преимущества и недостатки и обосновывая выбранные технические решения.
Теперь кратко о себе: Я опасно некомпетентен в криптографии. Это всё, что вы должны обо мне знать.
Я думаю, любой здесь web-разработчик, что со стороны front-, что со стороны back-, хотя бы раз реализовывал механизм парольной аутентификации на одном из своих проектов.
скажите, вашего сына и правда зовут «Вася, брось таблицу»?
TLS спасет мир
С тех пор много воды утекло. Разработчики стали опытнее, а взломщики – изворотливее. Массовое распространение получил HTTPS. Сейчас он продавливается так агрессивно, что кажется, будто вскоре вообще не окажется веб-приложений, не охваченных им. Правда это только кажется.
Ну а раз так, то зачем изобретать велосипеды? Передаем пароль как есть, и все дела. А о безопасности позаботится нижележащий слой TLS. Зря его что ли придумывали?
Вы можете не соглашаться, но факт есть факт: массовые утечки нехешированных паролей даже с крупных сайтов случаются. Точнее: именно благодаря таким утечкам мы и узнаем, что крупный сайт даже не удосужился захешировать наши пароли.
Кстати, почему только сайты. Многие аппаратные устройства хранят пароли в открытом виде.
Кто же может покушаться на процесс авторизации? Концептуально таких злоумышленников три класса:
Мы будем далее рассматривать только классы 1 и 2. Что касается атакующего на клиенте – то у него гораздо больше возможностей, чем у первых двух. И защититься от него в рамках нашей статьи не получится вовсе.
Также, давайте пока не будем обращать своё внимание на повсеместное распространение https. К нему много вопросов. И это тема отдельной статьи. Будем полагать, чего его нет вовсе. Тем более, что такое вполне может быть.
Хешируем
Ну хорошо. Попробуем усилить элементарную схему. Первое, что приходит на ум: будем передавать не пароль P, а его хэш H. И сервер будет хранить не исходный пароль, а его хеш. Теперь исходный пароль пользователей не сможет узнать ни MitM, ни взломщик БД. Кроме того, в качестве бонуса, даем возможность пользователю использовать пароль любой длины и из любых символов. Всё равно всё свернется в короткий хэш. А значит, поле для хранения пароля в БД можно сделать фиксированной длины, а не varchar().
Для надежности, возьмём в качестве хеширующей функции SHA2 или SHA3. 256-битов на текущий момент вполне достаточно. Но если хотите – обе функции поддерживают режим 512 бит. Хотя признаться, такое количество бит потребует сделать в БД поле размером в 64 байта!
Хорошо. Вот только злоумышленнику MitM не нужно уже знать пароль – ему достаточно узнать его хэш. Мало того, если пользователь использует такой же пароль на другом сайте, и тот сайт использует подобную «защиту», то MitM и там может «поживиться» (ему уже не обязательно взламывать канал, достаточно зайти «легально»).
Значит такая схема не лучше первой. Что ж. Усиливаем дальше.
Солим
В терминах криптографии, «соль» – это последовательность случайных бит, которые добавляются к хэшируемой (или шифруемой) последовательности для «рандомизации» результата. Добавляя соли к паролям при хешировании, мы будем получать разные хэши для одинаковых паролей. Ну при условии, конечно же, что соль используется разная:
Также заметим, что соль хоть и разная для разных пользователей, но не меняется со временем. А значит, злоумышленник MitM перехвативший однажды hash(password, salt), может использовать это значение для легального входа от имени жертвы. Тоже самое сможет сделать и взломщик БД.
Scrypt’им
В принципе, описанная выше схема уже надежна в некоторой степени. И уж более надежна чем предыдущие. Но тут есть одна засада.
Производительность компьютеров растет. И хотя закон Мура давно как не действует (по слухам, с 2006 года), и рост уже не экспоненциальный, на «плато» мы ещё не вышли. То что ранее считалось невозможным, теперь доступно многим. Например, аренда на время вычислительных кластеров с фантастической мощностью. Специализированных кластеров, заметим. Наточенных на число-дробильные операции, включая вычисление хешей. Спасибо за это криптовалютам.
количество хешей, которое обсчитывается в сети Bitcoin каждые три секунды, достаточно, чтобы найти коллизию для SHA-1. Источник.
Теперь взломщик БД может попытаться восстановить пароли интересующих его учетных записей, даже если они захешированы с солью (все восстанавливать нет смысла и не хватит времени).
Как? В начале по таблице известных паролей: синтетических qwerty, популярных 123 и когда-то угнанных реальных. Затем, путём тупого перебора символов из заданного алфавита. Алгоритм концептуально прост: берем пароль-кандидат, вычисляем hash( password, salt ), сравниваем результат. Соль учетной записи известна, ибо хранится рядом с хешем пароля.
На нашу беду, процесс перебора хорошо параллелится. А значит, в теории рост производительности не ограничен (правда только в теории; практика – вещь куда более суровая).
Вот для примера расчетыПредставим, что злоумышленник имеет специализированный кластер, способный вычислять наши хеши из пароля со скоростью 10^12 вариантов в секунду. Тогда для взлома ему потребуется 70^8 / 10^12 = ~576 сек. Т.е. ваш пароль будет гарантировано подобран за ~10 минут. А в среднем такой системе будет достаточно потратить лишь 5 минут на подбор пароля от известного токена. 10-символьный пароль потребует уже в среднем 15 суток. Но повысив производительность системы в 10 раз, мы сократим это время до 1-2 суток. А такая производительность теперь есть и легко доступна благодаря облачным сервисам, распределенным вычислениям и всего того наследия майнинговых фрем.
Этой проблемой озадачились уже достаточно давно. И в результате усилий криптографов, на свет появилась такая функция как scrypt.
Функция scrypt делает почти тоже самое, что и хэш-функция (на самом деле использует в качестве базы SHA2-256), но создана таким образом, чтобы усложнить атаку перебором при помощи ПЛИС: FPGA, ASIC и подобных. Она заставляет использовать в алгоритме много циклов и ветвлений (чего суперскаллярные процессоры крайне не любят), к тому же, требует слишком много памяти на одно ядро.
Поэтому, вместо стандартной хеширующей функции, мы будем использовать scrypt. WebCryptApi пока её не поддерживает, но для javascript-разработчиков есть уже реализованные библиотеки. В остальном схема взаимодействия пока остается прежней. И вроде бы, надежной.
Но защитит ли она от пассивного MitM? Нет. Ибо мы всё ещё посылаем на сервер всегда один и тот же хеш. А значит, перехватив передачу итогового хеша на сервер, злоумышленник может в последствии легально его использовать для входа под чужой учеткой.
Некоторые скажут, что MitM вообще можно было бы исключить из рассмотрения, ибо скоро нагрянет HTTPS. Но к этому протоколу большие вопросы. Использование https можно обойти и организационно. А надежность TLS – тема отдельной статьи. Да и к тому же, проектировать какие-либо защитные механизмы, надеясь на работу других средств безопасности, – наивно. Практика показывает, что более чем наивно.
Добавляем challenge
Ну хорошо. Давайте усложним жизнь и для MitM. Попытаемся добиться того, чтобы хеш от пароля на сервер передавался всегда разным. Как? А давайте «посолим» уже сам хэш! Тот самый, что нам дает функция scrypt( password, salt ). Для этого сервер сгенерирует и пошлет клиенту случайную последовательность байт (длина которой равна длине блока хеширующей функции), которую мы (по традиции) назовем challenge. Теперь схема взаимодействия клиента и сервера такова:
Разработчик этой схемы должен не забывать очищать на своей стороне challenge, который он использовал «только что», не давая вероятному MitM повторить вход пользователя «по горячим следам».
Теперь MitM точно не сможет узнать передаваемый хеш. Ну если только мы честно генерируем действительно случайный challenge, всегда разный для каждой аутентификации. Что касается взломщика БД: он всё ещё может воспользоваться угнанными хешами для авторизации под чужими учётками. Но только на этом сайте. Впрочем, за него мы «возьмёмся» позже.
Обоюдный challenge
Казалось бы где тут подвох? Да почти нигде. Вот только, что если наш злоумышленник MitM вклинится в момент аутентификации и поменяет challenge от сервера на более простой (например – все нулевые биты, или вообще пустой)? Зачем? А чтобы попытаться облегчить себе задачу обратного восстановления H из Hs.
Защититься от такой потенциальной атаки можно, если клиент будет генерировать свой challenge и использовать его для хеширования пароля. Теперь на шаге 2, клиент вычисляет Hs = hash(H,server-challenge,client-challenge) и отправляет Hs вместе со своей версией challenge. Как результат, даже если сервер или клиент (или кто-то другой за них) случайно или намеренно решит поменять challenge на более примитивный, это не снизит уровень защиты исходного H, который, в свою очередь, защищает пароль.
Финальный штрих
Некоторые, возможно, уже заметили, что даже такая усложненная схема авторизации не защищает нас от взломщика БД. Последний может использовать компрометированные хеши пользователей и соли для легального входа от имени пользователей. Можно ли как-то от этого защититься?
Можно. И даже более того. Фактически мы можем сделать так, что угон аутентификационных данных пользователей будет бессмысленным. Компрометация этих сведений не принесет взломщику ничего (ну правда, он может «поживиться» куда более ценными сведениями; например данными сохраненных кредитных карт и cvc-кодами для них; но мы ведь защищаем процессы авторизации, а не проектируем PCI DSS).
Чтобы защититься от компрометации на стороне сервера, клиенту необходимо иметь некий секрет и алгоритм доказательства серверу, что клиент знает этот секрет. Тут на ум сразу же приходит криптография на ассиметричных ключах. Попробуем вначале обойтись хешированием или симметричными шифрами. И посмотрим как это можно реализовать.
КРАЙНЕ ВАЖНОЕ ЗАМЕЧАНИЕ: если вдруг кому-то покажется интересной какая-то из двух рассмотренных далее схем, ни в коем случае не спешите внедрять. Внимательно изучите сравнительную таблицу недостатков и уязвимостей. Опять же, не забывайте про опасность использования «учебных» криптопротоколов. Я предупредил.
А Схема защиты на симметричных ключах
Пусть H – это тот самый хеш клиента, по которому сервер его аутентифицирует. H хранится на сервере. H может быть потенциально стать доступным взломщику БД.
Пусть клиент имеет некий ключ K, которым он зашифровывает свой исходный аутентификационный хеш H: V = EK(H), где E – функция шифрования на ключе K. Итоговый шифр V вместе с H сервер хранит в своей БД. Если алгоритм шифра выбран надежный, то из пары (V, H) восстановить исходный ключ почти невозможно.
Теперь в процессе аутентификации нам остается передать защищенным образом пару (H, V) серверу. Тот сверит H, расшифрует V и убедится, что мы действительно знаем ключ К, а не украли H при взломе БД.
Это был концепт. Теперь конкретика.
Определим функцию hmac как функцию HMAC-SHA2-256. Salt и challenge должны быть равны длине блока хеширующей функции. В нашем случае – 256 бит. Определим функцию E – как функцию шифрования, а функцию D – как функцию расшифровывания на базе симметричного шифра AES-256. Наконец, определим функцию scrypt, как функцию, возвращающую 256-битный хеш от пароля и его соли.
На стороне клиента производятся предварительные вычисления:
При регистрации клиент посылает серверу пару (H, V) в открытом виде. Заметим, что сервер не знает ни исходный пароль пользователя, ни его первичный хеш Hp.
Алгоритм авторизации клиента теперь такой:
Не смотрите косо на операцию XOR (^) при вычислении Kv. Если challenge сформирован действительно случайным образом (а для гарантии этого его генерируют обе стороны взаимодействия) KS не поможет криптоаналитику восстановить K из множества пар (Kv, KS). Подобная методика используется в AEAD-схеме Chiphertext translation.
Если взломщик БД получит доступ к аутентификационным сведениям пользователей (login, salt, H, V), то у него нет никакого шанса восстановить недостающие данные об password и K. Мало того, воспользоваться полученными сведениями для осуществления «легального» входа от имени жертвы злоумышленник тоже не сможет. Число Kv, которое помогло бы злоумышленнику восстановить K, доступно только в момент аутентификации. Поэтому, чтобы взломать эту схему окончательно злоумышленник должен взломать БД и перехватить все процессы аутентификации.
Такое вполне может быть. Например, если взломщик – это сотрудник/владелец ЦОД. Вот тут нас может выручить уже криптография на ассиметричных ключах.
Схема авторизации на ассиметричных ключах и эллиптических кривых
Пусть в процессе аутентификации клиент подпишет случайную строку message своим закрытым ключом e. А сервер проверит подпись клиента, зная его открытый ключ D. Но если клиент может таким образом доказать, что ключ D принадлежит ему, и только ему, то нам уже не нужно «заморачиваться» с хранением хэша от пароля!
Возьмём, например, эллиптическую кривую spec256k1 группы SECG («Standards for Efficient Cryptography Group», основанной Certicom). Она же используется в Bitcoin.
Параметры этой кривойp = 0xffffffff ffffffff ffffffff ffffffff ffffffff ffffffff fffffffe fffffc2fa = 0, b = 7, h = 1Gx = 0x79be667e f9dcbbac 55a06295 ce870b07 029bfcdb 2dce28d9 59f2815b 16f81798Gy = 0x483ada77 26a3c465 5da4fbfc 0e1108a8 fd17b448 a6855419 9c47d08f fb10d4b8n = 0xffffffff ffffffff ffffffff fffffffe baaedce6 af48a03b bfd25e8c d0364141где, p – простое, задающее размер конечного поля; a и b – коэффициенты уравнения эллиптической кривой y2=x3+ax2+b; h – кофактор подгруппы; (GX, GY) – декартовы координаты базовой точки G, генерирующей подгруппу; n – порядок подгруппы (определяет размер ключей и подписываемых данных).
Т.к. порядок подгруппы n этой кривой почти 128-битный, открытый и закрытый ключи, а также message будут 128-битными. Для формирования хешей по прежнему используем 256-битные SHA2 или SHA3.
Этап регистрации пароля пользователя в системе
Эта же операция производится и при смене пароля пользователем. Но можно менять не пароль, а соль. Пароль также может быть установлен администратором системы. Здесь проблем нет.
Этап аутентификации пользователя в системе
Подробности реализации функции Fe(message)Здесь e – секретный ключ клиента.Клиент генерирует случайное натуральное , где n – порядок подгруппы;Вычисляет точку P = kG (где G – базовая точка подгруппы);Вычисляет r = Px mod n, где Px – x-координата точки P; если r = 0, возвращаемся к п. 1;Вычисляет s = k-1(message + re), где e – закрытый ключ клиента, а k-1 – мультипликативная инверсия k по модулю n. Если s = 0, то возвращаемся к п. 1.Пара чисел (r, s) образует подпись.Подробности реализации функции Fd(r, s, message)Здесь D – открытый ключ.Сервер вычисляет u1=s-1message (mod n);Сервер вычисляет u2=s-1 r (mod n);Сервер вычисляет точку P=u1G + u2D.
Предлагаемая схема может быть применена не только в Web/HTTP, но и в других протоколах: SMTP/IMAP/POP3, SOAP, SNMP. Правда потребует принятия соответствующих под-стандартов. Эта же схема может быть применена для парольной авторизации любых ваших приложений, построенных на архитектуре клиент-сервер. Как пример, клиентский агент администрирования антивируса и консоль управления агентами.
Но уязвимость этого алгоритма в том, что клиент может повторно использовать ранее выбранное k или использовать слабый генератор случайных чисел. И если наш MitM умудрится перехватить две подписи от клиента, с одинаковым k, то он сможет определить закрытый ключ!
В вероятность этого стремится к нулю по многим причинам. Но даже, если такое произошло, смена salt пользователя мигом решит проблему. Фактически вместо классической смены пароля пользователя тут можно предложить обновление его salt и, как следствие, открытого ключа. На мой взгляд, очень удобно. Сравните с классической схемой, когда при взломе сайта, вы вынуждены (не по вашей вине) менять свой пароль. Другое дело, когда у вас лично увели пароль (клавиатурным шпионом). Но тут, как говорится, «против лома нет приёма».
Ложка дёгтя в бочке мёда.
Известно также, что существуют классы эллиптических кривых, которые являются слабыми. Однако на сегодняшний день не известно методик, которые бы однозначно могли оценить надёжность кривых. А вот методики, которые позволяют генерировать слабые кривые, замаскированные под сильные, есть. Поэтому всегда остается вероятность, что выбранный вами для предложенной схемы класс эллиптических кривых, уязвим к атакующему «по середине».
Обнадёживает тут только то, что даже если эллиптическая кривая «подведёт», пароль пользователя всё ещё находится под надёжной защитой благодаря scrypt и hmac.
Схема на базе протокола SRP
Для реализации схемы нам понадобятся: большое простое число N, генератор g мультипликативной группы Z*N и параметр k = hash(N, g). В качестве g и N стороны используют числа, определенные в RFC-5054. Так, например, g = 2, а «мультипликативная группа» – это просто степени двойки; точнее их остатки по модулю N.
Процесс регистрации пользователя в системе:
Процесс авторизации пользователя в системе:
Согласно спецификации, пользователь должен прервать аутентификацию, если получил B = 0 (mod N) или u = 0. (Полагаю, что B не должно быть также равно –kV, т.к. в этом случае клиент получит S = 0a+ux (mod N) = 0).
Сервер должен прервать аутентификацию, если получил A = 0 (mod N). Клиент должен первым доказать, что получил тот же ключ K. Если клиенту это не удалось, сервер должен прервать аутентификацию, без своего доказательства K.
Немного воды или, что же автор хотел всем этим сказать?
В преамбуле к статье я писал, что занимаюсь дурью проектирую протокол беспарольной аутентификации в Web, который бы сильно облегчил всем нам (конечным пользователям сайтов) жизнь, избавляя от парольного ада. И эта статья написана, чтобы «раскрывать причины технических решений, закладываемых в новый протокол». Так вот, касаемо схемы авторизации, я делаю ставку на SRP.
На самом деле протоколов авторизации гораздо больше, чем было описано выше. Но SRP – это, на мой взгляд, самая крутая схема, созданная профильным специалистом, выпускником Стэндфордского университета (Thomas Wu), и проверенная его коллегами и другими специалистами по безопасности. Созданная, кстати, уже достаточно давно (аж в далеком 1998-м). Возможно (не точная информация), в настоящее время оформляется патент в Стэндфордском университете.
Возникает закономерный вопрос? Если эта схема такая крутая и древняя, почему она не получила до сих пор широкого распространения.
Я думаю, что этот протокол просто опередил свое время. Тогда аутентификацию предполагалось выполнять на клиенте в браузере. А javascript находился в зачаточном состоянии и мог, в лучшем случае вывести алертом «hello word». А нужна была арифметика на больших числах. Сейчас уже есть, но время упущено.
И самое главное, веб сообщество до сих пор не осознало, что процесс аутентификации необходимо выносить за рамки прямого взаимодействия сервер–браузер (равно как и аутентификацию в иных системах). В самом деле, ведь никто в здравом уме не хотел бы реализовывать вручную TLS (на javascipt/PHP/JAVA)? Для этого есть специальные системные библиотеки. Так и аутентификацию необходимо давно снять с плеч javascript, браузера и бэкенда.
И если это осознать, то не трудно видеть, что гораздо более правильным решением, поступить также с аутентификацией: создать протокол более низкого уровня, заточить его на использование парольных менеджеров (как сейчас менеджеры сертификатов и криптопровайдеры). А там уже подтянется и более профессиональная криптография. Именно по этому пути идет ваш покорный слуга, но это тема отдельной статьи.
А кстати, почему это SRP вдруг крут?
Чтобы понять это, необходимо вначале глужбе его изучить. Сравнить с другими методами и протоколами.
Злоумышленник не сможет сделать ничего, даже если взломал сервер и активно контролирует канал. Это очень круто.
Мало того, это единственный протокол, который требует взаимной аутентификации сторон (а значит уходит «фишинг», как класс сетевых атак). Даже HTTPS вам такого не гарантирует (последний лишь гарантирует, что в данный момент вы взаимодействуете с сервером, обладающим доменным именем, которое у вас светится в адресной строке). А вот с этим протоколом, клиент точно может быть уверены, что это именно тот сервер, который знает ваш V. Иначе стороны не получат общий сессионный ключ, и пункты 9-12 потерпят неудачу.
А в качестве подобного эффекта от такой аутентификации – стороны получают совместный сессионный ключ, который может быть использован для последующих целей. Например, для отделения сервером запросов пользователя от запросов другого пользователя; для «подписи» запросов и т.п.
Единственная слабость – отправка в открытом виде верификатора пользователя V во время первичной регистрации.
Если злоумышленник контролирует канал на стороне сервера с самого его основания и всё время (оператор ЦОД), то он может подменять верификатор пользователя на свой, и выполнять прокси-авторизацию. В современных реалиях (когда модны облачные вычисления, аренда серверов, всякие «co-location») данный вид атаки более чем реален. Но стоит хотя бы раз «соскочить» с контроля канала (при смене оператора) – пользователи больше никогда не смогут авторизоваться. Возникнут паника, скандалы, расследования и прочий alarm.
Напротив, контролировать же все каналы пользователя – нереально: пользователи слишком мобильны.
Подведём итоги
Напоследок, приведу примеры авторизаций разных сайтов. Не ручаюсь сказать, кто из них хранит пароли в открытом виде. Но косвенно это можно выяснить, пробуя сайту скармливать сверхдлинные пароли. Если сайт хеширует ваш пароль, то ему всё равно какая длина и какие символы в наборе. А вот если сайт запрещает использовать некоторые символы и ограничивает длину пароля (gosuslugi.ru) – это намёк на нарушение.
Среди исследованных оказались такие: yandex.ru, mail.ru, gosuslugi.ru, sberbank.ru, vk.com, google.com. В тестах использовались реальные учётные данные. Результат огорчил. Можете проверить.
Ссылки на иные статьи:
Вы опасно некомпетентны в криптографии
Защита пароля при передаче по открытому каналу (часть 2)
Аутентификация на базе ЭЦП
SRP-6: аутентификация без передачи пароля
Доступно о криптографии на эллиптических кривых
Курс MIT «Безопасность компьютерных систем». Лекция 17: «Аутентификация пользователя», часть 1
Время на прочтение
Примечание: мини-статья написана для новичков
Давайте посмотрим вокруг: форумы, интернет магазины, гостевые книги и т.д. используют регистрацию и последующую авторизацию пользователей. Можно даже сказать, что это почти необходимая функция каждого сайта (только если это не домашняя страничка Васи Пупкина или не визитная карточка, какой-нибудь небольшой компании). Сегодня я хочу поделиться со всеми новичками информацией, о том, как лучше это все реализовать.
Почему надо хранить в куках хеш случайно сгенерированной строки, а не хеш пароля?
1. Из-за невнимательности программиста, во всей системе могут быть дырки, воспользовавшийсь этими дырками, злоумышленик может вытащить хеш пароля из БД и подставить его в свои куки, тем самым получить доступ к закрытым данным. В нашем же случае, двойной хеш пароля не чем не сможет помочь хакеру, так как расшифровать он его не сможет(теоретически это возможно, но на это он потратит не один месяц, а может быть и год) а воспользоваться этим хешем ему негде, ведь у нас при авторизации свой уникальный хеш прикрепленный к IP пользователя.
2. Если злоумышленик вытащит трояном у пользователя уникальный хеш, воспользовать им он также не сможет(разве если только, пользователь решил принебречь своей безопастностью и выключил привязку к IP при авторизации).
Хочу отметить, что здесь я рассматривал авторизацию основоную на cookies, не стоит в комментариях кричать, что сессии лучше/удобнее и т.д. Спасибо.