Двухфакторная аутентификация на сайте с использованием USB-токена. Теперь и для Linux

  • Tutorial

В одной из наших предыдущих статей мы рассказывали про важность двухфакторной аутентификации на корпоративных порталах компаний. В прошлый раз мы продемонстрировали, как настроить безопасную аутентификацию в web-сервере IIS.

В комментариях нас просили написать инструкцию для самых распространенных web-серверов под Linux — nginx и Apache.

Вы просили — мы написали.

Что надо, чтобы начать?


  • Любой современный дистрибутив Linux. Я выполнял тестовую настройку в MX Linux 18.2_x64. Это конечно не серверный дистрибутив, но для Debian вряд ли будут какие-то отличия. Для других дистрибутивов могут слегка различаться пути до библиотек\конфигов.
  • Токен. Мы продолжаем использовать модель Рутокен ЭЦП PKI, которая идеально подходит по скоростным характеристикам для корпоративного применения.
  • Для работы с токеном в Linux необходимо установить следующие пакеты:
    libccid libpcsclite1 pcscd pcsc-tools opensc


Выписывание сертификатов


В предыдущих статьях мы опирались на то, что сертификаты сервера и клиентов будут выписываться с помощью Microsoft CA. Но раз уж мы настраиваем все в Linux, то заодно расскажем про альтернативный способ выписывания этих сертификатов — не покидая Linux.
В качестве CA будем использовать XCA (https://hohnstaedt.de/xca/), который доступен в любом современном дистрибутиве Linux. Все действия, которые мы будем совершать в XCA можно сделать и в режиме командной строки с помощью утилит OpenSSL и pkcs11-tool, но для большей простоты и наглядности в этой статье мы их приводить не будем.

Начало работы


  1. Устанавливаем:

    $ apt-get install xca
  2. И запускаем:

    $ xca
  3. Создаём нашу базу данных для CA — /root/CA.xdb
    Мы рекомендуем хранить базу данных Certificate Authority в папке, куда есть доступ только у администратора. Это важно для защиты закрытых ключей корневых сертификатов, которые используются для подписывания всех остальных сертификатов.

Создаём ключи и сертификат root CA


В основе инфраструктуры открытых ключей (PKI) лежит иерархическая система. Главным в этой системе является корневой центр сертификации или root CA. Его сертификат и надо создать в первую очередь.

  1. Создаём для CA закрытый ключ RSA-2048. Для этого на вкладке Private Keys нажимаем New Key и выбираем соответствующий тип.
  2. Задаём имя для новой ключевой пары. Я её назвал — CA Key.
  3. Выписываем сам сертификат CA, с использованием созданной ключевой пары. Для этого переходим на вкладку Certificates и нажимаем New Certificate.
  4. Обязательно выбираем SHA-256, потому что использование SHA-1 уже не может считаться безопасным.
  5. В качестве шаблона обязательно выбираем [default] CA. Не забудьте нажать на Apply all, иначе шаблон не применяется.
  6. На вкладке Subject выбираем нашу ключевую пару. Там же вы можете заполнить все основные поля сертификата.


Создаём ключи и сертификат https-сервера


  1. Аналогичным образом создаём для сервера закрытый ключ RSA-2048, я его назвал — Server Key.
  2. При создании сертификата выбираем, что сертификат сервера необходимо подписать на сертификате CA.
  3. Не забываем выбрать SHA-256.
  4. В качестве шаблона выбираем [default] HTTPS_server. Жмём на Apply all.
  5. После чего на вкладке Subject выбираем наш ключ и заполняем нужные поля.


Создаём ключи и сертификат для пользователя


  1. Закрытый ключ пользователя будет храниться на нашем токене. Для работы с ним необходимо установить PKCS#11 библиотеку с нашего сайта. Для популярных дистрибутивов мы распространяем готовые пакеты, которые лежат тут — https://www.rutoken.ru/support/download/pkcs/. У нас также есть сборки для arm64, armv7el, armv7hf, e2k, mipso32el, которые можно взять в нашем SDK — https://www.rutoken.ru/developers/sdk/. Кроме сборок для linux также есть сборки для macOS, freebsd и android.
  2. Добавляем новый PKCS#11 Provider в XCA. Для этого идём в меню Options на вкладку PKCS#11 Provider.
  3. Жмём Add и выбираем путь до библиотеки PKCS#11. В моём случае это \usr\lib\librtpkcs11ecp.so.
  4. Нам понадобится отформатированный токен Рутокен ЭЦП PKI. Скачиваем утилиту rtAdmin — https://dev.rutoken.ru/pages/viewpage.action?pageId=7995615
  5. Выполняем

    $ rtAdmin -f -q -z /usr/lib/librtpkcs11ecp.so -u <PIN-код пользователя>
  6. В качестве типа ключа выбираем — ключ RSA-2048 на Рутокен ЭЦП PKI. Я назвал этот ключ Client Key.

  7. Вводим PIN-код. И ждём завершения аппаратной генерации ключевой пары

  8. Сертификат для пользователя создаём по аналогии с сертификатом сервера. На этот раз выбираем шаблон [default] HTTPS_client и не забываем нажать Apply all.
  9. На вкладке Subject вводим информацию о пользователе. На запрос о сохранении сертификата на токен отвечаем утвердительно.

В итоге на вкладке Сертификаты в XCA должна получиться примерно такая картинка.


Этого минимального набора ключей и сертификатов достаточно для того, чтобы приступать к настройке непосредственно серверов.

Для настройки нам необходимо выполнить экспорт сертификата УЦ, сертификата сервера и закрытого ключа сервера.

Для этого надо выбрать нужную запись на соответствующей вкладке в XCA и нажать Export.

Nginx


Как установить и запустить nginx-сервер, писать не буду — на эту тему достаточно статей в интернете, не говоря уже об официальной документации. Приступим сразу к настройке HTTPS и двухфакторной аутентификации по токену.

Добавляем в секцию server в nginx.conf следующие строки:

server {
	listen 443 ssl;
	ssl_verify_depth 1;
	ssl_certificate /etc/nginx/Server.crt;
	ssl_certificate_key /etc/nginx/ServerKey.pem;
	ssl_client_certificate /etc/nginx/CA.crt;
	ssl_verify_client on;
}

Подробное описание всех параметров, касающихся настройки ssl в nginx можно найти тут — https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_client_certificate

Я лишь коротко опишу те, которые сам задал:

  • ssl_verify_client — указывает, что необходимо проверить цепочку доверия к сертификату.
  • ssl_verify_depth — определяет глубину поиска доверенного корневого сертификата в цепочке. Так как у нас сертификат клиента сразу подписан на корневом сертификате, то и глубина задана — 1. Если сертификат пользователя подписывается на промежуточном CA, то в этом параметре необходимо указать 2, и так далее.
  • ssl_client_certificate — указывает путь до доверенного корневого сертификата, который используется при проверке доверия к сертификату пользователя.
  • ssl_certificate/ssl_certificate_key — указывают путь до сертификата/закрытого ключа сервера.

Не забываем выполнить nginx -t, чтобы проверить, что в конфиге нет опечаток, а все файлики лежат где надо и так далее.

И собственно всё! Как видите настройка очень простая.

Проверяем работу в Firefox


Раз уж мы всё полностью делаем в Linux, то будем считать, что и наши пользователи тоже работают в Linux (если у них Windows, то смотрите инструкцию по настройке браузеров в предыдущей статье.

  1. Запускаем Firefox.
  2. Попробуем в начале зайти без токена. Получаем вот такую картинку:

  3. Заходим на about:preferences#privacy, и идём в Security Devices…
  4. Жмём Load, чтобы добавить новый PKCS#11 Device Driver и указываем путь до нашей librtpkcs11ecp.so.
  5. Для проверки того, что сертификат видится можно зайти в Certificate Manager. Отобразится запрос на ввод PIN-кода. После корректного ввода можно проверить, что на вкладке Your Certificates появился наш сертификат с токена.
  6. Теперь заходим с токеном. Firefox предлагает выбрать сертификат, который будет выбран на сервер. Выбираем наш сертификат.

  7. PROFIT!


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

Apache


Так же как и с nginx проблем с установкой apache ни у кого не должно возникнуть. Если же вы не знаете, как установить этот web-сервер, просто воспользуйтесь официальной документацией.

А мы приступаем к настройке нашего HTTPS и двухфакторной аутентификации:

  1. Для начала необходимо активировать mod_ssl:

    $ a2enmod ssl
  2. А затем включить настройки HTTPS сайта по умолчанию:

    $ a2ensite default-ssl
  3. Теперь редактируем файл конфигурации: /etc/apache2/sites-enabled/default-ssl.conf:

        SSLEngine on
        SSLProtocol all -SSLv2
    
        SSLCertificateFile	/etc/apache2/sites-enabled/Server.crt
        SSLCertificateKeyFile /etc/apache2/sites-enabled/ServerKey.pem
    
        SSLCACertificateFile /etc/apache2/sites-enabled/CA.crt
    
        SSLVerifyClient require
        SSLVerifyDepth  10

    Как видите, названия у параметров практически совпадает с названиями параметров в nginx, поэтому пояснять я их не буду. Опять же кому интересны подробности — добро пожаловать в документацию.
    Теперь перезапускаем наш сервер:

    $ service apache2 reload
    $ service apache2 restart


  4. Как видите настроить двухфакторную аутентификацию на любом веб-сервере, что в Windows, что в Linux дело одного часа максимум. А настройка браузеров занимает около 5 минут. Многие считают, что настройка и работа с двухфакторной аутентификацией это сложно и непонятно. Надеюсь наша статья хоть немного, но развенчивает этот миф.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Нужна ли инструкция по настройке работы TLS с сертификатами на ГОСТ 34.10-2012:

  • 84.6%Да, TLS-ГОСТ очень нужен44
  • 15.3%Нет, настройка с ГОСТ-алгоритмами не интересна8
«Актив»
63,56
Компания
Поделиться публикацией

Комментарии 27

    +3
    Специально купил себе RuToken ЭП 2.0 микро «на побаловаться».
    Было очень интересно посмотреть, как он запустится под Linux.
    Запустился по инструкции с первого раза и даже определяется на nalog.ru
    image

    К сожалению, для реальной работы этого оказалось недостаточно. После получения сертификата ЭП требуется установка приптопровайдера и дополнительных приложений, которые работают только под Windows.

    P.S. Поэтому настроить можно, это действительно круто, но бесполезно по независящим от вас причинам.

    P.P.S. И кстати, прости меня родной Аладдин, с Рутокеном я справился гораздо проще и быстрее.
      +2
      Мы сейчас как раз активно работаем над тем, чтобы Рутокен ЭЦП 2.0 работал с личным кабинетом юр. лица в налоговой без криптопровайдера. Так что следите за нашими анонсами.
        +1
        rsashka, с налоговой все взлетит, если пойти в кабинет ИП, а не Юрлица. Попробуйте, если будет такая возможность.
        Ну а с юрлицами тоже все будет, но попозже.
          0
          Мне было нужно как раз с юрлицами.
          А токен чуть позже попробую заюзать на fips.ru
          Там как раз новый кабинет сделали.
        0
        После такой аутентификации сервер уже знает какой пользователь на него зашёл и можно больше не делать никаких дополнительных окон для проверки, а сразу пускать пользователя в его личный кабинет.
        Не совсем понятно, откуда сервер будет знать, кто на него вошел? Понятно, что он получит сертификат из ключа, как предъявленный документ. Но ведь информация в сертификате еще должна как-то привязаться к аккаунту пользователя, нет? А что, если данные пользователя не зарегистрированы в системе? Авторегистрация? Как тогда определить права и роли автоматически?
        И где двухфакторная авторизация? Пин-код ключа — это не фактор вроде.
          0
          Сервер получает информацию в сертификате, которая как вы правильно заметили должна быть привязана к аккаунту. Я в этой статье больше пишу про корпоративные порталы (смотрите статью на которую я ссылаюсь в начале). В корпоративных порталах авторегистрация редко предусмотрена, а права и роли задаются, например, при приеме на работе.
          Можно сделать и вариант с авторегистрацией, если у вас все пользователи по умолчанию с одними правами. А повышать их уже по запросу. Тоже весьма типичный сценарий.
          Что касается двухфакторности. Ключ к сертификату хранится на токене в неизвлекаемом виде, доступ к ключу можно получить только зная PIN-код. Выполнить вход под своей учеткой без токена не получится. Это первый фактор, так называемый фактор владения. А PIN-код — это второй фактор, фактор знания.
            +1
            Спасибо, понял по сертификату.
            По факторам получается, если хранить ключ в сейфе под кодовым замком, то получаем четырехфакторную идентификацию? (плюс код сейфа и сам сейф как фактор владения).
            Только на стороне портала (сервера) идентификация всё равно однофакторная остаётся — по сертификату и всего. Мне казалось, многофактор — это когда сам сервер проверяет идентификацию по нескольким каналам, а не заворачивание идентификационных данных в кучу обёрток.
              0
              Про многофакторную аутентификацию ведется масса холиваров, нередко замешанных на маркетинговом буллшите. Часто путают 2-факторную аутентификацию, 2-этапную верификацию, многоканальную аутентификацию и т.д.
              С моей точки зрения в такой ситуации следует полагаться на авторитетные официальные источники. Например вот:
              csrc.nist.gov/glossary/term/Multi_Factor-Authentication
                0
                Благодарю! Похоже, я тоже попался на эту удочку.
                И хотя описанная в статье схема полностью соответствует букве стандартов, для оператора сервера существует ненулевой риск сваливания в однофактор (если пользователь отменит запрос пин-кода или сделает его легко подбираемым).
                Описанная схема работы как раз и напоминает маркетинговый треш, когда вроде используется два фактора, но контролю поддаётся только один, и потому для безопасника это не выглядит как два фактора.
                  0
                  Отменить запрос PIN-кода нельзя. И легко подобрать тоже. Многие безопасники смешивают пароли и PIN-коды, а этого делать не стоит. PIN проверяется и блокируется аппаратно. Количество попыток сильно ограничено. Стандартно 10, но можно и 3 поставить. И перебрать даже PIN из 4 цифр за 10 попыток шансов совсем мало. А пользователю эти 4 цифры запомнить просто. Это не сложные пароли из 10 символов, где заставляют вставлять спец. символы, буквы в разных регистрах и так далее.
                    0
                    К сожалению, не могу согласиться.
                    PIN проверяется и блокируется аппаратно. Количество попыток сильно ограничено.
                    Увы, сделать аппаратный дубликат возможно. Потом его заблокировать и сделать еще один и так пока не надоест. То есть количество попыток не ограничено, если выйти в аппаратную плоскость.

                    Плюс к этому — более половины пользователей токенов не меняют заводские пины (личная практика). Если пин 4 цифры — его легко подсмотреть и запомнить хотя бы 3 цифры, а четвертую подобрать за 10 стандартных попыток. На самом деле пины растекаются очень интенсивно, даже от банковских карточек.
                    Вот на самом деле, почему не говорят, что банковская карточка использует двухфакторную аутентификацию? Ведь по сути у неё есть пин, а идентификатор клиента закодирован в чипе, 2 фактора на лицо.
                      +1
                      Сделать аппаратный дубликат защищенного токена у вас вряд ли получится. А если и получится, то цена вопроса будет в миллионах и не рублей. Это далеко не так просто, как вам кажется.
                      В PIN-коде можно и буквы использовать. Тогда за 10 попыток уже не получится. Плюс надо же еще токен украсть. А это не так просто и самое главное очень заметно. Если я, например, ваш пароль узнал, то заметить это только по логам входа получится. А отсутствие физической железки сразу видно.
                      Аутентификацию может использовать сервис. А не карточка. Не говорят — потому что наличие самой карты при оплате в интернете не проверяется. Цифры с карты это не сама карта. А вот в банкомате — полноценная двухфакторная аутентификация.
                        –1
                        Сделать аппаратный дубликат защищенного токена у вас вряд ли получится. А если и получится, то цена вопроса будет в миллионах и не рублей. Это далеко не так просто, как вам кажется.
                        Вот это совсем не так:

                        • Оборудование для самого жесткого вмешательства в аппаратную часть можно прикупить на али за пару килобаксов в комплексе.
                        • На сегодняшний день вроде нет чипов, интегрирующих АЛУ и ПЗУ на разных слоях одной микросхемы. А значит, извлечь и сделать дамп ПЗУ технически несложно.
                        • Сертификация ключей в любом органе (ФСБ, АНБ) подразумевает наличие алгоритмов восстановления ключа по обломкам его микросхем. А это то же самое, что создать дубликат ключа.
                        • Во всех стандартах NISTа попадание ключа в чужие руки расценивается как возможность появления дубликата и такой ключ должен быть максимально быстро заблокирован и при необходимости перевыпущен.

                        А вот в банкомате — полноценная двухфакторная аутентификация.
                        Тоже не факт. Если пин проверяется чипом карты, то это просто однофакторная аутентификация в двух разных сервисах — карта и банк. Реализация зависит от возможностей банкомата.

                        И с рутокенами тоже не факт, что пин проверяет ключ, а не установленное на компьютер ПО производителя — пруф между строк
                          +1
                          Ну раз уж мы решили разобраться глубоко, давайте разберемся.
                          На сегодняшний день вроде нет чипов, интегрирующих АЛУ и ПЗУ на разных слоях одной микросхемы.

                          Ошибаетесь. Более того технологий защиты у чипов предостаточно.

                          Сертификация ключей в любом органе (ФСБ, АНБ) подразумевает наличие алгоритмов восстановления ключа по обломкам его микросхем

                          Опять же ошибаетесь. Восстановление ключа для ФСБ имеет смысл при шифровании, а не подписи. И добиваются этого обычно другими способами, а не восстановлением по обломкам.

                          Конечно, если ключ был украден или утерян он должен быть заблокирован. Для этого и нужен PKI. Но тут скорее защищаются от того, что PIN тоже был скомпрометирован каким-то способом.

                          В Рутокене PIN проверяет ключ. Даже в том случае, если используется хранение контейнеров КриптоПро на токене. В том пруфе на который вы ссылаетесь, человек путает 2 понятия — неизвлекаемость и неэкспортируемость.
                            0
                            Ошибаетесь. Более того технологий защиты у чипов предостаточно.
                            Можете привести маркировку чипа, у которого ПЗУ находится под/поверх АЛУ? Не рядом, не на другом конце чипа, а именно в другом слое. Гугл не находит. Находит только те, где в одной плоскости компоновка. Я бы рад ошибаться, но пока не вижу опровержений.
                            Восстановление ключа для ФСБ имеет смысл при шифровании, а не подписи.
                            Не уверен, что мы можем оценивать и обсуждать мотивы подобных организаций.
                            В Рутокене PIN проверяет ключ. Даже в том случае, если используется хранение контейнеров КриптоПро на токене.
                            В Рутокене ПЗУ в кристалле процессора сделано? Подкинуть дубль файловой системы невозможно?
                            В том пруфе на который вы ссылаетесь, человек путает 2 понятия
                            Даже если так, пруф не о том, как извлечь ключ. Пруф о том, что если АЛУ ключа не защищает данные в ПЗУ, то вытянуть их можно от лёгкого до не очень сложного способами.
                            Но даже если защищает, а к ПЗУ есть доступ извне, программатором можно создать/восстановить дамп и АЛУ ничего не будет знать о том, сколько раз уже подбирался пин.

                            Эта тема не повод для спора. Я говорю, что большинство ключей можно скопировать. Вы говорите, что есть ключи, которые нельзя скопировать. Я отвечаю, что возможно на сегодняшний день так и есть, но через некоторое время и к таким ключам будут найдены подходы. Вы соглашаетесь, что нет ничего невозможного в будущем, на смену придут более защищенные ключи, которые в том будущем тоже будет тяжело скопировать. Остаемся при своих мнениях.
                              0
                              Этот спор упирается не в «можно или нельзя», а «сколько это будет стоить».
                              Можно сделать абсолютно все, но некоторые вещи можно сделать либо очень дорого, либо очень долго.
                                0

                                Еще года 4 назад активно занимался карточными технологиями.
                                Участвовал в семинарах Gemalto и NXP. В частности, посвященным аппаратной защите чипов карт от извлечения ключа разными методами. Однако, чипы предназначенные для карт (а токен это по сути чип карты+USB ридер), весьма надежно защищены от различных атак разных методов.
                                (про чипы для GSM карт, речь не идет. Они зачастую дешевле и проще в массе..)


                                И информацию (подробности) о защите (аппаратной и методов безопасного создания приложений карт) и методов взлома в Интернете, Вы особо найдете. Не надо думать что в Интернете есть все.


                                Тоже не факт. Если пин проверяется чипом карты, то это просто однофакторная аутентификация в двух разных сервисах — карта и банк. Реализация зависит от возможностей банкомата.

                                И да… Банкомат по стандартам НЕ работает с off-line PIN. Исключительно on-line PIN через EPP клавиатуру.

                                  0
                                  И да… Банкомат по стандартам НЕ работает с off-line PIN. Исключительно on-line PIN через EPP клавиатуру.
                                  Не все банкоматы одинаковы

                                  Имел возможность наблюдать как вскрываются микросхемы и дампятся микрокоды из интегрированного в кристалл ПЗУ.
                                  Вот даже на Хабре есть статья о препарировании карты Яндекса.

                                  Кажется, ваша вера в защищенность банковских чипов идёт от риторики маркетологов, а не от знания технологий защиты. Верить маркетологам производителей на слово — крайне опасное поведение.
                                  И информацию (подробности) о защите (аппаратной и методов безопасного создания приложений карт) и методов взлома в Интернете, Вы особо найдете. Не надо думать что в Интернете есть все.
                                  Резонно. Как можно найти в Интернет информацию о том, чего нет в природе в принципе?
                                    0
                                    Не все банкоматы одинаковы

                                    Рассуждают люди о том, про что они слышали краем уха. А на это рассуждение мне дают ссылку как пруф. Ага… А ничего что я лет 15 занимаюсь платежными технологиями и как раз у меня стандарты под рукой.


                                    Вот даже на Хабре есть статья о препарировании карты Яндекса.

                                    Еще один дилетант статью опубликовал. "Я тут посмотрел на чип и внешне он выглядит как все остальные чипы. Значит он не защищен".
                                    Мда..


                                    Резонно. Как можно найти в Интернет информацию о том, чего нет в природе в принципе?

                                    Даже комментировать ну буду. Смысл.
                                    Вы действительно считаете, что информация выданную "под роспись" (тип хотя бы коммерческие секреты) всяк имеющий к ней доступ норовит выложить в свободный доступ в Интернете?


                                    Интернет это помойка.
                                    Давать в качестве пруфов такие статьи и особенно диалог в конфе (его немного смешно читать. Как рассуждения людей, которые что то слышали… но все равно нифига точно не знают).


                                    Кажется, ваша вера в защищенность банковских чипов идёт от риторики маркетологов, а не от знания технологий защиты.

                                    Специализированные семинары по безопасному программированию апплетов карт и способах защиты ведут не маркетологи, а инженеры компаний, которые непосредственно этим занимаются. К слову..

                                      0
                                      Михаил, предлагаю направить беседу в конструктивное русло. Опыта у нас с вами у каждого предостаточно. Судя по различиям в мнениях, опыт у нас разный. Хотелось бы прояснить ситуацию, а не видение этой ситуации с высоты двух разных опытов.

                                      Вы говорите, что у вас есть под рукой Стандарт, который регламентирует использование в банкоматах только онлайн проверки ПИНа. Но это всего лишь рекомендации, а не закон, которому необходимо безоговорочно следовать. Поэтому, даже если этот Стандарт распространяется на РФ, банки не обязаны ему следовать. И холивар в пруфе как раз показывает, что некоторые банки плевать хотели на Стандарт, которого придерживались вы.
                                      К слову, вы пока не обозначили, что это за Стандарт у вас под рукой, к чему относится, как называется и где используется. У меня если поискать, тоже найдётся с десяток разных стандартов под рукой, даже таких, которые будут противоречить друг другу. Поэтому хотелось бы знать номер, дату и орган принятия Стандарта, о котором вы говорите.

                                      Специализированные семинары по безопасному программированию апплетов карт и способах защиты ведут не маркетологи, а инженеры компаний, которые непосредственно этим занимаются.
                                      «Безопасное программирование» — термин вызывает смешанные чувства. Заставляет думать, что существует и «опасное программирование апплетов карт», раз на эту тему организовываются курсы и семинары.
                                      В если добавить к этому, что на этих курсах никто не дает подписку о том, что программировать будет «безопасно», можно предположить, что большинство апплетов в картах представляют собой опасные для пользователя программы, что с одной стороны заставляет производителей проводить обучающие курсы для разработчиков, а с другой ставят под удар пользователей электронного пластика.
                                        0
                                        Вы говорите, что у вас есть под рукой Стандарт, который регламентирует использование в банкоматах только онлайн проверки ПИНа. Но это всего лишь рекомендации, а не закон, которому необходимо безоговорочно следовать.

                                        1. Сложно сказать является ли сертификационные тесты EMV(co) (обязательны для прохождения перед сертификацией в Visa & MC & МИР & UP) "законом". Но в них предусмотрен ТОЛЬКО on-line PIN.
                                        2. В правилах платежных систем прописано
                                          использование только on-line PIN.
                                          Если Вам нужна обязательно сылка в Интернет
                                          (https://www.mastercard.us/en-us/issuers/products-and-solutions/grow-manage-your-business/payment-innovations/chip-emv.html "Online PIN only")

                                        Банки сами софт ATM не пишут и не сертифицируют.
                                        Предположение, что какой то банк, будет нарушать правила платежных систем, скрывая это при обязательной сертификации (которая нехило стоит) своего процессинга и нарываться на штрафные санкции ПС…
                                        Ну разве, что он выпускает свою локальную ПС со своими локальными картами и делает там что угодно.


                                        «Безопасное программирование» — термин вызывает смешанные чувства. Заставляет думать, что существует и «опасное программирование апплетов карт», раз на эту тему организовываются курсы и семинары.

                                        Да. Существует "опасное" программирование.
                                        Просто для иллюстрации (я не собираюсь все рекомендации описывать).
                                        Нельзя использовать boolean флаги в критических местах. Рекомендуется


                                         private static final short TRUE = (short) 0xA5A5;
                                         private static final short FALSE = (short) 0x5A5A;
                                        ...
                                               is_critical_apdu = TRUE;
                                        

                                        Был продемонстрирован пример, когда манипуляций напряжения и освещения УФ апплет вел себя не так как задуманно.
                                        Так что, не все так просто.


                                        По правилам, апплеты платежных приложений проходят penetration тесты в сертфикационных лабораториях. И если написаны без учета многих подобных тонкостей, то не пройдут сертификацию по факту.
                                        Стоимость и сертификации логики и прочих сертификаций просто не сравнима со стоимостью создания апплета.
                                        Ничего не знаю, про Рутокен и прочее. Знаю только про платежные апплеты и требования сертификации ПС.

                                          0
                                          Сложно сказать является ли сертификационные тесты EMV(co) (обязательны для прохождения перед сертификацией в Visa & MC & МИР & UP) «законом». Но в них предусмотрен ТОЛЬКО on-line PIN.
                                          Я не смог найти в требованиях EMV положения о недопустимости оффлайн-пина. Возможно это как раз требования последних редакций, которые тяжело найти.
                                          В правилах платежных систем прописано
                                          использование только on-line PIN.
                                          Если Вам нужна обязательно сылка в Интернет
                                          (https://www.mastercard.us/en-us/issuers/products-and-solutions/grow-manage-your-business/payment-innovations/chip-emv.html «Online PIN only»)
                                          Не считается. Это объявление о продаже тестовых карт, среди характеристик которых поддержка только онлайн-пина. Это не правило, это просто обрезанная версия карты для тестов и девелопмента.
                                          Ну разве, что он выпускает свою локальную ПС со своими локальными картами и делает там что угодно.
                                          Это тоже аргумент не в вашу пользу. Если банк может выпустить свою карту с оффлайн пином, то предположение, что пин проверяется всегда онлайн уже будет неверным. Зачем продолжать настаивать на этом? С точки зрения держателя пластика — на любой карте банка у него лежат его деньги.
                                          Был продемонстрирован пример, когда манипуляций напряжения и освещения УФ апплет вел себя не так как задуманно.
                                          Так что, не все так просто.
                                          Похоже, всё-таки инженеры вели семинары, а не маркетологи. Нам эти вещи еще в институте рассказывали, многое уже позабылось )
                                          Ничего не знаю, про Рутокен и прочее. Знаю только про платежные апплеты и требования сертификации ПС.
                                          Требования к апплетам продиктованы стремлением защиты финансовой транзакции. Апплеты не могут знать, кто их использует в данный момент. Как и банк не может быть уверен, что операцию совершает именно владелец денег.
                                          Если операция была совершена неправомерно, ответственность несет тот оператор, который принял карту. Поэтому платежные шлюзы стараются защититься, обязывая свои банкоматы проверять пин онлайн. В интернет еще 3д секури придумали, дополнительный способ авторизации платежа, т.к. у онлайн шлюзов нет возможности проверить пин.
                                          Тем не менее, не все операции проходят тщательную проверку. Мне приходилось пользоваться онлайн сервисами, которые кроме номера карты и срока ничего не просили, даже cvv. Причем это была карта, покрытая 3д секурой с ног до головы.

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

                                          Например, если пишут «двухфакторная аутентификация на сайте», то логично предположить, что именно сайт проверяет 2 фактора. А если сайт проверяет только сертификат, а чтобы получить сертификат человеку нужно ввести пин в токен, то это скорее «двухэтапная», а не «двуфакторная» аутентификация.
              0

              Один из вариантов (например для REST Web API) настройки nginx — это что ни будь типа


              server {
                  listen 443 ssl;
                  ssl_verify_depth 1;
                  ssl_certificate /etc/nginx/Server.crt;
                  ssl_certificate_key /etc/nginx/ServerKey.pem;
                  ssl_client_certificate /etc/nginx/CA.crt;
                  ssl_verify_client on;
              
                      location / {
                      proxy_set_header X-TLS-iDN $ssl_client_i_dn;
                      proxy_set_header X-TLS-sDN $ssl_client_s_dn;
                     }
               }

              А уже сервис, принимающий запрос, понимает по атрибутам клиентского сертификата — кто конкретно пришел и какие у него права.
              Чисто для иллюстрации пример (можно и другие извращения с $ssl_client_.. придумать)


              Но вообще, USB токен для захода на сайт через браузер ИМХО не удобно. Уж лучше брелок с OTP паролем (как альтернатива SMS/Push), как второй фактор к обычному паролю (ну или самый дешевый вариант — OTP приложение под смартфон).


              А вот для аутентификации программных клиентов — аппаратный токен — само то..


              И да… Для безопасности бы, не помешало бы изменить ssl_session_timeout с 5m по умолчанию, на что то более разумное (меньшее значение)

              +1

              Все хорошо пока есть Windows и когда можно использовать любую Linux. Подскажите пожалуйста как обстоят дела с Astra Linux и планируется ли сертификация ФСТЭК? Уж больно часто приходится работать с гос.заказчиками и им очень хочется ЭЦП)

                0
                C Astra Linux дела обстоят хорошо. Прошли очередной раунд тестирования на совместимость с Astra Linux Common Edition (версии 1.10,1.11,2.12) и Special Edition (версии 1.4,1.5).
                Сертификат ФСТЭК на ПАК Рутокен есть и действует. Так что гос.заказчиков можно успокоить. Если есть какие-то сомнения, задавайте вопросы. Если надо будет потестировать какую-то конкретную конфигурацию — обращайтесь, рассмотрим.
                  +1
                  Отлично. Про Common Edition я и не сомневаюсь, что работает, как раз интересно было про SE, но вы меня опередили ответом). А можно немного подробнее про Special Edition (1.5, либо 1.6). Для рутокена нужны драйвера — где можно взять сертифицированные? Или нужно делать отдельный запрос и осуществлять закупку? Просто как раз-таки стоит задача — Контроллер домена, авторизация, документооборот, ЭЦП…
                    0
                    Для Astra SE мы рекомендуем брать токены из семейства Рутокен ЭЦП 2.0. Это CCID устройства, поэтому драйверы есть в самой ОС (в Astra SE тоже есть и все успешно работает). Может понадобится библиотека PKCS11 — она доступна как на нашем сайте, так и поставляется вместе с сертифицированной версией токена на диске.

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое