В предыдущем своем топике «Пароли — это прошлый век, в дальнейшем требуются новые методы авторизации и хранения личных данных» я рассказывал существующие проблемы использования паролей в сети и методы построения авторизации с использованием ЭЦП. В данной топике я хочу привести подробную схему авторизации в интернете с использованием ЭЦП, обеспечивающий высокий уровень безопасности от мошенников и киберпреступников.
Приводимая здесь схема будет также рассматриваться в рамках модели авторизации с использованием единого центра авторизации для любых интернет ресурсов, подробно описанных в предыдущей статье. Поэтому для лучшего понимания процесса приведу небольшую цитату из прошлой статьи:
С точки зрения безопасности лучшую защиту на сегодняшний день могут предоставить использование USB-токенов, защищенных пин кодом из 3-х попыток и (опционально) встроенным сканером отпечатков. В процессе авторизации можно использовать передачу на единый центр авторизации цифровую копию биометрического отпечатка, подписанного персональной цифровой подписью (криптографического преобразования закрытым ключом). При этом каким либо образом вытащить из USB-токена цифровую копию биометрического отпечатка и используемые ключи не возможно, а расшифровать передаваемые данные может только тот, кто имеет вторую пару открытого ключа. Для защиты от перехвата при каждой авторизации передаваемые данные должны быть уникальными, например при каждой авторизации вместе с копией биометрического отпечатка зашифровывать также случайную строку и значение счетчика успешных авторизаций. Еще лучше, если заранее созданы и сохранены персональные наборы открытых и закрытых ключей на каждый день в течении всего срока использования ключа (например, в течении 10-20 лет) а токен при авторизации сверяет дату со своими серверами и подписывает данные необходимым ключом на текущую дату. При этом открытые ключи также должны быть надежно защищены и находится только на сервере авторизации (например, во внутреннем сервере единого центра авторизации проверяющего достоверность полученных данных, но не имеющего прямого выхода к сети интернет).Каждый USB-токен должен иметь свой уникальный номер. А при генерации пары открытых/закрытых ключей номер USB-токена должна быть сохранена в связке с этими ключами. Это позволит серверу авторизации по номеру токена сопоставить необходимые публичные ключи в процессе авторизации.
Итак, рассмотрим как должен происходить процесс авторизации:
1) Пользователь шифрует цифровую копию биометрического отпечатка + значение счетчика авторизации + случайную строку своим USB-токеном. К полученным данным добавляется уникальный номер USB-токена и направляется на веб-сервер для авторизации.
2) Веб-сервер получает сообщение пользователя и добавляет в него свой уникальный номер токена. Полученные данные направляются в единый центр авторизации.
3) Сервер центра авторизации расшифровывает полученное сообщение используя открытый ключ пользователя. Если в итоге расшифровки сервер получает правильную цифровую копию биометрического отпечатка пользователя, то сообщение зашифровано подлинным ключом. При успешном результате случайная строка пользователя также сохраняется на сервере в связке с текущим порядковым номером авторизации.
4) Свой положительный вердикт + случайную строку пользователя сервер авторизации шифрует используя открытый ключ веб-сервера и направляет обратно ответным сообщением. При отрицательном вердикте сервер шифрует ответное сообщение используя новую случайную строку.
5) Веб-сервер расшифровывает полученное сообщение своим токеном и получает положительную или отрицательную команду на авторизацию.
6) При успешной авторизации веб-сервер возвращает пользователю в открытом виде его случайную строку, Полученная строка сверятся с отправленной строкой и при совпадении USB-токен увеличивает счетчик успешных авторизации на одну единицу.
Следует учесть, что значение счетчика успешных авторизаций в USB-токене ни при каких условиях не может быть больше, чем на сервере. А если значение меньше, то сервер должен сверить полученную случайной строку пользователя с сохраненной строкой используя указанный номер авторизации. Это позволит легко выявить нарушителя. Если эти строки совпадут, то идет попытка фальсификации с отправкой перехваченного трафика от предшествующий авторизации, а значит сервер должен запретить доступ, оперативно предупредить об этом специалистов безопасности и занести IP адрес нарушителя в список отслеживаемых. Если эти строки разные, то во время прошлой авторизации веб-сервер не вернул пользователю его случайную строку, значит сервер должен разрешить доступ, уменьшить карму виновного веб-сервера и добавить в случайную строку пользователя специальный код для корректировки счетчика успешных авторизаций.
Преимущества:
1) Открытую и закрытую пару ключей можно менять хоть каждый день, если токены умеют в зависимости от даты использовать разные ключи.
2) Перехватывать трафик бесполезно, если при каждой авторизации вместе с биометрическими данными шифруется показание счетчика успешных авторизаций и случайная строка. Проверка показания счетчика и случайной строки позволит определить фальсификацию.
3) Попытка переадресовать процесс авторизации на фальшивый сервер то же ничего не дает, если открытая пара ключей только в центре авторизации и надежно защищена. Фальшивый сервер не сможет вернуть свой вердикт, зашифрованное публичным ключом веб-сервера.
4) Никакие уязвимости применяемых скриптов авторизации на сайтах не могут скомпрометировать процесс авторизации.
5) Взлом веб сервера не позволит получит биометрических отпечатков и цифровых подписей пользователей. По сути в этой схеме каждый участник авторизации заинтересован только в собственной безопасности и не несет ответственности за безопасность другого участника.
6) Если значения счетчиков успешных авторизаций не совпадают, то сервер может точно определить пытаются ли скомпрометировать авторизацию или во время прошлой авторизации веб-сервер не вернул пользователю его случайную строку.
7) По сути защищенное SSL соединение в данном случае не требуется, потому что все конфиденциальные данные передаются зашифрованном виде. Но всё же использование защищенного протокола SSL еще больше увеличивает степень безопасности.
Недостатки:
1) Используется 2-х кратное шифрование и расшифровывание данных, необходимых для подтверждения подлинность каждого из участников.
2) Разрядность ключей должна быть по возможности не большим, чтобы не сильно загружать сервера в процессе авторизации.
3) Токены, используемые на веб-серверах должны обеспечивать высокую скорость расшифровки данных. Особенно если у сайтов высокий уровень посещаемости, то вместо использования USB-токенов нужно предусмотреть высокопроизводительные платы расширения или надежные программные токены (для сайтов расположенных на виртуальных серверах).
4) Центры авторизации должны быть построены из высокопроизводительных кластеров, «непотопляемых» к DDoS атакам.
Текст переработан и исправлен 11 марта 2015 г.
