Pull to refresh
19
0
Николай Корабельников @nmk2002

Информационная безопасность

Send message

Поправьте, если я неправ, но все последние обнаруженные существенные уязвимости связаны с веб интерфейсом Exchange (OWA, ECP). Если его не открывать в интернет, а оставить доступными только smtp/imap/mapi, то головной боли должно быть значительно меньше. Это не отменяет то, что нужно регулярно заниматься патчингом.

Можете пройти этот курс: https://intuit.ru/studies/courses/110/110/info

Это намного больше, чем требуется для бытового понимания, но чего-то другого предложить не могу.

Справедливости ради, это перевод и спрашивать надо автора оригинала)

Тоже хотел упомянуть psono. Доволен им как слон. И по групповой работе и по назначению прав доступа все устраивает. Даже поддержка в лице единственного разработчика работает очень оперативно, хотя у меня не платная версия.

Понял, что вы имеете в виду. Спасибо. Дело в том, что одно и то же значение секрета (seed) хранится и в генераторе и на сервере. При аутентификации сервер просто генерирует OTP аналогично тому, как это происходит в генераторе OTP. И сравнивает с полученным. Интернет тут не требуется. Но я про это и не пишу. А пишу про то, что есть центральная база с общими секретами. В случае с асимметричной криптографией такой базы нет.
Почему вы мне это написали?
Планшет — это не только экран. Это компьютер с ARM процессором. Он может сам шифровать данные. Для защиты от манипуляций можно удалять чувствительную информацию при попытке вскрытия корпуса, аналогично тому, как это реализовано у HSM.
Повторю только то, что уже написал: биометрия в подобных решениях проверяется локально на аутентификаторе, а не собирается централизованно. Поэтому нелогично говорить про сбор биометрических данных как цель описанных стандартов аутентификации.
При чем тут сбор биометрических данных? Биометрия вообще не входит в стандарт, а скорее частный пример реализации. Даже если вы решили использовать отпечаток для подтверждения аутентификации, обычно он проверяется локально на устройстве и никто его не «собирает». Централизованные системы биометрической аутентификации — почти всегда не очень хорошая идея.
Обычная аутентификация по сертификатам не стала популярной из-за ее неудобств и обычно она основана на том, что каждый сервис выпускает свой сертификат. За каждым сертификатом надо следить, перевыпускать, отзывать. А тут у вас будет одна пара ключей, которую примут все сервисы, поддерживающие стандарт, и привяжут к вашей учетной записи.
Революция в том, что теперь использовать асимметричную криптографию для аутентификации станет намного проще обеим сторонам: пользователям и сервисам.
Принципиально отличие очень большое. В случае с Google Authenticator на сервере хранится так называемый seed, на основании которого происходит генерация одноразового кода. А значит, что теоретически все учетные записи пользователей могут быть централизованно скомпрометированы. В случае с U2F вы используете асимметричную криптографию — на сервер отдается ваш открытый ключ и потом вы просто подписываете запросы аутентификации своим закрытым ключом. Любая компрометация сервера не приведет к утечке вашего закрытого ключа. Таким образом удается избежать такой неприятности как массовая утечка.
Еще токен Google Authenticator может быть скопирован, а криптографические чипы скопировать гораздо сложнее (обычно считается, что закрытый ключ неизвлекаем).
те же токены YubiKey поддерживают аппаратные пинкоды, которые неизвестны серверу, в отличие от обычных смарт-карт

Не могли бы вы пояснить? Разве PIN коды от смарт-карт надо хранить на сервере?
на планшете не составит особого труда внедрить запись потока событий сенсора при собственноручной подписи одного документа, а затем воспроизвести её под соверешенно другим

Как я уже упоминал, есть планшеты, для которых это невозможно, так как сам документ является параметром для шифрования.

Или показать пользователю один документ для подписи, а реально подписать другой

Тут как раз лучше, чем с бумагой, где подмена документов ловкостью рук иногда практикуется (или уже нет?). Если вы начали процесс подписи, то на планшете отображается документ, который позже будет подписываться. Если вы потом захотите «подсунуть» другой документ, то он сначала опять-таки должен отобразиться на планшете.
Да, для граждан, которые не носят эцп сделали публичную оферту — если я правильно понял.

Никакая публичная оферта не заменяет необходимости подписывать кредитный договор. Его можно подписать собственноручно или с использованием квалифицированной ЭП. Если у всех клиентов есть с собой квалифицированная ЭП, то можно использовать эту технологию для отказа от бумаги. В реальной жизни у клиента ничего нет. Поэтому отказаться от бумаги используя квалифицированную ЭП не получается. Планшеты в этом случае решают задачу отказа от бумаги сильно не меняя процессы подписания.

Другой пример. Внутренний электронный документооборот на фирме

По-моему, в большинстве задач внутреннего документооборота ЭП будет предпочтительнее. Ограниченное множество сотрудников, которые административным способом обязаны носить токены или смарт карты. Полагаю, что вы в курсе, что можно использовать разные способы электронной подписи, предварительно условившись о порядке их применения. Например, вы можете осуществлять электронную подпись вводом кода из СМС. И это имеет статус простой подписи. Не могу не сказать про минусы такого варианта — небезопасные СМС, которые по сути не подтверждают владение SIM-картой и то, что такая простая подпись никак не связана с самим документом.

Что касается ЦРП, то результат подписания можно рассматривать и как обычную собственноручную подпись (пока в РФ нет отдельных законов для такого типа подписи) и как неквалифицированную ЭП.
По третьему примеру — я не знаком с форматом приема данных государственной системы ДЕЛО, но подозреваю, что она ожидает на входе именно документ с ЭП, которую может проверить. При использовании ЦРП проверка подписи производится только для спорных случаях. Пока спора нет — подпись — это просто картинка стоящая рядом с ФИО подписанта. Ответ — нет, думаю, что ЦРП тут не применим.

