Очевидно, что сервер подписывает ответ своим ключом для всех токенов.
Если аутентификация stateless, то инвалидировать нельзя никак. Единственное, чем вы можете управлять это время жизни токена. Нужно с умом выбирать тот или иной способ аутентификации в соответсвии с конкретной задачей. И конечно не стоит слепо гнаться за «набирающими популярность» вещами. Надо все самому взвешивать и оценивать.
Спасибо за статью. Немного намешано разных аспектов аутентифкации, но в основном написаны правильные вещи.
И ещё один, менее (пока) популярный (и доступный только на устройствах Apple) метод беспарольной аутентификации: использовать Touch ID для аутентификации по отпечаткам пальцев.
Тут надо отметить, что Touch ID обычно только заменят PIN-код при доступе к криптографическим ключам, которые используются для аутентификации.
Кстати есть решения и с новомодным FaceID.
Что касается биометрии, то ее следует рассматривать как локальную аутентификацию на устройстве. Я бы избегал систем, где биометрические данные используются для централизованной аутентификации.
Одним из трендов в аутентификации обещает стать FIDO U2F. Он, к сожалению, не упоминается в этой статье. Про него очень неплохо написано тут.
Добавлю такой продукт — Ericom AccessNow. Он заворачивает RDP в HTTPS, а значит может использоваться в любом браузере (HTML5). Получается такой «RDP в браузере». Разворачивал этот софт в связке с сервером многофакторной аутентификации, так как считаю, что открывать доступ к удаленному рабочему столу, защищенному одним паролем, плохая идея.
Зря вы переходите на личности и позволяете себе такой тон общения.
Про ассиметричную криптографию в статье ничего нет и это прямо следует из заголовка статьи.
Лично мне статья очень понравилась. По-моему, именно так и надо преподавать криптографию. Жду от автора цикла статей.
Не важно, какая карма у человека сейчас. Если считаю, что человек прав и плюса за комментарий или статью недостаточно, чтобы выразить свое согласие, то всегда плюсую карму. Было дело, что плюсовал и карму человека, когда она была, кажется, -80 или около того.
Согласен с вами, что есть некоторый стоп-фактор перед написанием комментария. Иногда не хочется писать «непопулярную» точку зрения.
Думаю, что ТМ все понимает. Возможно надо просто что-то конкретное предложить. Например, чтобы пользователи не могли напряму понижать карму, а только повышать. Понижение кармы пусть происходит засчет итогового рейтинга комментариев и статей. Например 5 минусов за коммент равно -1 к карме. Это более регулируемо, так как другие пользователи, если по их мнению человека минусуют незаслужено, поставят свой плюс. Хотя кажется, рейтинги комментариев и статей уже используются для рассчета рейтинга пользователя (зачем он нужен вообще?).
Да, я знаю, что ваш сервер аутентификации не поддерживает SAML. Самое близкое к SAML, что у вас есть, это WS-Federation. Я просто высказал свое мнение, что интереснее для VMware Horizon View была бы интеграция по SAML. Это открывает свободу в выборе методов аутентификации и позволяет легко менять и комбинировать методы. К тому же, коммуникации между сервисом и сервером аутентификации защищены, в отличии от RADIUS-PAP. Кстати вы не ответили про PAP: почему выбор пал именно на него? Или JAS тоже только его поддерживает?
С чем связано, что вы рекомендуете использовать PAP, а не MSCHAPv2?
Как по мне, более интересна аутентифкация по протоколу SAML. В этом случае есть большая вариативность методов аутентификации, а не только то, что можно завернуть в RADIUS.
Вы так много пишите про информационную безопасность. Тут даже указали, что у вас есть система защиты клиентов. Но я захожу на ваш сайт и вижу личный кабинет и веб-версию торговой платформы, доступные по статическому паролю.
Не верю, что вы не слышали про двухфакторную аутентификацию.
Поворошу старую тему. Менял на прошлой неделе сим карту мегафон. Мне сообщили, что сутки не будут работать СМС. Через сутки СМС начали работать. По-моему, очень простое решение, хоть и немного неудобное (не смог получить одноразовый код, который понадобился именно в эти первые сутки).
Спасибо за статью.
Есть ли какие-то требования со стороны стандарта к реализации двухфакторной аутентификации? Например:
— список разрешенных методов аутентификации
— требования к сертификации софта, реализующего аутентификацию или можно использовать самописный/opensource
— архитектурные требования
и т.д.
Спасибо за ответ.
Было бы неплохо предоставлять пользователям возможность выбора второго фактора вместо СМС.
ЦБ, надеюсь, свои рекомендации пересмотрит, как их пересмотрел недавно NIST. Все таки украсть СМС уже не так дорого, а перевыпуск SIM вообще давно успешно практикуется.
Вы пишите про OAuth 2.0 в разрезе аутентификации, но справедливости ради — это все-таки стандарт авторизации. Интересно узнать, что у вас отвечает за собственно аутентификацию?
И планируете ли вы уходить от SMS, как от одного из факторов аутентификации?
Кажется вам подойдет смарт-карта. Ключ физически у пользователя, но он не может его получить в открытом виде, а может только использовать.
Другой вариант, вероятно более подходящий под ваше описание: облачный сервер подписи. Ключи пользователей могут храниться на нем + HSM. При прохождении строгой аутентификации(можно даже по OTP-паролям) на этом сервере, он позволит подписать аутентификационный запрос. Правда, насколько мне известно, пока облачные сервера подписи используются только для подписи. Но аутентификация по ключам подразумевает как раз подпись нонса, так что это тоже должно быть возможно.
Понимаю, к чему вы клоните. Но я негодую не из-за подачи материала, а из-за фактических ошибок. Вот например, вам проще называть и открытый ключ и сертификат термином «публичная часть ключа». Но это некорректно. Потому, что нет никаких частей ключа. И даже если предположить, что вы называете этим термином открытый ключ ключевой пары, то в других предложениях вы этим же термином называете сертификат. А сертификат != открытый ключ. Вы можете таким «упрощением» запутать читателя и него будут ложные представления о рассмотренном материале.
В моем комментарии было не так много вопросов, в основном я указываю на ошибки, не задавая вопросы. Если так будет проще, то давайте я соберу вопросы, на которые мне хотелось бы услышать ваш ответ:
1. Чем сертификат от Let's Encrypt хуже платного?
2. Что вы хотите сказать фразой «о PKI как таковой речи быть не может»?
Если аутентификация stateless, то инвалидировать нельзя никак. Единственное, чем вы можете управлять это время жизни токена. Нужно с умом выбирать тот или иной способ аутентификации в соответсвии с конкретной задачей. И конечно не стоит слепо гнаться за «набирающими популярность» вещами. Надо все самому взвешивать и оценивать.
Тут надо отметить, что Touch ID обычно только заменят PIN-код при доступе к криптографическим ключам, которые используются для аутентификации.
Кстати есть решения и с новомодным FaceID.
Что касается биометрии, то ее следует рассматривать как локальную аутентификацию на устройстве. Я бы избегал систем, где биометрические данные используются для централизованной аутентификации.
Одним из трендов в аутентификации обещает стать FIDO U2F. Он, к сожалению, не упоминается в этой статье. Про него очень неплохо написано тут.
Про ассиметричную криптографию в статье ничего нет и это прямо следует из заголовка статьи.
Лично мне статья очень понравилась. По-моему, именно так и надо преподавать криптографию. Жду от автора цикла статей.
Думаю, что ТМ все понимает. Возможно надо просто что-то конкретное предложить. Например, чтобы пользователи не могли напряму понижать карму, а только повышать. Понижение кармы пусть происходит засчет итогового рейтинга комментариев и статей. Например 5 минусов за коммент равно -1 к карме. Это более регулируемо, так как другие пользователи, если по их мнению человека минусуют незаслужено, поставят свой плюс. Хотя кажется, рейтинги комментариев и статей уже используются для рассчета рейтинга пользователя (зачем он нужен вообще?).
Как по мне, более интересна аутентифкация по протоколу SAML. В этом случае есть большая вариативность методов аутентификации, а не только то, что можно завернуть в RADIUS.
Не верю, что вы не слышали про двухфакторную аутентификацию.
Есть ли какие-то требования со стороны стандарта к реализации двухфакторной аутентификации? Например:
— список разрешенных методов аутентификации
— требования к сертификации софта, реализующего аутентификацию или можно использовать самописный/opensource
— архитектурные требования
и т.д.
Было бы неплохо предоставлять пользователям возможность выбора второго фактора вместо СМС.
ЦБ, надеюсь, свои рекомендации пересмотрит, как их пересмотрел недавно NIST. Все таки украсть СМС уже не так дорого, а перевыпуск SIM вообще давно успешно практикуется.
И планируете ли вы уходить от SMS, как от одного из факторов аутентификации?
Другой вариант, вероятно более подходящий под ваше описание: облачный сервер подписи. Ключи пользователей могут храниться на нем + HSM. При прохождении строгой аутентификации(можно даже по OTP-паролям) на этом сервере, он позволит подписать аутентификационный запрос. Правда, насколько мне известно, пока облачные сервера подписи используются только для подписи. Но аутентификация по ключам подразумевает как раз подпись нонса, так что это тоже должно быть возможно.
В моем комментарии было не так много вопросов, в основном я указываю на ошибки, не задавая вопросы. Если так будет проще, то давайте я соберу вопросы, на которые мне хотелось бы услышать ваш ответ:
1. Чем сертификат от Let's Encrypt хуже платного?
2. Что вы хотите сказать фразой «о PKI как таковой речи быть не может»?
Игнорирование вопросов, это, конечно, ваше право.