Не утверждаю. Не знаю. Полагать, что знаешь, и знать на самом деле - не одно и тоже.
как это сделать иным способом
Например, использовать один общий ключ и протокол SRP. У меня как раз на него взгляд упал при поисках альтернативных механизмов аутентификации в веб. Он не обеспечивает анонимность, наоборот. Но если у группы пользователей будет одинаковый ключ...
А обязательно нужно, чтобы x_i зависел от a_i, тем более что мы преследуем анонимность? Если не обязательно, то подойдет любой криптостойкий генератор случайных чисел. Или генератор псевдослучайных чисел с огромным периодом, формирующий последовательность на базе начального b. Например, Вихрь Мерсена, скорость которого приближается к скорости линейных конгруэнтных алгоритмов.
Начальное состояние хеш-функции, которое неявно фигурирует в выработке хеша. Да, Вы правы: хеш-функция - это функция одного аргумента. Но только формально. А по факту - там ещё один скрытый параметр - начальный вектор инициализации. Его я обозначил первым аргументом.
А если, например, взять семейство SHA-2 (из FIPS PUB 180-4) - то там фигурирует ещё и третий аргумент - постоянный (неявный) ключ шифрования. Например, у SHA-2 - это первые 32 бита дробных частей кубических корней первых 64 простых чисел.
Если длина b равна в точности блоку хеш-функции, то, например:
где запятой я отделил значение начального вектора инициализации. Но у вас длина b - не равна блоку. Тогда:
это я имел в виду.
Если у вас алгоритм генерации x_i не входит в протокол - может стоит вынести его в приложение, как рекомендацию при реализации протокола?
Андрей Львович, спасибо за ответы! Единственное, в качестве пожелания: сделайте пометку, что алгоритм защищен патентом. А то я уже порывался найти ему применение в своей идее беспарольной аутентификации на сайтах... неловко вышло.
2 Да. Я потом уже сам догадался, что не прав.
3 Если честно, то кажется) Вот если бы пример был в виде: пусть у нас есть группа роутеров, которым необходимо... Есть N участников документооборота, необходимо... - или любой другой подобный вариант. Это было бы, на мой взгляд, более близко к программистам - тем кто, в конечном итоге, будет реализовывать протокол. Но честно скажу, сам пока не могу придумать реальный кейс на использование. Т.е. придумать могу, но тут же приходит на ум, как использовать иные протоколы для реализации придуманной задачи. Вот я о чём.
Немного занудства
Статья начинается с уровня "Ничего не слышал про криптографию" и потом резко переходит на уровень "Эксперт по теории чисел". Это вызывает когнитивный диссонанс. Скромно предположу, что преамбула привлекает читателей из первой группы, но отталкивает из второй.
5 На Хабре есть специалисты и по криптографии и по теории чисел (я дилетант и к ним не отношусь). Подозреваю, что они просто не увидели статью в мощном потоке ежедневных статей. Или не обратили внимание из-за преамбулы)
4.A Подозреваю, что причина кроется в том, что выход хеш-функции передается на её вход в качестве вектора инициализации:
где h^{i-1}(b) - это начальное значение вектора инициалиации хеш-функции h.
(Данный факт упрощает вычисления x_i во время единовременной генерации множества X).
4.B Хм.. п. 4 не относится к протоколу... Получается, в качестве x_i можно вообще брать случайные числа, сформированные криптостойким генератором? А приведенная формула получения x_i - это вариант такого генератора на базе хеш-функции. Я правильно понял?
4.C Меня немного смущает, что a_i - это множество всех последовательностей букв произвольной длины. Кто отвечает за генерацию? Участник или (назовем его) Арбитр, раздающий участникам x_i, P_i? Почему смущает? Ну хотя бы потому, что отдача на откуп генерации a_i открывает вектор атаки на вычисление h^i(b). Самый примитивный пример: a_i - пустая строка от Хакера. С другой стороны, ну вычислит этот b или h(b) легитимный Участник, что это ему даст? Он и так может "слить" свой идентификатор постороннему.
Интересный протокол. Получается, мы можем определить, что, например, аутентифицировался "свой", но кто именно из группы "своих" - неизвестно. Я прав?
Среди исходных данных заявлено , но точка нигде не используется. Где-то опечатка?
Полагаю, что протокол родился в процессе решения какой-то практической задачи. Не покажите примеров применения протокола на практике? Очень интересно.
Почему решили использовать именно многократное хеширование ? Как по вашему, такой вариант: ?
К сожалению, не рассмотрена процедура добавления/удаления участников. Тоже интересно:
А описываемый способ позволяет менять список гостей, не уведомляя посетителей.
Вот здесь хотелось бы подробнее. У меня получается пока путём полного перерасчета Г. А это ведет к необходимости рассылки новых ключей всем старым участникам.
Ещё я ввел 000000000000000000000003, 4, 5 — египетский треугольник, но мне сообщили, что числа слишком большие. Это уже баг на стороне сервера. Но за ошибку не засчитали. Нули перед числом стандартными библиотечными парсерами обрабатываются без ошибок. У вас — нет.
Javascript: parseInt('000000000000000000000003') == 3
Java: Integer.valueOf('00000000000000000003') == 3
PHP: intval('00000000000000000003') == 3;
Также ваша форма не пропускает случайные пробелы перед или после числа, хотя формально для значений input'ов разработчики обычно делают trim(), кроме input[type=textarea].
Пользователи часто на веб-формах вставляют лишние пробелы. Например, в поле логина, при копировании оного из Notepada, как пример. Обычно захватывается невидимый '\n'
Ну и ещё IEEE-нотация записи дробных чисел не реализована. Хотя на форме не сказано, что нужно вводить только целые числа.
Если я не ошибся в расчетах, для астероида размером 200км ускорение свободного падения g на поверхности находится в интервале 0,1..0,3м/с^2. Что почти в 100 раз меньше Земного. А первая космическая — 148м/с (530км/ч).
Расчеты
Положим, что астероид — идеальный железный шар, диаметром 200км, со средней плотностью 7,8т/м3. Тогда его оценочный объём составит 4,2 млн.куб.км, а масса — 3,2e+16 тонн. Оценочные значения ускорений получаем, применяя классическую формулу Ньютона для гравитации.
Конечно, астероид не идеальный шар, а реальная его плотность может быть чуть выше. Поэтому оценка g дана на интервале.
Прошу прощение, за задержку с ответом. Я подумал, что вопрос закрыт: тут всё всем понятно. Но! Дьявол зарывается в детали.
Вот если рассматривать ситуацию ровно в том контексте, что Вы описали, то проблем вообще не возникнет никаких. Но если вы «тянете» контент, доступный только авторизованным пользователям, то да — может быть проблема. И она может выскочить в самом неожиданном месте. Следите за руками.
Пусть есть у вас сайт, на котором авторизованный пользователь может смотреть некие графики. Например, статистику по серверному оборудованию. Стата эта отдается в виде JSON отдельными подзапросами. Но не отдается анонимусу. И это важно. А для отрисовки красивых графиков вы решили не изобретать велосипед, а использовать готовую стороннюю библиотеку. А чтобы иметь её самую свежую версию, – загружаете прямо с github.
1. Чтобы отрисовать график, ваш скрипт запрашивает данные с вашего сервера и отдает на отрисовку либе. Проблем пока нет. Скрипт делает запрос, правила выполняются, авторизация пользователя «не слетает».
2. Представим, теперь, что библиотека сама умеет запрашивать JSON-ки с вашего сервера. Вы говорите ей, где их и как брать. Она это делает. И вот тут возникает проблема!
Чужой скрипт делает запрос к вашему серверу. Понятно, что в нашей ситуации ничего криминального тут нет. Но одному богу известно, что хочет от вашего сервера сторонний скрипт! Такая попытка автоматом блокируется правилами вычисления токена.
3. Аналогичный облом возникнет, если библиотека не сама качает данные с вашего сайта, а просит ваш скрипт сделать это для неё.
По такой схеме может работать, например, api яндекс.карт. Вы там заводите Observer. Он вызывает ваш скрипт. Вы делаете ajax-запрос. Апи наносит точки на карту. (Это апи позволяет по разному грузить данные. В том числе и самостоятельно). Кажется я ничего с ним не напутал?
Но это и не принципиально. Принципиально объяснить, почему тут выходит облом.
Потому что, в цепочке вызовов скриптов, приводящих к запросу, был чужой скрипт. И если мы не учтём данный факт, то открываем целый класс возможных атак чужих скриптов на ваши. Javascript ещё та штучка.
4. А если очень нужно? Тогда качаем библиотеку с github и грузим её уже с вашего сайта. Теперь вы, как разработчик сайта, несете ответственность за содержание кода библиотеки и ручаетесь, что она «не порождение зла».
Но такой подход может быть применен не всегда. Например, тот же случай с яндекс.картами. Попробуй выкачай все компоненты библиотеки! Тот ещё квест. Да и не правильный подход это. Оригинальный код api поменяется, и через некоторое время вы рискуете получить полностью неработоспособного клиента.
5. Но что если совсем никак, а очень нужно? Сторонее api через нас просит скачать некий контент с нашего сайта. Он закрыт для анонимусов. API перенести к себе мы не можем. Авторизация слетает. Как быть?
Используем тот факт, что авторизация нам нужна на нашем сайте (а не на чужом). Генерируем для нашего скрипта некий сеансовый ключ, авторизующий его запросы. Теперь наш скрипт, делая ajax-запросы посылает этот ключ среди параметров. А сервер валидирует именно эти запросы не только по токену, но и по ключу.
Через cookie передавать это, я бы не стал. Что-то мне подсказывает, что с cookie могут и тут возникнуть проблемы. Вообще решений здесь много. Нужно каждое исследовать с точки зрения безопасности и удобства.
Т.е. в п. 5 помимо токенов придется ещё и такой ключ учитывать. Сложно. Не очень системно. Согласен. Я уже поставил себе таск на исследование этого.
Но обратите внимание, этот подход очень похож на тот, что используется для защиты от CSRF (одна из мер). Т.е. протокол вынуждает разработчика реализовывать защиту даже в этом случае! По крайней мере, то, что мы обратили внимание на это разработчика, – уже хорошо. Ведь, какой бы ни был хороший разработчик, человеческий фактор ошибки никто не отменял.
Прав Sabubu, когда говорил, что протокол имеет запутанные правила и разработчикам необходимо их учитывать. А я думаю, что многие такие кейсы всплывут на тестовых стендах. И будут найдены хорошие решения. По их результатам можно сделать что-то вроде cook-book с best practice. И ещё нужно будет подумать на диагностикой и отладкой таких непредвиденных ситуаций.
Всё-таки тестовая реализация нужна; но только после тюнинга этого протокола с учётом высказанных замечаний.
Что делать при делегировании доступа, когда один сервис обращается к другому на основании credentials пользователя, полученных первым сервисом?
Если сервис будет сам обращаться на основании credentials пользователя (без участия последнего; т.е. пользователь покинул сайт сервиса, а тот работает) — поступаем как и с приложением: генерируем для него API-ключ доступа. За генерацию отвечает «другой» сервис. А за распространение API ключа — пользователь, например. Так и безопаснее. И ключ не палим. И права можно выставить. API-ключ передать можно разными способами.
Если сервис, принадлежащий домену S1, будет обращаться к сервису S2 в результате действий пользователя на S1 — применяем технику ССО.
что делать разработчикам клиентских приложений (не браузеров), которым нужно работать с веб-сервисами или веб-сайтами, закрытыми такой аутентификацией
На сайте делается функционал: предоставить доступ приложению от имени пользователя. Предлагается выбрать набор предоставляемых приложению прав. Для приложения генерируется API-ключ. На мой взгляд, так будет более правильно.
При таком подходе:
1. получаем контроль над доступами приложения (это может быть чья-то сторонняя разработка; не разработчиков сайта)
2. не компрометируем ключи/токены пользователя
Что делать сайтам, живущим на одном домене, но по разным путям?
Здесь получается, что даже если пользователь и работает с приложением A1 под учеткой U1, а в приложении A2 под U2, всё-равно, каждый из этих приложений может легко получать доступы от соседнего профиля. Ну, хотя бы, в силу того, что этим «соседним» приложениям доступны все куки пользователя со своего домена.
По-сути, приложения работают с одним и тем же пользователем, но с разными профилями. На мой взгляд, здесь неправильно поставлен акцент.
Пользователь работает в приложениях не под разными учетными записями, а с разными ролями. А такую задачу можно решить, предлагая пользователю выбрать роль, по которой он будет работать с приложением. Но после авторизации.
Подойдет такое решение? Или я не Вас правильно понял?
Не утверждаю. Не знаю. Полагать, что знаешь, и знать на самом деле - не одно и тоже.
Например, использовать один общий ключ и протокол SRP. У меня как раз на него взгляд упал при поисках альтернативных механизмов аутентификации в веб. Он не обеспечивает анонимность, наоборот. Но если у группы пользователей будет одинаковый ключ...
Вот. Отличный кейс!
А обязательно нужно, чтобы x_i зависел от a_i, тем более что мы преследуем анонимность? Если не обязательно, то подойдет любой криптостойкий генератор случайных чисел. Или генератор псевдослучайных чисел с огромным периодом, формирующий последовательность на базе начального b. Например, Вихрь Мерсена, скорость которого приближается к скорости линейных конгруэнтных алгоритмов.
Начальное состояние хеш-функции, которое неявно фигурирует в выработке хеша. Да, Вы правы: хеш-функция - это функция одного аргумента. Но только формально. А по факту - там ещё один скрытый параметр - начальный вектор инициализации. Его я обозначил первым аргументом.
А если, например, взять семейство SHA-2 (из FIPS PUB 180-4) - то там фигурирует ещё и третий аргумент - постоянный (неявный) ключ шифрования. Например, у SHA-2 - это первые 32 бита дробных частей кубических корней первых 64 простых чисел.
Если длина b равна в точности блоку хеш-функции, то, например:
где запятой я отделил значение начального вектора инициализации. Но у вас длина b - не равна блоку. Тогда:
это я имел в виду.
Если у вас алгоритм генерации x_i не входит в протокол - может стоит вынести его в приложение, как рекомендацию при реализации протокола?
Всем, кто хочет изучить/понять ассемблер рекомендую начать именно с книги Зубкова.
3 Прошу прощения, ответ выше писал, ещё не ознакомившись с документом. Чукча не читатель...
Андрей Львович, спасибо за ответы! Единственное, в качестве пожелания: сделайте пометку, что алгоритм защищен патентом. А то я уже порывался найти ему применение в своей идее беспарольной аутентификации на сайтах... неловко вышло.
2 Да. Я потом уже сам догадался, что не прав.
3 Если честно, то кажется) Вот если бы пример был в виде: пусть у нас есть группа роутеров, которым необходимо... Есть N участников документооборота, необходимо... - или любой другой подобный вариант. Это было бы, на мой взгляд, более близко к программистам - тем кто, в конечном итоге, будет реализовывать протокол. Но честно скажу, сам пока не могу придумать реальный кейс на использование. Т.е. придумать могу, но тут же приходит на ум, как использовать иные протоколы для реализации придуманной задачи. Вот я о чём.
Немного занудства
Статья начинается с уровня "Ничего не слышал про криптографию" и потом резко переходит на уровень "Эксперт по теории чисел". Это вызывает когнитивный диссонанс. Скромно предположу, что преамбула привлекает читателей из первой группы, но отталкивает из второй.
5 На Хабре есть специалисты и по криптографии и по теории чисел (я дилетант и к ним не отношусь). Подозреваю, что они просто не увидели статью в мощном потоке ежедневных статей. Или не обратили внимание из-за преамбулы)
4.A Подозреваю, что причина кроется в том, что выход хеш-функции передается на её вход в качестве вектора инициализации:
где h^{i-1}(b) - это начальное значение вектора инициалиации хеш-функции h.
(Данный факт упрощает вычисления x_i во время единовременной генерации множества X).
4.B Хм.. п. 4 не относится к протоколу... Получается, в качестве x_i можно вообще брать случайные числа, сформированные криптостойким генератором? А приведенная формула получения x_i - это вариант такого генератора на базе хеш-функции. Я правильно понял?
4.C Меня немного смущает, что a_i - это множество всех последовательностей букв произвольной длины. Кто отвечает за генерацию? Участник или (назовем его) Арбитр, раздающий участникам x_i, P_i? Почему смущает? Ну хотя бы потому, что отдача на откуп генерации a_i открывает вектор атаки на вычисление h^i(b). Самый примитивный пример: a_i - пустая строка от Хакера. С другой стороны, ну вычислит этот b или h(b) легитимный Участник, что это ему даст? Он и так может "слить" свой идентификатор постороннему.
Интересный протокол. Получается, мы можем определить, что, например, аутентифицировался "свой", но кто именно из группы "своих" - неизвестно. Я прав?
Среди исходных данных заявлено
, но точка нигде не используется. Где-то опечатка?
Полагаю, что протокол родился в процессе решения какой-то практической задачи. Не покажите примеров применения протокола на практике? Очень интересно.
Почему решили использовать именно многократное хеширование
? Как по вашему, такой вариант: 
?
К сожалению, не рассмотрена процедура добавления/удаления участников. Тоже интересно:
Вот здесь хотелось бы подробнее. У меня получается пока путём полного перерасчета Г. А это ведет к необходимости рассылки новых ключей всем старым участникам.
Javascript: parseInt('000000000000000000000003') == 3
Java: Integer.valueOf('00000000000000000003') == 3
PHP: intval('00000000000000000003') == 3;
Пользователи часто на веб-формах вставляют лишние пробелы. Например, в поле логина, при копировании оного из Notepada, как пример. Обычно захватывается невидимый '\n'
Ну и ещё IEEE-нотация записи дробных чисел не реализована. Хотя на форме не сказано, что нужно вводить только целые числа.
Мужик, я тебя отлично понимаю! У самого вон проект забуксовал.
Поверьте vpedak, тут дело не в лени. С детьми и правда личного времени не остается.
Конечно, астероид не идеальный шар, а реальная его плотность может быть чуть выше. Поэтому оценка g дана на интервале.
Вот если рассматривать ситуацию ровно в том контексте, что Вы описали, то проблем вообще не возникнет никаких. Но если вы «тянете» контент, доступный только авторизованным пользователям, то да — может быть проблема. И она может выскочить в самом неожиданном месте. Следите за руками.
Пусть есть у вас сайт, на котором авторизованный пользователь может смотреть некие графики. Например, статистику по серверному оборудованию. Стата эта отдается в виде JSON отдельными подзапросами. Но не отдается анонимусу. И это важно. А для отрисовки красивых графиков вы решили не изобретать велосипед, а использовать готовую стороннюю библиотеку. А чтобы иметь её самую свежую версию, – загружаете прямо с github.
1. Чтобы отрисовать график, ваш скрипт запрашивает данные с вашего сервера и отдает на отрисовку либе. Проблем пока нет. Скрипт делает запрос, правила выполняются, авторизация пользователя «не слетает».
2. Представим, теперь, что библиотека сама умеет запрашивать JSON-ки с вашего сервера. Вы говорите ей, где их и как брать. Она это делает. И вот тут возникает проблема!
Чужой скрипт делает запрос к вашему серверу. Понятно, что в нашей ситуации ничего криминального тут нет. Но одному богу известно, что хочет от вашего сервера сторонний скрипт! Такая попытка автоматом блокируется правилами вычисления токена.
3. Аналогичный облом возникнет, если библиотека не сама качает данные с вашего сайта, а просит ваш скрипт сделать это для неё.
По такой схеме может работать, например, api яндекс.карт. Вы там заводите Observer. Он вызывает ваш скрипт. Вы делаете ajax-запрос. Апи наносит точки на карту. (Это апи позволяет по разному грузить данные. В том числе и самостоятельно). Кажется я ничего с ним не напутал?
Но это и не принципиально. Принципиально объяснить, почему тут выходит облом.
Потому что, в цепочке вызовов скриптов, приводящих к запросу, был чужой скрипт. И если мы не учтём данный факт, то открываем целый класс возможных атак чужих скриптов на ваши. Javascript ещё та штучка.
4. А если очень нужно? Тогда качаем библиотеку с github и грузим её уже с вашего сайта. Теперь вы, как разработчик сайта, несете ответственность за содержание кода библиотеки и ручаетесь, что она «не порождение зла».
Но такой подход может быть применен не всегда. Например, тот же случай с яндекс.картами. Попробуй выкачай все компоненты библиотеки! Тот ещё квест. Да и не правильный подход это. Оригинальный код api поменяется, и через некоторое время вы рискуете получить полностью неработоспособного клиента.
5. Но что если совсем никак, а очень нужно? Сторонее api через нас просит скачать некий контент с нашего сайта. Он закрыт для анонимусов. API перенести к себе мы не можем. Авторизация слетает. Как быть?
Используем тот факт, что авторизация нам нужна на нашем сайте (а не на чужом). Генерируем для нашего скрипта некий сеансовый ключ, авторизующий его запросы. Теперь наш скрипт, делая ajax-запросы посылает этот ключ среди параметров. А сервер валидирует именно эти запросы не только по токену, но и по ключу.
Через cookie передавать это, я бы не стал. Что-то мне подсказывает, что с cookie могут и тут возникнуть проблемы. Вообще решений здесь много. Нужно каждое исследовать с точки зрения безопасности и удобства.
Т.е. в п. 5 помимо токенов придется ещё и такой ключ учитывать. Сложно. Не очень системно. Согласен. Я уже поставил себе таск на исследование этого.
Но обратите внимание, этот подход очень похож на тот, что используется для защиты от CSRF (одна из мер). Т.е. протокол вынуждает разработчика реализовывать защиту даже в этом случае! По крайней мере, то, что мы обратили внимание на это разработчика, – уже хорошо. Ведь, какой бы ни был хороший разработчик, человеческий фактор ошибки никто не отменял.
Прав Sabubu, когда говорил, что протокол имеет запутанные правила и разработчикам необходимо их учитывать. А я думаю, что многие такие кейсы всплывут на тестовых стендах. И будут найдены хорошие решения. По их результатам можно сделать что-то вроде cook-book с best practice. И ещё нужно будет подумать на диагностикой и отладкой таких непредвиденных ситуаций.
Всё-таки тестовая реализация нужна; но только после тюнинга этого протокола с учётом высказанных замечаний.
Если сервис будет сам обращаться на основании credentials пользователя (без участия последнего; т.е. пользователь покинул сайт сервиса, а тот работает) — поступаем как и с приложением: генерируем для него API-ключ доступа. За генерацию отвечает «другой» сервис. А за распространение API ключа — пользователь, например. Так и безопаснее. И ключ не палим. И права можно выставить. API-ключ передать можно разными способами.
Если сервис, принадлежащий домену S1, будет обращаться к сервису S2 в результате действий пользователя на S1 — применяем технику ССО.
На сайте делается функционал: предоставить доступ приложению от имени пользователя. Предлагается выбрать набор предоставляемых приложению прав. Для приложения генерируется API-ключ. На мой взгляд, так будет более правильно.
При таком подходе:
1. получаем контроль над доступами приложения (это может быть чья-то сторонняя разработка; не разработчиков сайта)
2. не компрометируем ключи/токены пользователя
Здесь получается, что даже если пользователь и работает с приложением A1 под учеткой U1, а в приложении A2 под U2, всё-равно, каждый из этих приложений может легко получать доступы от соседнего профиля. Ну, хотя бы, в силу того, что этим «соседним» приложениям доступны все куки пользователя со своего домена.
По-сути, приложения работают с одним и тем же пользователем, но с разными профилями. На мой взгляд, здесь неправильно поставлен акцент.
Пользователь работает в приложениях не под разными учетными записями, а с разными ролями. А такую задачу можно решить, предлагая пользователю выбрать роль, по которой он будет работать с приложением. Но после авторизации.
Подойдет такое решение? Или я не Вас правильно понял?