Прогнозирование полезно, если не сказать «необходимо» для организации среды желательным для Разума (в этом месте на всякий случай напоминаю, что Разум является атрибутом не индивидуума, но популяции) образом. Но. Только в том случае, когда предсказания прогноза (для некоторой заданной в пространстве/Времени точки) достаточно точно соответствуют реально происходящим (вспоминая о претензиях второй сигнальной системы на регуляцию *всех* функций организма — не только наблюдаемым) изменениям среды, а не воплощают желаемое (или какой ещё абсурд).
При этом необходимо учитывать, что категория будущего специфична для уровня второй сигнальной. На уровне первой сигнальной системы (т.е. в мире животных) её не существует.
Ну и, естественно, то, что данная формулировка выводит на первый план задачу верификации некоторого идеального комплекса (в формулировке предисловия — «прогноза», но практически тот же метод применим для любого проекта).
И снова «но». Оторванные от живой практики рассуждения имеют склонность к быстрому вырождению в пустую схоластику. Поэтому начинать нужно с некоторого примера, достаточно близкого к Практике. И не лениться верифицировать.
Недавно, внезапно и совершенно неожиданно встретилась серьёзная заявка на эталон адекватного оппонирования, камрад МысльВслух, хвост обсуждения здесь. И это при последовательном не-согласии с высказываемыми мной утверждениями и ссылками на разбиравшиеся мной сказки!
Но (что особенно) без упоротого отрицания высказываемых мной утверждений.
Сравните с ужимками Александра Мичуринского при решении архи-насущной задачи
на ёлку влезтьне согласиться с высказанным мной утверждением изадницу не ободратьне высказать при этом утверждения, нарушающего правила техники безопасности идеального дискурса и очевидным образом противоречащего наблюдаемой действительности. Как это случилось с воинствующим вендосектантом в примере тематической статьи.
Правда потом, уже в личке, уважаемый оппонент отступил на рубеж «итальянской забастовки» (в науке так справедливо называется акцент на согласовании терминов и определений). Самым же печальным здесь является уже ставшее традиционным не-знание материала руководства господина Брукса (Ф. Брукс «Мифический человекомесяц», в данном случае речь о формализуемости понятия «правильности» решения. И необходимых предпосылках чувства «правильности» в виде определённого комплекса личного опыта).
Драма ситуации заключается в том, что разработчики технологий вынуждены предусматривать включение в массив потенциальных пользователей тех, кому впариваемая сущность по уму вообще ненужна (и кто всяко не будет обременять себя вопросами наработки культуры правильного использования) с использованием представлений минет.жиров об ожиданиях данной аудитории. В результате получается прекрасное (см. например давешнюю статью об антагонизме удобства и безопасности).
В результате имеем то, что:
1. Правильные (!) решения в статье продаванов вредоносного ПО лаборатории касперского вообще не упоминаются (!!!) Об оставлении в ноосфере следов информации об… особенностях реализации поддержки платформ, отличных от «самой распространённой ОС можно даже не мечтать;
Впрочем, данная… особенность неоригинальна. В некоторых виденных мной корпоративных регламентах по «информационной безопасности» та же шляпа.
И лишь изредка, в вердиктах согласования сотрудниками соответствующего подразделения, проскальзывают элементы знания правильного решения…
2. Описанные же решения не только (и даже не столько) добавляют безопасности, сколько открывают широкие возможности для атакующего. См. прекрасный обзор камрада jojo о крайнем эпизоде с уводом учётных записей видных персонажей.
На этом присказку можно считать законченной и пригласить уважаемого оппонента попробовать реконструировать сценарий атаки, аналогичный описанному для [пока увы] гипотетического сценария использования правильной (!) реализации механизма двухфакторной авторизации в web.
Начинать надо, правда, с проблем традиционной реализации [двухфакторной авторизации] и способов их решения (в пакете с побочными эффектами). И, сугубо, следующего витка эволюции. Приведённого в массы, с полагающимся побочным эффектом (см. описание тенденции в памфлете об анагонизме удобства и безопасности по вышеприведённой ссылке).
А там, глядишь, и до формулировки различий профанации от истинной реализации дело дойдёт…
И самой не только вкусной, но и практически интересной части сравнения эксплуатационных характеристик (надеюсь, на АШ *вся* публика грамотная и нет необходимости в развёрнутом доказательстве утверждения того, что основные деньги жизненного цикла системы закопаны в форме издержек в процессе эксплоатации) систем, построенных на профанации и на правильном решении.
Вот ещё один наглядный ключик к проблеме полноты проработки современных инновационных технологий.
Комментарии
начнем с
https://aftershock.news/?q=node/918144
На мой взгляд, здесь сразу можно явно выделить два направления: организационное и техническое.
С точки зрения системы (т.е. с технической) действия пользователя были легитимны. Т.е. все манипуляции с данными для доступа произошли полностью за ее рамками. Получается, что рамки безопасности должны были быть шире: не только целевая система (стограмм, банк и т.д.), но и мобильный оператор. Т.к. описанный способ оказался рабочим, для связки система-оператор он стал фактически уязвимостью нулевого дня.
Кроме того «отягчающим» фактором стало то, что приложение для доступа к целевой системе и средство дополнительного подтверждения доступа (СМС) оказались на одном и том же устройстве, что фактически свело на нет возможность повышения безопасности. Если бы доступ осуществлялся с ПК, а подтверждение приходило по телефону, то перехватить и то, и другое при условии соблюдения хотя бы базовых правил безопасности, конечно было бы гораздо сложнее.
Решение таких проблем также, очевидно, лежит в двух плоскостях.
Организационно каждая из задействованных систем безопасности должна "знать" друг о друге, иначе, не заморачиваясь в лишних трудах, они будут обоюдно принимать любое сообщение, как достоверное. Проблема может быть в том, что тот же стограмм не будет связываться с каждым оператором отдельно, поэтому лишня "нагрузка" ложится на оператора, а это деньги, т.е. вряд ли стоит ожидать активных действий, особенно учитывая, что оператор является всего лишь посредником. То, что операторы начали специальным образом обрабатывать данные от восстановленных сим-карт, это конечно хорошо, но в следующий раз злоумышленники придумают что-то еще. Интересно, насколько банки работают в этом направлении с операторами?
Традиционно к организационным проблемам относится и утечка данных (об абонентах оператора, о клиентах банка и т.д.). Здесь бороться сложно, но можно, основной вопрос, сколько на это будет потрачено усилий. Теоретически можно сделать многоуровневую систему контроля, но во что это обойдется и как это повлияет на быстродействие - вопрос.
Технически, конечно, могут быть реализованы разные варианты, коих великое множество. Здесь, действительно, проблема в том, что всякое усиление безопасности ухудшает удобство пользователя. Неплохое средство – сложный пароль (да еще периодически сменяемый), передаваемый по шифрованному каналу. Но люди, как правило, не любят такие сложности и от этого становятся объектами успешных атак.
Возвращаясь к многофакторной (в нашем случае двухфакторной) аутентификации…
Все же я придерживаюсь мнения, что надо определить, что это такое, иначе мы обречены на разговор слепого с глухим.
Упрощенно считается, что введение пароля после имени пользователя, а затем еще одного пароля (кода) – это и есть двухфакторная аутентификация. Как частный случай при определенных условиях это подходит. Но, как говорится, есть нюансы.
Если такой механизм использовать на одном и том же устройстве (смартфон, планшет), то считать это двухфакторной аутентификацией можно только формально. Значит вопрос, что делает ее двухфакторной реально.
Сразу скажу, что я не специалист в разработке и технической реализации подобных мер, но из того, что пишут, можно сделать два наблюдения: фактором аутентификации может служить связь пользователь-аутентификационные_данные, каналы (механизмы) обработки аутентификационных данных должны быть надежно изолированы друг от друга.
Некоторые ростовщики дополнительно привязываются к идентификатору устройства.
Но это — та же фикция, с расширением базы не затрагивающим суть явления.
«Сложный пароль» — штука конечно хорошая.
Особенно если не лениться соблюдать регламент смены паролей…
Вот только в ситуации, когда их количество переваливает хотя бы на вторую дюжину… получается интересно.
Также как и с выделением отдельного устройства (цена артефакта плюс цена владения плюс традиционно игнорируемая специфика предметной области).
О том, что в предлагаемом идентификаторе (номер телефона) отсутствует избыточность (и как следствие — хотя бы потенциальная возможность контроля ошибок) скромно умолчим.
Как и про умышленное забвение технологического цикла привлекаемой предметной области (круговорот номерной ёмкости в сетях телефонной связи).
Пока просто отмечу эпизод в тему:
Или вот ещё прекрасное про одну промелькнувшую в ноосфере модную, но скоропостижно уничтоженну. соц.сеть:
задался целью найти идеальную или хотя бы просто теоретическую модель двухфакторной аутентификации ... ничего толкового не нашел
Наглядная иллюстрация сути современных интернетов: найти там можно только зная конкретику и достаточно большую часть правильного решения для верификации найденного.
Позвольте рекомендовать Вам творческую паузу с впаданием в детство ☺ В книгах Романа Душкина элементов решения достаточно много, и они собраны относительно компактно. В отличие от изуродованных коммереской пропагандой с подавлением обратной связи интернетов.
Можно (нужно) использовать эту литературу для совместного чтения с детьми.
Тема зарыта достаточно глубоко, можно и поделиться элементами правильного решения.
Ссылки на статьи с элементами — потом ☺
Описываю сообразно моему текущему пониманию решения.
Классический (и столь же классически неупоминаемый продаванами вредоносного ПО) пример ДА: публичный ключ.
Со столь же классической проблемой точки входа.
И фичей (стандарта де-факто формата openssh) в виде опционального единичного поля с информацией о пользователе.
Плюс проблемой (задачей) оперативной блокировки в случае компрометации закрытого ключа.
Развитие темы — стандарт X.509 (очень большой и жырный с сопутствующими следствиями в виде не просто отсутствия целостных реализаций, но хотя бы достаточно полной поверки модели практикой) плюс реализация библиотека SSL.
Но тут подкрадывается ещё формирующее воздействие требований массового распространения (помните эссэ о взаимоотношениях удобства с безопасностью?).
Откуда следуют вопросы как к полноте реализации необходимых функций, так и к их поддержке (совсем недавно зопилили поле для доменных имён серверов и всего несколько лет назад выпилили поддержку legacy-договорённости о заполнении).
Решением в первую очередь вышеотмеченной задачи является использование авторизации по сертификатам X.509.
Практически (в минимальной части) организуется некоторая дополнительная вспомогательная сущность типа «Удостоверяющий центр».
Которая издаёт себе специальный сертификат (который по уму не должен использоваться ни для чего, кроме заверения других сертификатов и возможность задания какового ограничения предусмотрена стандартом).
Сертификат УЦ играет роль публичного ключа на стороне сервера (и в данном приближении полноты реализации стандарта в настоящее время сущности УЦ и сервера, доступ к которому контролируется по ДА организационно совпадают, с некоторым *техническим* разделением).
Для получения доступа к сервису пользователь:
1. Формирует себе *приватный* ключ;
2. Формирует запрос на подпись сертификата;
3. Вручает сформированный *запрос* (ключ лежит на токене в сейфе) представителю УЦ (точка входа, как и в случае с базовым сценарием авторизации по публичному ключу является узким местом, в рамках модели красивое решение невозможно);
4. На основании запроса УЦ формирует сертификат *пользователя* (опять же: по уму пригодный только для использования для авторизации TLS клиента, как максимум — ещё и подписи электронной почты).
5. Пользователь из приватного ключа и сертификата собирает PKCS12. С которым уже умеет работать браузер.
Одним из наборов атрибутов сертификата (и СОСа) является срок действия.
В продолжение/завершение нити: в случае необходимости (организационные вопросы оставляю за кадром) сертификат (п.4) отзывается, то есть заносится в СОС (Список Отозванных Сертификатов), проверку которого можно, а в определённых случаях и нужно прописать серверу.
И в случае попытки обращения с отозванным сертификатом сервер их блокирует.
Из известного, данную схему авторизации использует webmoney.
Справедливое (и весьма крамольное) замечание камрада Конструктор игр:
И, как по заказу, наглядная иллюстрация проблемы.