Комментарии 18
Вместо SRP лучше использовать современные PAKE алгоритмы на основе эллиптических кривых, например, OPAQUE или SPAKE2.
>Эллиптические кривые используются в криптографии относительно недавно и ещё слабо изучены.
Лихое, однако, утверждение касающееся львиной доли современной асимметричной криптографии вы озвучили.
>Однако на сегодняшний день не известно методик, которые бы однозначно могли оценить надёжность кривых.
Не углубляясь в математику, надёжность secp256k1, как минимум, оценена рыночной капитализацией Биткойна. Чего уж говорить об остальных кривых, обеспечивающих безопасность обмена данных, в т.ч. финансовых сообщений на много-много денег.
Ох как хитро завернули, коллега! Я так и не понял, кто мсье, кто хочет оспорить, и кому посвящена ваша реплика. Но меня точно не стоит демотивировать)
Но судя по тому, что в приведенной Вами ссылке кривая Биткоина называется небезопасной, думаю,
надёжность secp256k1, как минимум, переоценена
Или я не прав?
Лихое, однако, утверждение
Утверждение, что "теория эллиптических кривых ещё только-только развивается", я не раз слышал от самих математиков на лекциях. Хотя теория такая, что приходится вгрызаться зубами, чтобы хоть что-то понять. Знал бы, что придется держать ответ, собирал бы пруфы.
Математики вообще скромные ребята: "мы только-только начертили дорожную карту, чтобы понять, куда идти дальше". Сравните со "здание физики уже построено, остались лишь детали".
Опасения о том, что "не все кривые одинаково полезны", тоже не на пустом месте родились. Особенно после известных в узком кругу скандалов.
Так что я тут "за что купил, за то и продаю") Не судите строго.
А Вы не могли бы вкратце пояснить, чем именно лучше? Я сейчас без подвохов спрашиваю.
Я погрузился в черновик стандарта OPAQUE, но так и не понял, выполняются ли нужные мне требования: взаимная аутентификация сторон, защита клиента даже после взлома сервера при последующем активном вмешательстве в канал (защита от проксирования, навязывания ложной информации).
Не увидел там формул вообще. А только поверхностное описание протокола при очень подробном описании используемых структур данных. Может не туда смотрел, каюсь заранее.
Не понимаю зачем городить огород для веб. Используешь https, который уже предполагает защиту, передаёшь пароль на сервер в открытом виде. На сервере всё хранится в виде солёного хеша. В той же php есть операторы password_hash и password_verify для подобных операций. Даже если сольют базу, то будут вынуждены искать пароли для каждой учётной записи отдельно. На Python есть аналогичный функционал, как я понял, когда смотрел базу matrix-synapse. К тому же на вебе передать пароль в открытом виде можно через обычную html форму, а для предложенных алгоритмов нужно использовать js.
Чтобы понять намек, поищите по фразе "Национальный сертификат безопасности Казахстана"
Слышал о таком. Но если пользователь своими руками даёт способ расшифровывать свой трафик, то чья это вина? К тому же, кто мешает в таком незащищённом соединении модифицировать ваши скрипты и передать пароль в открытом виде на сторону? Да, сложнее, но тоже возможно.
У среднего пользователя недостаточно квалификации чтобы понять это. Особенно если государство будет продвигать свой СА под соусом "государственной безопасности".
Да и необязательно заставлять пользователей делать это самостоятельно. Можно просто продавить микрософт, чтобы сертификат "государственной безопасности" прилетел в автоматическом обновлении всем гражданам данного государства. В таком случае пользователь уж точно не будет винить себя.
Так если бы своими руками давал. Вот в школах интернет "фильтруют" в принудительном порядке. Ровно таким методом.
К тому же, кто мешает в таком незащищённом соединении модифицировать ваши скрипты и передать пароль в открытом виде на сторону?
Вот поэтому я и предлагаю в новом протоколе (на базе SRP), вынести процессы авторизации (включая сопутствующие) за рамки "браузер-сервер", как сейчас работает TLS.
Ага. Это полбеды. А ещё есть такая штука, как StoneGate, у которой заявлено "инспекция HTTPS-трафика со скоростью 40Мб/с". И она вскрывает трафик без всяких предварительных установок сертификатов. Автору самому "больно щелкнули по носу", когда он усомнился в таком. Так что я сейчас немного настороженно отношусь к т.н. гражданской криптографии.
И кстати, интернет в российских школах некоторых регионов тоже также фильтруется - через установку корневого сертификата. Ключевые слова: InsideSystems и Ростелеком.
Это в дополнение к Вашему комментарию.
А как «фишинг» уйдёт, если создать реплику сайта с похожим доменом?
в такой атаке нет необходимости во взаимодействии с оригинальными клиент / сервер.
останется вопрос как туда траффик нагнать, но это уже другая история
Если я правильно понял Ваш вопрос.
В протоколе, который проектирую, само явление "как ввод логина/пароля" на веб-сайте уходит "в отставку". Аутентификацию предлагается проводить через дополнительные HTTP-заголовки по протоколу SRP.
Сервер себя идентифицирует не по доменному имени (как это принято в SSL), а по идентификатору, который выбирает сам. Как результат, появляется понятие не сайта, а "приложения", которое может быть распределено по нескольким доменам, или, наоборот, несколько приложений (даже от разных вендоров) сконцентрироваться в пределах одного домена.
Конечно, в такой схеме любой сайт, заманивший пользователя к себе, может попытаться использовать чужой идентификатор и потребовать "авторизоваться" (аналог фишина в моей версии протокола). Но т.к. SRP требует от сторон взаимной проверки, сервер злоумышленника не сможет прикинуться легальным, и клиент это выявит (пп. 9-12 протокола).
Не получится и проксировать запросы через себя, подменяя информацию. Хотя прослушивать сможет. Но сам акт авторизации никак не выдает ключевую информацию, и уж тем более пароль. Обратите внимание, что там на первом этапе вообще передаются случайные числа, из которых получить исходный ключ или верификатор клиента невозможно, даже если решить задачу дискретного логарифма.
Кроме того, в дальнейшем полученный сессионный ключ предлагается использовать для подписи запросов клиента и сервера. Тем самым мешая проксирующему серверу "навязать" неверные данные.
Вообще, я предлагаю стандартизировать большинство процессов, связанных с аутентификацией (регистрация, замена ключей, логин/логаут, предоставление/отзыв доступов сторонним интернет-приложениям, резервный план восстановления учеток и другое), освободив разработчиков от это "рутины". Но это тема большой отдельной статьи.
Спасибо за актуальную и подробную статью!) Помогите разобаться в нескольких моментах схемы на базе протокола SRP:
scrypt предлагается использовать везде далее в алгоритме вместо SHA-1 или только для вычисления x? т.е. hash() в описанном алгоритме это scrypt() или SHA-256?
почему A и B получаются 2048-битные?
числа N и g используются из спецификации постоянно? Есть необходимость их генерировать под каждый проект (сайт) или под каждого пользователя сайта?
зачем клиенту посыласть дважды свою соль серверу при регистрации в пунктах 1 и 6?
какая группа N и g подразумевается в вашем алгоритме (скольки битная)?
В тексте схемы защиты на симметричных ключах нет картинки формулы K=hmac_{H_p}(salt)
Только для вычисления x. hash - это криптографическая хеш-функция, не scrypt. Сам scrypt, конечно же работает, на базе криптографической хеш-функции (SHA-2). Основное предназначение scrypt - сильно замедлить подбор пароля пользователя, по известной злоумышленнику соли и хешу. В остальных случаях, где нужен хеш - используется SHA-2; криптографы уже не рекомендуют использовать SHA-1.
Теническая ошибка. Я неявно допустил, что N выбрано 2048-битным (см. https://datatracker.ietf.org/doc/html/rfc5054#appendix-A, п. 3). Хотя об этом не сказал. Да, прошу прощения. Так что далее, подразумевается, что разрядность чисел A, B не может быть больше 2048 бит, т.к. мы получаем эти числа, как результат математических операций по модулю N. Что касается, исходных чисел a и b, - они должны иметь разрядность не менее 11 бит (миниальное точное значение необходимо уточнить у математиков; подразумеваю, что не менее 22 бит). Иначе задача дискретного логарифма превращается в просто задачу логарифма,
Можно сгенерировать под каждый проект/сайт индивидуально. Тогда сервер должен предварительно уведомлять клиента о использумых им N и g. Но учтите, что поиск больших простых чисел достаточно трудоёмкая операция. Можно неудачно сгенерировать N и получить уязвимость. Я же предлагаю не использовать индивидуальные N/g для каждого клиента, т.к. клиенту придется где-то хранить ещё и эти параметры для каждого сервера.
Незачем. Досадная ошибка. Я много раз вычитывал текст, перед публикацией. Но видно глаз замылился. Можно убрать отправку из п. 6.
N - 2048-битная. Тут нужно соблюсти баланс между достаточным уровнем безопасности и техническими накладками по реализации. Считаю (субъетивное мнение), что 2048 - это на текущий момент достаточная длина модуля. Более крупные модули приведут к тому, что числа (V, A, B) будут такими же крупными. Не будем забывать, что серверу придется хранить верификатор пользователя (V - 256 байт), а при аутентификации ещё и оперировать такими гиганскими числами. При такой математике впору подумать над защитой от DDoS. Основная уязвимость протокола SRP в том, что сервер делает гораздо больше вычислений, чем клиент при авторизации.
А вот не знаю, кто съел картинку) Когда публиковал статью - была. Формула там один-в-один как в п. 2, только соль вместо логина.
Большое спасибо за внимательное прочтение и вопросы "по делу".
Техники безопасной парольной авторизации в Web