Comments 33
Многофакторная авторизация решает проблему куда лучше, чем напрягать пользователя вводить какие-то отдельные буквы.
Система должна оставаться удобной. Аппаратные генераторы чисел, защита по IP-адресу, алгоритмическая зависимость действий от дня недели, числа месяца, самого месяца, см. habr.com/ru/company/itsoft/blog/581154
А пароли все копипастят из хранилок паролей. Пароль — это только один фактор. Нужны и другие.
О какой диссертации речь?
Статический пароль — это слабая защита. Нужен динамический — аппаратный генератор чисел, СМС и прочее. А описанный метод — можно расширить до таблицы кодов на бумажке или до книги какой-то: страница номер, строка номер, вторая буква третьего слова.
Актуальность этого вопроса состоит хотя бы в том, что такие пароли широко используются реальными компаниями. Ясно, что таким образом решается проблема кейлоггинга, но хотелось бы посмотреть, насколько же такой подход реально эффективен. Видимо, англичане находодят pps удобными в некотором смысле.
К сожалению, не все ресурсы предоставляют возможность использовать двухфакторную аутентификацию. Возможно, сам человек не хочет оставлять лишние личные данные, номер телефона на этом сайте. А использование pps не требует никакой допинформации, легко в реализации. Возможно, в простеньких системах оно может иметь какое-то весомое значение как отдельный тип защиты.
Кроме того, можно представить ситуацию (пусть маловероятную), когда злоумышленник получил доступ к почте и к телефону (уж очень он хотел взломать некоторого гражданина), тогда частичные пароли могут выступить последней преградой на его пути. Может быть, седьмой замочек и не откроется.
Ещё вот такой важный сценарий: помнится, одно время очень популярны были скиммеры для банкоматов. Ввёл пинкод, карту считали. А при снятии денег по какой-то причине не просят звонить куда-то или снимать биометрию (пока что). Так что частичные пароли также могут иметь место в системах, в безопасности которых человек неуверен.
Таким образом, есть проблема - есть некоторое решение, которое в определенных условиях и в определенном смысле эффективно, более того, уже реально используется.
Список литературы никогда не бывает лишним. Можно обратиться к первоисточникам и почитать поподробнее.
Само собой, это не диссертация) Популярное эссе на тему с схемами и мемами, с некоторой долей наукообразия. Вряд ли бы диссертационная комиссия оценила моё желание рассказать им про то, что такое вероятность или элементраная комбинаторика.
На мой взгляд, главная проблема, что информационные системы игнорируют это решение. Хотя его внедрять делать нечего.
Есть Яндекс, Гугл, майкрофосфт аутентификаторы.
Аунтификаторы может и есть, но аутентификация кривая. Я только начал это изучать
Дано: аппаратный ключ с поддержкой u2f, fido2 задача: попробуем аутентификацию без пароля.
(вариант с СМС не рассматриваю это костыли)
Яндекс: ставь наш аутентификатор, универсальные мы не поддерживаем. и только 2-х факторная.
Гугл: 2-х факторная аутентификация ок. Но в некоторых случаях я буду спрашивать только пароль(например при запросе установке приложения на телефон, когда запрос идёт с ПК) хотя казалось бы логичнее спрашивать 2-й фактор. Я даже поддерживаю безпарольную аутентификацию... но только если у вас есть 2 ключа. С одним никак. P.S. А ещё я похоже нашёл баг. Один и тот-же ключь нельзя дважды привязать к 2-х факторной аутентификации. Привязал, выключил 2-х факторную, второй раз уже не привязывается.
Майкрософт: поддерживаю даже безпарольную аутентификацию... но только через облако.
Steam: поддерживаю только собственное приложение. и только 2-х факторная.
Итого: беспарольная аутентификация 1/4(на самом деле меньше, т.к. сюда не вошли те, кто не поддерживает даже 2-х факторную аутентификацию) и то костылями.
2-х факторная... у всех с костылями.
эти велосипеды изобретены еще до появления всяких аутентификаторов. И почему вы боитесь засветить свой телефон? Да и при чем тут вообще телефон?
Многофакторная аутентикация (одним из вариантов которой, если подумать, является та же проверка IP-адреса) -- это всегда внесение в систему дополнительных внешних зависимостей. По определению, потому как она должна проходить по независимому каналу.
Но чем больше зависимостей, тем выше вероятность, что какие-то из них будут использованы во зло. Не взломаны "хакерами", а именно недобронамеренно использованы самими хозяевами. Зачастую во имя самых светлых идеалов. Закрыть телефонный номер, потому что с него был разослан "запрещённый контент". Заблокировать почтовый адрес, потому что странно себя повёл. Не выслать товар, потому что заказан с непривычного айпи. Ну и т.п. И вот суммарная надёжность (с точки зрения конечного потребителя) многофакторных схем начинает падать. И будет падать, пока не сравняется с "наихудшей альтернативой", не имеющей внешних зависимостей. То есть... паролями.
У паролей, конечно, есть слабости. Труднозапоминаемые пароли люди пишут в менеджеры, что сводит безопасность схемы на нет. Легкозапоминаемые легко подбираются. НО! Вот как раз таки схема "частичного пароля", применённая к легкозапоминаемым, но длинным фразам, в значительной степени эту трудность устраняет.
Поэтому мне лично данная статья кажется крайне важной, а направление -- весьма перспективным. Не побоюсь сказать даже, в мировом масштабе.
Ведь схема <имя, пароль> -- это последнее ещё существующее средство для пользователя заявить свою "идентичность", контролируемое самим пользователем, а не Кем-То Третьим. Цифровой мир, где не осталось этого средства, будет очень страшным, управляемым лишь немногими игроками, и унылым местом. Пароли не просто рано выкидывать на свалку, за их сохранение надо бороться.
Кстати, русские пароли в таком виде удобны и для применения в виде частичных, поскольку для русскоязычного удобно отсчитать нужные символы в уме, не записывая пароль на бумажке
Тоже когда-то пользовался этой методиков. До полного перехода на менеджер паролей. Но надо понимать, что при установлении (или при обоснованном предположении о вашем родном языке), такой подход увеличит сложность атаки по словарю всего в два раза.
Кстати, о менеджерах паролей. Я далеко не все из них смотрел, но широкой поддержки PPS я не видел. Это, как мне кажется, будет серьёзной проблемой для широкого внедрения частичных паролей. Да и реализовать автозаполнение в этом случае будет очень нетривиальной задачей.
Но надо понимать, что при установлении (или при обоснованном предположении о вашем родном языке), такой подход увеличит сложность атаки по словарю всего в два раза.
В сочетании с заменой букв на символы или цифры, а так же выбор редких слов нивелирует эти уязвимости. Как вам, например, "Ону4иношен#е"?
о менеджерах паролейKeePass2Android предлагает «быструю разблокировку» по трем последним символам пароля с одной попыткой ввода. При ошибке требует полный пароль. Я понимаю, что это несколько другое, но тем не менее.
Под Android использую приложение Keepass2Android, но, как правило, пользуюсь копи-пастом вместо интегрированных функций автозаполнения. Также много лет таскаю от смартфона к смарфону безопасную клавиатуру для паролей (вводишь на русском, пишет латиницей) без рекламы и вообще без выхода в Интернет. Она очень эргономичная. Этой клавиатуры давно нет в PlayMarket, к сожалению. Где-то на 4pda встречал её, но не вспомню.
Но надо понимать, что при установлении (или при обоснованном предположении о вашем родном языке), такой подход увеличит сложность атаки по словарю всего в два раза.Это, в основном, просто удобнее для запоминания
Hellenic bank пошёл ещё "мудрее". Они спрашивают (!) последние две цифры пин-кода карты. При логине на сайт. /facepalm x3.
Лучше бы otp сделали.
Странный какой-то анализ...
Но все же, запросы вида «Введите символы 1,1,3» или, тем более, «Ждем позиций 7,7,7» будут выглядеть несколько странно.
Это не просто странно, а фактически уменьшает длину запроса (потому что для атакующего эти два запроса - то же самое, что "1,3" и "7", соответственно), повышая вероятность успешного брутфорса выше. Например, при запросе "7,7,7" атакующему, вообще не знающему ничего об искомом пароле, надо просто угадать один символ из алфавита - что, очевидно, гораздо менее безопасно обычной схемы с несколькими запрашиваемыми символами.
Видим, что хотя на первых нескольких попытках вероятность ответа чуть ниже у сценария A (так как в запросе не может быть повторов), но для всех остальных значений сценарий B имеет значительно более высокую стойкость к взлому.
Но ведь формулы, приведённые в статье перед этой фразой, говорят не о стойкости к взлому, а о - цитата - "вероятность того, что в очередном запросе будут позиции символов, которые ему уже известны". Что, как бы, и так понятно из неформальных рассуждений: если схема такова, как "B", что она иногда спрашивает у пользователя меньше символов, то и кейлоггер будет в среднем накапливать меньше данных, да и более короткий запрос имеет меньшие шансы пересечься с уже накопленным. Только вот как это коррелирует с общей безопасностью схемы? Мы же ухудшаем устойчивость одного запроса к взлому: во-первых, атакующему проще угадать ответ на один запрос из-за его возможно меньшей длины (см. начало комментария), а, во-вторых, ценность каждого утекшего символа растёт (пользуясь вашими примерами - для ответа на запрос "7,7,7" атакующему достаточно знать один-единственный утекший символ №7).
Само собой, выпадение 777 - это просто угадывание одного символа на позиции 7. Это не вполне хорошо, в некоторых смыслах, стоит как-то подправить эту схему.
Стойкость схемы с повторениями оказалась эффективнее в контексте восстановления пароля полностью. Вариант с дополнительным угадыванием, к сожалению, в случае дополнительного угадывания не рассматривался .Впрочем, нет особой проблемы сделать это, может быть, на досуге стоит посмотреть. Или кто-то из читателей может этим заняться, если будет интересно.
Результат наверное, естественный (но если задуматься, то не такой уж и тривиальный), ведь просто ниже вероятность выпадения всего набора букв (возможно, придётся долго ждать последних недостающих символов из-за некоторых повторений в запросе). Само собой, с учётом угадывания, результат может измениться, оптимизация параметров должна быть более тонкой. Кроме того, уж очень слабые комбинации можно просто блокировать и не запрашивать или ограничивать минимальное число уникальных символов в запросе. Так что открывается большой простор для оптимизаций параметров, но анализ при этом кардинально не усложняется. Ещё, эта проблема может дополнительно купироваться на коленке увеличением словаря (но не им единым).
Теперь стоит сказать, для чего нужно отдельное рассмотрение такой атаки: атаки с полным восстановлением пароля или атаки с уверенным ответом на следующий запрос (гиперболизированный пример). Злоумышленник поставил перед собой цель во что бы то ни стало взломать аккаунт некоего гражданина. Допустим, он получил доступ к основному паролю своей горе-жертвы (подсмотрел из-за спины или просто скопировал из какого-нибудь блокнотика на компьютере), доступ к телефону/почте (почему бы и нет) и узнал девичью фамилию троюродной бабушки по отцовской линии. Ему для беспрепятственного доступа к аккаунту не хватает лишь ответа на частичный пароль, который ему не удалось пока узнать. Поэтому он установил на компьютер жертвы кейлоггер или физически поставил на его клавиатуру свою реплику-шпион (или не на компьютер, а на его любимый терминал в ТЦ). Теперь злоумышленник затаился и ждёт, пока он не накопит информацию о частичном пароле, при каждом входе жертвы он получает новую информацию (а пароль этот будет достаточно длинным, с оптимальными параметрами).
Patience... Don't do anything stupid.
Он не хочет рисковать: если попытаться войти в аккаунт и провалиться, то жертва сорвётся и поменяет пароль или заблокирует свой счёт или свою страничку... Дожидается и получает прямой доступ в аккаунт своей жертвы.
Менее вероятно, что злоумышленник сможет получить полный набор данных о большом числе людей, чтобы иметь возможность поиграть в статистику.
В таком контексте были проведены рассуждения в матмодели, вплоть до раздела "Атака кейлоггинг + bruteforce"
Возможно, сценарий и искусственный, но, всё же, такое решение действительно создает некоторые дополнительные преграды, против которых некоторые другие способы защиты бессильны (например, при ограниченном бюджете и возможностях).
Предложенная attack surface не очень понятная. Если мы рассматриваем только этот вид атак, то самой выгодной станет схема "спрашивать по одному символу пароля". В вашей модели attack surface (с затаившимся взломщиком) это даст самое медленное раскрытие информации, хотя в реальности, разумеется, это абсолютно небезопасная схема, потому что любому "не таящемуся" атакующему достаточно будет угадать один символ для успешного взлома. Ваша схема "B" - это просто один шаг в направлении этой схемы, но уже этот шаг понижает общую устойчивость к взлому.
Я, в большей части, вижу (точнее, недавно увидел) pps как дополнительную меру защиты аккаунта. Собственно, она в существующих решениях так и используется. Да, возможно, в гиперболе выше самым лучшим решением будет посимвольный запрос и действительно так и стоит бороться с настойчивыми и находчивыми взломщиками. Но интуиция может легко обмануть, на мой взгляд, запрос по одному символу будет менее безопасным даже в таком контексте. Это можно проверить (я пока не проверял, могу ошибаться).
В реальности используются другие параметры, характерные числа и были рассмотрены выше (которые, к сожалению, имеют сомнительную стойкость во многих смыслах). Задача проста, но, на удивление, очень мало людей ей уделяют внимание, непропорционально тем надеждам, которые на pps возложены (создавая при этом некоторый дискомфорт пользователю). Было бы неплохо плотнее взяться за эту тему.
Мотивация к рассмотрению B в том, что это элементарная модификация A, к которой легко перейти почти задаром и которая легко интерпретируется.
На русском языке я не нашел ни одного шага, лежащего на расстоянии вытянутой руки. Так что можно делать шаги дальше. Тем более, что модель совсем несложная.
Неужели вы не видите противоречия между тем, что, как вы согласились, предложенный сценарий "B" приближает нас к варианту с односимвольным челленджем, и очевидной небезопасностью односимвольного челленджа? Что условную устойчивость к кейлоггингу мы покупаем ценой компроментации всей схемы, фактически укорачивая запрашиваемые пароли?
Я много раз писал о том, что нет смысла использовать эти пароли в отрыве от других средств защиты, хотя бы с обычным паролем. Тогда условная устойчивость pps к кейлоггингу с безусловной уязвимостью к угадыванию дополняется безусловной устойчивостью пароля к подбору, однако имеющего абсолютную уязвимость к кейлоггингу. В этом случае даже односимвольный челлендж будет лучше, чем ничего
Это забавно, что вы упомянули про "ничего", потому что в вашей модели атак, как раз-таки, "ничего" будет идеальной системой защиты! Потому что если сервер не спрашивает ни одного символа пароля, то и кейлоггер не запишет ни одного символа - вот и идеальный результат в предложенной вами attack surface. По меньшей мере тут уже можно понять, насколько абсурден анализ, проводимый из таких предпосылок...
Прошу прощения, но я считаю, что Вы уже передёргиваете. Если будет "ничего", то пользователь вводит свой пароль и в тот же момент его теряет. Если есть частичный пароль, то этого не произойдёт с вероятностью, отличной от 1.
Я Вам скажу, что подобный абсурдный анализ, ещё и с некоторыми помарками, был опубликован в рецензируемых журналах (теперь уж пришлось апеллировать к авторитетам). Во многом на них и основано эссе. Но я лично не позиционирую этот текст как исчерпывающее руководство к действию, а как повод узнать или задуматься про такой тип паролей, так как не получится найти источников на русском языке по этой теме.
Скажем так, среди прочего, предпосылка - это то, что такие пароли активно используются уже давно и используются по сей день. Проблема в том, что нужно проводить подбор параметров более тщательно, чем это делают в настоящий момент, потому что даже против простых типов атак, связанных с кейлоггингом они неэффективны, не выполняют своей роли. Хотелось тут донести, что стоит подправить параметры, чтобы вообще вся эта затея имела смысл. А то выходит, что пользователи финсектора страдают ни за что.
Я остановился на анализе такого типа. Исчерпывающий анализ заслуживает какой-нибудь небольшой монографушки. Я и не претендовал на всеобъемлющее исследование, на последние истины. Но в рассмотренных постановках, где производилось сравнение двух методов, были сделаны некоторые выводы и было упомянуто, в каких предпосылках. Можно спорить о них, но замах был ровно на то, о чём и было написано. Предоставлен некоторый простой и занимательный метод, как можно посчитать некоторую несложную комбинаторику. Быть может, кто-то захочет покопаться в этом вопросе самостоятельно.
Спасибо за Ваши комментарии, я думаю, что теперь желающие использовать pps люди ещё раз взвесят все за и против перед тем, как выкатывать что-то в продакшен. Возможно, кто-то захотел бы использовать текст как кулинарную книгу, чего бы делать не стоило.
"Вариант с дополнительным угадыванием, к сожалению, в случае дополнительного угадывания не рассматривался" - опечатка, должно было быть "Вариант с дополнительным угадыванием, к сожалению, в случае запросов с повторениями не рассматривался"
Так ведь без этого какие выводы можно делать о реальной устойчивости схемы? Упражнения на комбинаторику в статье проделаны хорошие, только вот к выводу "сценарий B имеет значительно более высокую стойкость к взлому" они никак не приводят. В лучшем случае это введение читателей в заблуждение, в худшем - кто-то пойдёт на поводу у статьи и эту, простите, ерунду в реальный продакшен выкатит...
В выводе я отдельно отметил, в каком сценарии это действительно так. Цитата "сценарий B имеет значительно более высокую стойкость к взлому" взята из раздела, где недвусмысленно и не один раз описано, в каком случае и при каких предположениях одна схема лучше другой. В выводе, опять же, сделана ремарка о том, в каком смысле и что лучше. Возможно, что при беглом чтении может возникнуть желание сделать обобщение или вообще принять, что частичные пароли - это панацея. Но это не так. Я старался не быть категоричным и уж точно не рекламировал pps, никакого интереса в этом не имею.
На всякий случай ещё раз дополню общий вывод, чтобы уж наверняка не ввести читателей в заблуждение.
Можно еще добавить призыв к дальнейшему изучению, в качестве упражнения и досуга.
К сожалению, достаточно много людей уже выпустили в продакшен эту ерунду, многие этой ерундой пользуются, в выборе параметров не руководствуясь никакими расчётами и выкладками. Кто-то из пользователей и не задумывался, зачем такую изощрённую пытку вообще придумали. Возможно, кого-то и остановят полученные результаты от использования в продакшене
И да, я люблю упражнения на комбинаторику. Может быть, кому-нибудь эта страничка будет интересна в контексте занимательных формул и фактов.
Речь не про частичные пароли, а про ваш вывод, что сценарий B более защищён, чем другой. Повторюсь, этот вывод является манипуляцией: на основе одной формулы, которая оценивает только один из аспектов безопасности, делается вывод об общем превосходстве этой схемы над другой. Однако это вывод так же неверен, как, например, говорить "давайте предположим, что атакующий не будет использовать атаки по словарю" и на основе этой предпосылки делать рекомендации о применении схем безопасности.
Я внёс некоторые дополнительные изменения в текст, чтобы уж точно исключить возможное неправильное толкование.
Общего превосходства не доказано, как и не показано, почему вообще рассмотрено только две схемы (одна - используется в реальности, другая - её простая модификация). И почему вообще именно частичные пароли нужны именно в таком виде (возможно, кто-то придумает альтернативу).
Да, предпосылка такая. Но в тех сравнениях и не шла речь про атаки с подбором. Там давались либо точные ответы на новый запрос, либо полное восстановление пароля. А актуальность и распространенность такого сценария очевидна и показана на примерах, особенно в случае роли pps в качестве дополнительного средства защиты (а другое и не имеет особого смысла). Так что решалась поставленная задача, которая имеет как практический, так и некоторый теоретический интерес (занимательные формулы на поупражняться, добрая затея), в указанных предпосылках система описывается некоторой моделью, которая исчерпывающе закрывает вопрос с этим сценарием (напомню, он даже изолированно имеет большое значение). Так что манипуляций нет и речи о них быть не может. Все модели неверны, но некоторые из них полезны. Полезность этой - мною уже много раз описана и в тексте, и в комментариях. Другая польза в том, что можно будет продолжить анализ и покопаться в подробностях не в одиночку, а той части коммьюнити, которой показалась занятной модель и результаты или тем, кто заинтересовался практической стороной дела. Кроме того, показана очевидная уязвимость текущих частичных паролей, нет никакого смысла делать запросы и целый пароль в pps такими маленькими.
Пожалуй, мне больше нечего сказать.
Однако есть и очевидные минусы pps: не каждый человек захочет запоминать пароль так, чтобы у него от зубов отскакивали все символы в каждой позиции.
На мой взгляд, с этого можно было бы начать и отбросить все остальные выкладки. При наличии выбора, я бы избегал пользоваться сайтами с такой аутентикацией
Parole*, paro*es, *aroles…