С больничными можно рассмотреть вариант, но тут скорее надо делать гибридный вариант, когда врач рассписывается облачной подписью. По мне так тут лучше строгую аутентификацию использовать, так как врачи — ограниченный груг лиц.

ЦРП можно предложить клиентам медучреждений подписывать всякие бумаги, тогда это оправдано.
Думайте о подписи на планшете как об обычной подписи на бумаге. Как и подпись на бумаге — ее может поставить кто угодно. Вам и без планшетов могут сказать, что вы расписались в договоре на бумаге. Тут у кредитных организаций есть свои риски таких действий, поэтому они заинтересованы не допускать такой фрод.
По решению суда экспертизу оплатит в итоге недобросовестный залогодатель, если будет признано, что вы не брали кредит.
Для разных задач есть разные решения. Не все граждане носят с собой токены с ЭП при походе в магазин. А, например, магазины и банки заинтересованы, чтобы вы могли быстро взять кредит на холодильник. В то же время возни с бумагой и сопутствующие расходы на логистику и архивирование хочется избежать.
Есть расширения, которые могут. Например, я пока использую Proxy Toggle для Firefox.
Про защиту от копирования блока подписи и помещения его в другой документ я уже писал — если попытаться перенести блок подписи (а PDF документ представляет собой блочную структуру и подпись в нем — отдельный блок, добавленный к исходному документу), то расшифровать этот блок не представляется возможным.

Физически расписаться может и злоумышленник, аналогично тому, как и на бумаге не видно, кто поставил подпись. Для определения принадлежности подписи назначается графологическая экспертиза.

Вообще, подпись на планшете по своей сути полностью аналогична подписи на бумаге, но для графологов несет значительно больше информации, так как содержит не только графические данные и давление, но и скорость перемещения пера. Самое важное тут — правильно привязать подпись к документу таким образом, чтобы не было сомнений, что она сделана именно для конкретного документа.
Как уже многократно упоминалось, вы вольны выбирать, какой носитель аутентификатора использовать.
Я привел пример, когда вы можете видеть использование одной и той же технологии (push) при аутентификации. И там и там push. Но методы то совсем разные.
Это как если вам нужно использовать шифрование: вы можете использовать стандартный алгоритм AES, а можете взять какой-то алгоритм, который не стандартизован, но зато придуман вами и является на ваш взгляд более надежным.
В приват24 свое приложение со сканером qr кода. Если я залогинился в нем, то через сканер меня пустит на сайт без каких либо проверок.

Ну вот вы не видите, что происходит, а пока вы держите телефон, приложение отправляет на сервер приват24 информацию, что вы — аутентифицированный пользователь. Я предполагаю, что в этот момент общение между приложением и сервером примерно такое:
1. приложение сообщает серверу, что хочет аутентифицировать пользователя.
2. Сервер отправляет нонс
3. Приложение его подписывает закрытым ключом и возвращает ответ серверу.
4. Сервер проверяет подпись.

Фактор владения байтами (приватный ключ) не больше фактора знания пароля

Есть разные угрозы. От подсматривания, кейлоггеров или даже от утечки на стороне поставщика услуг мобильное приложение с закрытым ключом более предпочтительно, чем парольная аутентификация.
Говорить, что какой-то фактор больше или меньше другого, некорректно. Тем более, что даже в приведенном мной примере можно использовать PIN-код(аналог пароля) для доступа к закрытому ключу. А значит, что это уже двухфакторная аутентификация.
Если сайты вынуждены писать свои моб приложения, то какой смысл от стандартизации? Опенсорсные либы?

Сайты могут использовать метод аутентификации, который им нравится. Но среди прочих, они смогут выбрать то решение по аутентификации, которое построено на стандартизированных протоколах. Соответствие стандартам позволяет понимать, что именно и как работает. Иначе может получиться ситуация которую я недавно видел в одном банке: одна компания предложила аутентификацию с использовнием push сообщений для уведомления пользователя по аналогии с тем, что написано в статье. То есть на смартфон приходит уведомление о том, что надо аутентифицироваться или подписать транзакцию (с текстовым описанием самой транзакции). Пользователь открывает приложение для аутентификации и вводом пин-кода, отпечатком пальца или FaceID подтверждает аутентификацию (подписывает нонс закрытым ключом и отправляет на сервер аутентификации). А конкуренты предложили просто присылать по каналу push одноразовые коды. Это вообще нельзя рассматривать как конкурирующие методы аутентификации. Но для клиента не всегда понятно, в чем разница, если и там и там push.
Кста. В приват24 для входа мне не нужно никуда жать, просто открыл главную страницу, навел камеру телефона на экран и сайт сам меня впускает через 10 сек. Похоже они уже ушли дальше этого стандарта.

Что именно происходит при аутентификации в приват24 я не знаю. Но вы явно не просто камерой снимаете, а используете мобильное приложение банка, которое скорее всего тоже использует асимметричную криптографию для подтверждения входа.
Есть одна проблема. Эти схемы не гарантируют факт владения номером телефона, а ведь факт владения это один из факторов двухфакторной авторизации.

Замечу, что нет метода аутентификации, который бы гарантировал факт владением номера. СМС вообще крайне не рекомендуется к использованию для аутентификации.
В приведенных примерах вы доказываете факт владения закрытым ключом (на смартфоне, на аппаратном носителе или еще на чем-то), что и является фактором.
Они там вроде дают 20 портов на реальном IP.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity