Вы здесь

Под капотом Emercoin. Часть 4. emcSSL. Децентрализованная беспарольная система безопасности

Как всем известно, наиболее распространённым способом аутентификации пользователя является пароль. Эта практика имеет исторические корни, и основана на парадигме получения доступа к доверенному устройству (компьютеру). При этой парадигме, устройству полностью доверяют, а устройство идентифицирует пользователя паролем.

Под капотом Emercoin. Часть 4. emcSSL. Децентрализованная беспарольная система безопасности

Этот подход хорошо работал в прошлом, когда компьютер был изолирован от сети, и просто так никакой троян не мог перехватить пароль, а даже если б и мог бы – то никуда б особо его не мог использовать, ибо зачем пароль трояну, который уже и так в компьютере вовсю орудует?

Эта парадигма, идеальная для персональных компьютеров, уже стала давать слабину в многопользовательских системах, где взломщик, имея непривилегированный доступ, запускал на своём терминале программу, симулирующую стандартный логин, и таким образом оставлял ловушку для следующего оператора. Такие системы имели ограниченную популярность в студенческой среде 80-х, когда особо пронырливый студент вместо завершения сессии оставлял после себя такую вот ловушку в компьютерном классе. Эдакий прообраз современного фишинга.

И эта парадигма уже не удовлетворяет условиям безопасности современных систем, где недоверенным может быть и устройство, и сетевое соединение, и даже сервер.

Недавний пример – захват домена blockchain.info с последующим выуживанием паролей пользователей фальшивым сайтом и хищением биткоинов со счетов пользователей. 8 миллионов учётных записей оказались потенциально скомпрометированы. В этом инциденте сам сайт не был взломан, но была взломана сетевая инфраструктура, что и сделало возможным «выуживание» паролей фальшивым сайтом.

Известны также инциденты, связанные со взломом популярных сайтов и «сливом» оттуда базы данных пользователей, включая и хеши паролей. Например – несколько громких инцидентов последнего времени: Adultfriendfinder – украдено 412 миллионов учётных записей.

OPM (база государственных служащих США) – украдено 22 миллиона записей.

Ну и отечественные хакеры тоже не отстают – взлом крупнейшей российской социальной сети «вконтакте» скомпрометировал 171 миллион учётных записей.

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

Глядя на текущее бедственное положение дел, встают два извечных русских вопроса, сформулированные ещё Герценым и Чернышевским:

  • Кто виноват?
  • Что делать?

Кто виноват?

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

Ключевой недостаток парольной аутентификации заключается в том, что оператор, предъявляя устройству пароль, полностью раскрывает свой секрет. Для доверенного устройства — это не страшно. Но в случае не-доверенного устройства, или вмешательства злоумышленника, последний, перехватив пароль, овладевает секретом пользователя, и получает полный доступ к его учётным записям. Другими словами, пользователь, единожды раскрыв пароль, становится беззащитным против злонамеренных действий «с той стороны монитора». А так как вряд ли какое-либо устройство в современном сетевом мире можно считать доверенным, то хищение паролей становится неизбежным и систематическим. Попытки же улучшить эту систему принуждением пользователей к частой смене паролей, да не простых, а с всякими вывертами – раздражает пользователей, создаёт им массу проблем, и по сути является паллиативным решением. Таким же паллиативным решением являются современные системы двухфакторной авторизации на основе СМС, в которых требуется подтвердить владение ещё одним недоверенным устройством, подключённым к ещё одной недоверенной сети.

Вторым ключевым недостатком является централизация учётных записей, то есть хранение их в огромных базах. Если бы в учётной записи содержался бы только UserID, то «слив» такой базы не приводил бы к катастрофе – в конце концов, просто UserID не является секретной информацией. Но в базах, наряду с UserID, хранится и другая информация, разглашению не подлежащая – например хеши паролей. Да, хеш конечно же – не пароль. Но имея соответствующий словарь, по хешам удаётся восстановить значительную часть паролей слитой базы, порядка трети. Ну и эвристические атаки на слабые пароли тоже кое-что добавляют. Ну а далее – секрет известен, и ключи в руках злоумышленника.

Резюмируя вышесказанное – имеем:

  • Парольную систему с полным раскрытием секрета, не соответствующую современным требованиям.
  • Централизованное хранение данных пользователей, что приводит к катастрофическим последствиям в случае компрометации базы данных.

Следует заметить, что выполнение обоих вышеуказанных условий делает взлом практически полезным для злоумышленника.

Так, если бы из слитой базы невозможно было бы восстановить пароли, то её ценность была бы весьма сомнительной (хотя персональные данные и могут представлять интерес тоже), так как получить доступ к учётной записи всё равно было бы невозможно.

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

В общем – виноваты мы все, так как используем архитектуру, не соответствующую современным требованиям. И ленивые владельцы сайтов традиционной ориентации, и пользователи, которые соглашаются такими системами пользоваться.

Что делать?

Как было замечено выше, систематическая компрометации базы пользователей имеет смысл в случае применения обоих механизмов устаревшей архитектуры – паролей(a) с полным раскрытием секрета, и централизации(b), делающей привлекательным и экономически выгодным хищение базы пользователей с их паролями. Отказ от любого из этих механизмов (а лучше – от обоих сразу) сделает бессмысленными взломы, подобные вышерассмотренным.

Иными словами, необходима новая архитектура аутентификации, которая:

  • a) Не раскрывает секрет пользователя в процессе аутентификации серверу.
  • b) Использует децентрализованное хранение учётных записей. В идеале – сервер должен знать о пользователе только UserID, и ничего более.

Нельзя сказать, что попытки заменить парольную аутентификацию не предпринимались. Так, например, для избегания полного раскрытия секрета пользователя получили ограниченное применение пользовательские SSL-сертификаты. При их использовании серверу предъявляется открытая часть сертификата, а секретный ключ никогда не покидает компьютера пользователя, что решает проблему (a). Но покупка таких сертификатов стоит каких-то денег и сопряжена с хлопотами, вследствие чего такие системы получили весьма ограниченное распространение даже в корпоративном секторе.

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

Долгое время проблема централизации (b) не имела удовлетворительного решения. Однако появление феномена криптовалют и публичного блокчейна, обеспеченного независимым доверием, дало миру инструмент, на основе которого можно построить новую архитектуру аутентификации, удовлетворяющую обоим условиям – (a, b).

На основе этого инструмента такая архитектура была создана, и уже более года находится в эксплуатации. Встречайте героев нашего времени – emcSSL+InfoCard!

Описание архитектуры и механизмов работы обеих систем подробно рассмотрено здесь.

Теперь, смеем надеяться, стал понятен и ответ на извечный вопрос №2.

Ниже будет кратко рассмотрено, как предложенная архитектура решает вопросы (a, b).

emcSSL

Как было указано выше, система клиентских SSL-сертификатов решает проблему полного раскрытия секрета (a). Однако по ряду причин, включая приведённые выше, она не слишком хорошо масштабируется, и широкого распространения не получила.

В системе emcSSL отсутствует центр сертификации, а выпуском сертификатов занимаются сами пользователи. Соответственно, выпуск сертификата – по определению бесплатен. Блокчейн криптовалюты EmerCoin выступает только, как публичное доверенное хранилище хешей SSL-сертификатов и обеспечивает уникальность Serial, который и является уникальным UserID.

Таким образом, в системе emcSSL успешно решены обе проблемы – как неразглашения секрета (a), так и децентрализации (b), что позволяет масштабировать систему до общемирового уровня. Пользователь системы emcSSL получает эдакий «пропуск-вездеход», не зависящий ни от кого, кроме самого пользователя. Ни от «сайта в интернете», ни от сертификатора, ни от кого-либо ещё. Соответственно, в системе невозможны атаки типа рассмотренных выше, которые приводят к массовой компрометации учётных записей, ибо приватные ключи генерируются пользователями, и никогда не покидают их компьютеров, и просто не существует такого центрального места, которое можно скомпрометировать.

В особо важных случаях целесообразно использование emSSL совместно с паролем в рамках двухфакторной авторизации. При этом emcSSL авторизует устройство и обеспечивает безопасный канал связи с сервером, а пароль авторизует оператора.

Ещё стоит упомянуть, что блокчейн-архитектура emcSSL эффективно и безопасно решает проблему отзыва скомпрометированного сертификата и его быстрой замены, чем выгодно отличается от CRL и протокола OCSP, уязвимого к атаке MItM.

InfoCard

Итак, система emcSSL решает все поставленные задачи. Компрометация какого-либо сервера не приводит к компрометации учётных записей, так как пароль ни в какой форме на сервере не хранится. Однако на сервере может храниться дополнительная информация о пользователе, представляющая интерес для злоумышленника, такая как номер телефона, домашний адрес и тп. И по-хорошему, весьма желательно, чтобы этой информации на сервере не хранилось тоже. Некоторые интернет-магазины в целях безопасности так и поступают – дают возможность пользователю делать покупку как «гость», и не сохраняют информации о пользователе после совершения покупки. Подход конечно варварский, но верный. По крайней мере, в плане обеспечения безопасности.

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

Система InfoCard именно так и поступает. Информация о пользователе (инфокарта) создаётся самим пользователем, шифруется и помещается в блокчейн EmerCoin. Когда пользователь логинится по сертификату emcSSL, сертификат содержит ссылку на инфокарту и ключ расшифровки. Сервер в этот момент может извлечь содержимое инфокарты, и использовать его – например взять адрес доставки заказа и заполнить его содержимым поля формы заказа. После совершения покупки, сервер «забывает» содержимое инфокарты – до следующего логина пользователя. В результате, в учётной записи на сервере можно хранить только UserID, и ничего больше. Ни пароля, ни персональных данных пользователя. Не слишком богатый улов для взломщика, не так ли? Соответственно, если с сервера взять нечего – его скорее всего и не будут пытаться взломать.

В дополнение стоит заметить, что система InfoCard, кроме повышения безопасности, повышает удобство пользователя, так как:

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

Примеры применения

Система emcSSL была открыта для публичного использования примерно год назад. В течение этого года система была принята в промышленную эксплуатацию рядом организаций и веб-сайтов. Некоторые из известных нам применений перечислены ниже:

Как начать пользоваться

Для начала мы советуем ознакомиться с детальной статьёй, как всё работает и как начать пользоваться. А на этом видео пошагово показано, как оператор сгенерировал свой SSL-сертификат и разместил его в блокчейне EmerCoin.

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

Если же Вы считаете приемлемым доверить Вашу безопасность внешнему сайту, как это происходит в случае логина через соцсети, то Вы можете бесплатно сгенерировать сертификат online на сайте Криптор, и потом самостоятельно разместить его хеш в NVS. При желании, можно потом сгенерировать ещё один сертификат локально, и обновить его хеш в NVS, что поднимет Вашу безопасность до «классического» уровня.

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

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

За дополнительными консультациями или технической помощью Вы можете обратиться в Emercoin Group или компанию HashCoins.

Категория: 
Криптовалюты
5
Ваша оценка: Нет Средняя: 4.9 (5 оценок)
55241 / 2
Аватар пользователя admin
Публикацию добавил: admin
Дата публикации: чт, 12/08/2016 - 09:08

Что еще почитать:

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

Узда Афанасий

Вопрос назрел господа, а если этот файлик потерян или ОС пользователя была переустановлена ?
то что делать в таком случае ?

чт, 12/08/2016 - 22:20

Анонимус

Если остался шаблон и приватный ключ емеркоина - создайте новый сертификат и обновите существующую запись на блокчейне.

пт, 12/09/2016 - 22:26

paramedic

А почему на вашем сайте когда пытаешься залогиниться через EMCSSL показывается предупреждение "Внимание! В связи с ошибками в некоторых браузерах, авторизация через SSL временно отключена" ?

Хотел потестировать, а тут такое...

пт, 12/09/2016 - 10:34

Анонимус

Присоединяюсь к вопросу.

сб, 12/10/2016 - 02:04

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

пн, 12/12/2016 - 09:47

Gurum

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

пн, 11/26/2018 - 22:08