Разбирая… буфер нашёл указание на событие, представляющее определённый интерес. В качестве присказки отмечу, что сначала расплодившиеся буквально на каждом углу терминалы платёжных систем завлекали потенциальных пользователей нулевой комиссией наиболее распространённого платежа (пополнение счёта мобильного телефона). Потом, то ли оценив степень привыкания целевой аудитории как достаточную, то ли исходя из некоторых не получивших широкой огласки причин ввели комиссию. Из массовых сетей, практикующих приём платежей без комиссии осталась только «Евросеть».
И собственно сообщение: На вторую половину лета (июль-август) 2015 года отмечено, что терминалы «Связного» (по крайней мере в населённому пункте уровня районного центра центрального региона) прекратили приём платежей МТС.
Комментарии
Забудьте вы про терминалы, давно уже есть сбер онлайн
Когда сможете забить в извилины разработчиков Сокровенное Знание о существовании механизмов авторизации, отличных от парольного и предъявите факт внедрения *адекватной* системы доступа к сетевому интерфейса, всемерно впариваемому далеко не только сбербанком, возвращайтесь.
В сбере не только парольная авторизация, пробовали сами?
Вы никак хотите сагитировать мена за инновационную технологию делегирования ответственности налево (с вводом волшебных кодов подтверждения из SMS-сообщений)?
Эээ, а чем плохи подтверждения из SMS-сообщений?
Вы когда в последний раз видели худо-бедно вменяемую блокировку оконечного устройства?
Смартфоны исключаем из-за особенностей плаптформы, позволяющей втыкать дополнительное ПО, умеющее скрывать ненужные SMS (задача трансляции кода из извещения едва ли качественно сложнее).
А если СМС приходят на физически другое устройство? Т.е. банк не на смарте, а в ноуте.
Т.е. Вы хотите сказать, что на ноуте выполняется главное правило (что эффективно-бизнесмены освоили не только написание ПО приемлемого качества, но и *правильную* компоновку с распространением пакетов)?
По моему опыту (если интересно, могу раскопать тему с наглядной иллюстрацией) — фантастика. Ненаучная.
Эээ, откровенно говоря, ничего не понял в Вашем ответе.
В т.ч. что такое "главное правило"?
Главное правило: ни в коем случае, никогда ничего не устанавливать минуя пакетную систему дистрибутива.
Особенно с учётом достижений корпораций в использовании big data для идентификации пользователей попытка разнесения в пространстве скорее доставит проблем (ну примерно как требования профессионалов по регулярной смене паролей) , чем способствует улучшению защиты.
Все инновации сбера имеют одну цель, снижение собственных рисков путем перекладывания их на плечи их уважаемых Клиентов)))
Девиз "С нами выгодно!" видимо из природной скромности специально пишут с двумя ошибками: Вы пишется раздельно и желательно с большой буквы в знак уважения, ну и далее по тексту В меняют на Д)))
А какие механизмы вы бы предложили Сберу вместо обычной авторизации через пароль?
Имхо мне известны ТРИ принципа аутентификации:
1. мы знаем что-то, чего не знают другие (логин-парол).
2. мы имеем то, что не имеет больше никто (смарткарты и прочее).
3. за нас поручается третья сторона, с абсолютной надёжностью (сертификаты от надёжного Центра).
Если кто-то знает иные принципы и способы -- было бы тоже интересно их узнать..
Собственно в 3 способе, на самом деле мы перекладываем задачу аутентификации на этот надёжный Центр(так что скорее пример - OpenID, а наличие сертификата - это 1 или 2), так что в принципе в самом конце от пользователя ожидается 1, или 2, или какая-то их комбинация.
«Наличие сертификата» — парол???
Имхо, комрады от вас ожидают не прений-дискуссий, а пояснения вашей позиции. В виде белее-менее развёрнутого объяснения..
Тема достаточно сложна и масштабна, чтобы хвастаться возможностью *изложения*, но попробовать можно.
Предметная область накладывает определённые ограничения на представление используемых знаков.
А в общем случае задача не ограничивается аутентификацией.
Внешний сервис (OpenID сотоварищи), решает проблему множественности баз пользователей. Но не гарантирует использования более (и вообще сколько-нибудь) продвинутого механизма аутентификации.
Потому эту нить не рассматриваю.
Седую древность (rlogin/rsh/и т.д.) тоже пропускаю.
Так вот, простейшим, исторически первым первым механизмом, является логин/пароль.
Особенносью данной технологии является простота и удобство для атакующего: достаточно перехватить данные сессии (в случае использования шифрования канала их ещё надо прочитать).
Повысить защищённость можно ограничивая возможность подключения конкретным IP-адресом или подсетью, что регулярно делается не смотря на ошибки типа false positives. Древние и казалось бы окончательно устаревшие технологии всё ещё живут.
Следующим этапом эволюции является технология авторизации по публичному ключу (надеюсь, термин не требует отдельного пояснения). Эволюцию алгоритмов и протоколов опускаю.
Имя пользователя как исторический и привычный идентификатор пользователя остаётся. Но практически идентификация обращения осуществляется по публичному ключу. То есть перехвата сессионных данных недостаточно. Для успешной авторизации необходим соответствующий публичному ключу приватный ключ. Который в изначальном и простейшем случае может лежать в файле, либо на специальном устройстве (токен).
Всё замечательно работает.
Но, увы, вероятность компрометации приватного ключа не равна нулю (особенно в случае использования клиентом самой распространённой ОС, тамошние клиенты, по моим наблюдениям, не производят даже банальной проверки прав на файл, что достаточным образом характеризует заявления о реализации многопользовательского режима).
При количестве «серверов», на которых авторизуется пользователь, больше 3-4 оперативная зачистка скомпрометированного ключа превращается в достаточно дорогую задачу.
Следующим шагом является переход от одноуровневой точка-точка к иерархической структуре: удостоверяющий центр (с тоже ненулевой вероятностью компрометации приватного ключа, смотрите историю распространения вирусов для самой распространённой ОС), издающий (в простейшем случае, иерархию не рассматриваю) «сертификат» (в ощем случае «ключ», или «приватный ключ» и «сертификат» или «публичный ключ») для идентификации сервера и клиента (в простейшем вырожденном случае, который можно наблюдать например на АШ сертификат клиента отсутствует, а сертификат сервера играет роль как собственно сертификата сервера, так и сертификата клиента).
В этом случае при компрометации приватного ключа клиента достаточно направить в УЦ запрос на компрометацию, и после обновления всеми корреспондентами списка отозванных сертификатов взаимодействие с клиентом, идентифицирующим себя отозванным сертификатом становится невозможным.
Для ssh поддержка фичи существует ЕМНИП всё ещё в виде отдельного патча.
В общем - согласен. Пара замечаний:
Во-первых, "достаточно перехватить данные сессии" - строго говоря, неверно. Мало того, что https используется повсеместно, и их действительно надо еще прочитать, так и вполне можно использовать пароль клиента для шифрования внутри соединения.
Да и если перехватить сессию(не скомпрометировав пароль), у клиента остаётся возможность сменить его.
Во-вторых, проблема в случае компрометации приватного ключа клиента - как получить новый ключ. Как правило, для смены пароля просят либо ввести старый, либо отсылают ссылку для регенерации на закрепленный e-mail адрес, при этом для мыла большинство пользователей всё же используют иной пароль. А с сертификатом?
Ну и в третьих - теоретически-то понятно, будущее за параноиками. Но тут мы как-бы обсуждаем не параноика, а "обычного пользователя", которому нужно войти в (Сбер)банк. Соответственно, от схемы аутентификации требуется не только надёжность, но и простота.
Изначально вы поставили под сомнение способы аутентификации Сбера (и не только его). Но предложенные вами способы радикально ничего не вносят и рисков не уменьшают, но при этом несут в себе техническое усложнение..
В случае с интернет-банкингом, задача аутентификации -- убедиться, что на том конце связи сидит именно тот человек, который соответствует предоставленному им идентификатору. И многофакторная аутентификация тут призвана увеличить надёжность и размазать ответственность.
До тотальной телефонизации, и-банки выдавали электронные ключи (как вы и говорите, которые использовались одновременно с логином-паролём), на дискете или, позже, на флешке. Но эти ключи точно так же можно было украсть, как и телефон сейчас. Так что надёжность тут тоже не идеальная. А против терморектального криптоанализатора вообще защититься проблематично! Что события на Уркаине в 14 году это подтвердили, когда победившие "революционеры"-правосеки (легализованная гопота) массово потрошили банковские счета обывателей..
Так что данная проблема -- не такая уж и простая как кажется на первый взгляд. И на второй тоже..
Если крепко-крепко зажмуриться и подобно менеджерам сбербанка сделать вид, что между «ключом» на дискетке и им же на токене нет *никакой* разницы, то действительно «предложенные вами способы радикально ничего не вносят и рисков не уменьшают, но при этом несут в себе техническое усложнение».
И главной целью внедрения многофакторной аутентификации, которая привносит не меньше геммороя, является именно что «размазать ответственность».
Если рассуждать не эмоционально, а технически -- то велика ли разница в плане возможности кражи носителей с ключами: дискеты, флэшки, токена? Сильно велика ли между ними разница, в плане возможности их использования БЕЗ владельца? Какие преимущества есть у одних носителей, каковых нет у других?
Если рассуждать не эмоционально, а технически -- то многофакторная аутенитификация имеет позитивные для банка последствия не только в "размазывании ответственности", но и некоторого существенного повышения надёжности аутентификации. Или вы не согласны?
Если прежде чем вешать на аргументы оппонента ярлычок «эмоциональности» поинтересоваться свойствами артефактов, то можно было бы и обойтись без риторических вопросов.
Если рассуждать *технически*, то многофакторная аутентификация действительно крайне удобна и для банка, и для бизнеса.
Помните заявление сбербанка… практически в пользу ренты для паразитов?
И давно ли вы встречали адекватный *телефон* (не смартфон, см. замечание выше) с блокировкой терминала?
Я не имею желания развешивать ярлыки. Но ваше выражение "Если крепко-крепко зажмуриться и подобно менеджерам сбербанка сделать вид" мне видится более эмоциональным нежели технически содержательным. Обидеть не хотел и не хочу..
Я бы всё-таки предпочёл не акцентировать внимание на удобности для банка. А на альтернативных решениях. Приемлимых так же и с точки зрения социальной инженерии.
Я лично вот не вижу, как из существующих методов собрать способ, радикально надёжнее существующих.. Может вы видите?
Телефонов таких давно не встречал..
К сожалению у меня кратно избыточный личный опыт попыток применения пропаганды *технических* преимуществ конкретных решений в ситуациях, которые можно решить только организационными мерами.
Вообще, корень проблемы в том, что подобно карикатуре на коммерческую медицину («давайте лечить за деньги… здоровых людей») банки претендуют на тот же сугубо ограниченный ресурс («дать денег в долг… тем, у кого они и так есть»).
На следующем уровне обобщения проблема сводится к использованию «роста» в качестве критерия прогресса.
ЗЫ: Ну вот. Смартфон — в лучшем случае просто источник абонплаты разработчикам вирусов (если не налетите на воплощение пророчества тов. RMS), телефон — скорее отмазка для банка.
А специализированное устройство типа «токен» хорошо тем, что после задаваемого пользователем количества попыток ввода пинкода его можно только отформатировать.
Мне интересно обсуждать только проблемы и их возможные решения. Этика в данном случае мне не интересна..
ЗЫ: можно ведь и несколько раз ошибочно введённый логин-пароль заблокировать. Чем это в результате отличается от форматирования токена? И потом, кто мешает украсть токен, а ПИН перехватить?
Вот что на Вике пишут:
Уязвимости
Простейшая уязвимость с любым токеном — это его потеря или кража. Вероятность случая компрометации может быть уменьшена с помощью личной безопасности, например: замки, электронная привязь, сигнализация. Украденные токены — бесполезны для вора, если использована технология двухфакторной аутентификации. Как правило для проверки подлинности требуется вводить персональный идентификационный номер (PIN) вместе с информацией на токене.
Любая система, которая позволяет пользователям аутентифицироваться через ненадежную сеть (например, Интернет) является уязвимой к атаке «человек посередине». MITM-атака (англ. Man in the middle) — термин в криптографии, обозначающий ситуацию, когда криптоаналитик (атакующий) способен читать и видоизменять по своей воле сообщения, которыми обмениваются корреспонденты, причём ни один из последних не может догадаться о его присутствии в канале. Метод компрометации канала связи, при котором взломщик, подключившись к каналу между контрагентами, осуществляет активное вмешательство в протокол передачи, удаляя, искажая информацию или навязывая ложную.
Так что -- и с токенами "не всё так однозначно"..
То есть даже очевидные зависимости, типа организационных или ресурсных ограничений, Вы уже не рассматриваете?
Как Вы представляете себе процесс перехвата пина токена? Что для этого *необходимо* сделать?
ЗЫ: Когда-то давно, по наивности я пытался использовать вики в качестве источника *технической* информации.
Но абсолютный арбитр Истины быстро вынес эту дурь.
Кстати, действительно: выдавать каждому клиенту по токену и учить с ним обращаться - как-то более дорогая и сложная операция, чем рассылать смс-ки. Очевидное ограничение.
Обыкновенное делегирование накладных расходов.
Помните эпизод, когда сбербанк под предлогом невыплаты дани разработчикам вредоносного ПО отказался компенсировать ущерб от мошенничества?
Как раз в модели с двухфакторной авторизацией…
Ну почему, давайте посмотрим какие могут возникнуть ограничения и побочные эффекты, если банк всем клиентам раздаст токены, от мала до велика. И попытается их обучить..
Так вроде уязвимости я из Вики процитировал выше. Но вы видимо с ними категорически и обоснованно не согласны..?
ЗЫ: Я Вики
пидо..не использую сразу же как истину в последней инстанции, а для начала -- в качестве источника оценочной информации. А потом видно будет..Приведённая цитата показывает мастерство авторов в натягивании востребованного доказательства на типовой комплекс опыта.
Но, увы, категорически не выдерживает встречи с практикой.
В частности, демонстрирует лишь успешную реализацию нежелания авторов обременять себя понимание различий между *публичным* и *приватным* ключами.
Наглядную иллюстрацию можно наблюдать в статье. Для полноты картины вики-эксперту недостанет лишь возмущённого заказчика с терморектальным криптоанализатором.
ЗЫ: Практика показывает, что ошибки начальной фазы исправляются сложнее и дороже всего. Поэтому источники, решающие посторонние задачи и придавленные бременем популярности не стоят затрачиваемого времени.
Вы исходите из стереотипа защищённости приватного ключа, что взломать шифрование чрезвычайно сложно. А что будет, когда приватный ключ украдут?
Я исхожу из того *факта*, что промышление приватного ключа — это отдельная задача с совсем другой ресурсоёмкостью и вероятностью успеха.
Отдельно интересует перспектива скрадывания приватного ключа с специализированного устройства типа «токен».
И речь идёт не о «чрезвычайной сложности», а о цене решения в заданных условиях.
ЗЫ: И для полноты картины не забывайте описывать устойчивость оконечного метода популярной альтернативы.
Что мешает подтянуть приватный ключ вместе с носителем, не важно каким?
ЗЫ: Я ни в коей мере не имею желания идеализировать применяемые сейчас решения. Мне интересно понять перспективы реализации заявленных вами "беспарольных методов аутентификации" в имеющихся рамках. А так же цена вопроса и риски -- то есть вообще, стоит ли игра свечь?
Вообще меня всегда умиляли подборки, авторы которых решали задачу натягивания востребованного результата на очевидно несовпадающий физический смысл.
Как, например, увлекательнейший процесс подсчёта язвимостей:
Виндавсы разбили по версиям, линуксы свалили в кучу.
Существование как давно во все дыры форсимых технологий типа SELinux, так и банального факта конфигурируемости ядра, крепко зажмурив глаза, проигнорировали.
Свалили в одну кучу дыры реально существующие и эксплуатируемые с потенциальными уязвимостями, выявленными в ПО с открытыми исходниками.
И — о Чудо.
Востребованный результат налицо.
Ну например - если у нас обычный токен вида "нажми на кнопку и получи пин-код", то с mitm простая схема атаки: перехватываем отправку первого ключа, ждём, пока пользователь нажмёт на кнопку и получит второй ключ, после чего - отдаём серверу первый ключ.
После того, как пользователь завершил работу - у нас есть рабочий пин-код, входим и делаем "грязное дело".
Кстати, с смс - подтверждением эта атака не сработает, т.к. сервер знает последний выданный пин-код, и использовать предыдущий - не получится.
Вы много обвиняете.. А хотелось бы конкретики.
Конкретика сводится к тому, что *приватный* ключ на то и приватный, что никуда не передаётся, а используется *локально*.
А кто мешает его украсть? И использовать локально, но уже в другом месте?
Тот факт, что для этого необходимо:
1. Снечала идентифицировать рабочую станцию, оператором которой используется целевой ключ;
2. Промыслить с неё файл ключа.
При использовании специализированных устройств (откуда ключ, по крайней мере в нормальном случае не извлекается, гаджет обеспечивает интерфейс для выполнения с ключом некоторого набора стандартных операций и всё) задача переводится в необходимость:
1. Добыть устройство-носитель;
2. Успешно пройти квест «угадай PIN-код».
2. чем угадывание ПИН-кода отличается от угадывания пароля?
Те же яйца, вид сбоку?
При использовани парольного механизма используемые политики задаются на стороне сервера.
Зачастую с «информированием» пользователя на уровне типового договора оферты (видели статью?).
Причём вектор мотивации администратора сервера (в обсуждаемом примере — банка) содержит такие архи-востребованные конкретным пользователем составляющие, как, например, стремление сэкономить на сопровождении.
При использовании токена пользователь задаёт (ну или может задать) политику самостоятельно, прислушиваясь исключительно к голосу своей лучшей подруги по имени Паранойя.
Вот скажите честно: Вы *часто* встречали практику полной блокировки учётной записи после [например] трёх ошибок ввода пароля?
Сервисы делаются дла того, чтобы ими пользовались. Потолок целевой аудитории давно пройден. Отпугивать требованиями соблюдения правил информационной безопасности потенциальных пользователей (или злоумышленников)?
Среди задыхающихся при виде призрака Крызиса банкстеров готовых подписаться на это деяние героев не много.
ЗЫ: И не стоит исключать из рассмотрения *необходимые* предпосылки игры в «угадай PIN-код токена».
Подруга Паранойя есть не только лишь у всех. Гораздо у более всех -- есть дядюшка Слабоумие. И при таких раскладах отдавать настройки политики в руки пользователя -- это заранее спровоцировать косяки и убытки. И логично будет, что издержки при таком подходе будут перекладываться на юзера: сам просохатил -- сам и виноват.
В банковских продуктах (коих я пользовал не так уж много) -- ни разу, что вызывает недоумение..
ЗЫ: так и терморектальный криптоанализ тоже не стоит исключать из рассмотрения..
ЗЗЫ: Я так и не увидел, что может существовать РЕАЛЬНАЯ альтернатива аутентификации в и-нет-банковском деле, свободная от недостатков существующих методов, не являющаяся теми же яйцами вид сбоку, и не требующая особой продвинутости пользователя..
Издержки и так перекладываются.
Эпизод, с отказом Сбербанка компенсировать действия мошенников, под предлогом невыплаты даны разработчикам вредоносного ПО, я упоминал.
С учётом закономерной необходимости включения в базу пользователей (необходимое условие существования капитализма) тех, кому впариваемое ненужно, реверансы в сторону простоты — очевидная необходимость.
Снимите последнее требование доступности тем, кому оно ненужно и кто не собирается утруждать себя ни мыслительной деятельностью, ни тем более освоением недостающих навыков.
От равнения на отстающего страдают все.
Я, может быть, чего-то не понимаю, но как использование токена даёт возможность влиять на политики безопасности на стороне сервера?
Согласен, "сервисы делаются, чтобы ими пользовались". Только вот вероятность какого события больше? "Пользователь 3 раза неверно ввёл пароль" или "у пользователя увели пароль"? "Пользователь потерял токен" или "у пользователя токен украли"? Проблема в том, что массовое решение по безопасности должно защищать пользователя в том числе от самого себя. Ну и до кучи быть удобным.
Не только удобным, но и (интуитивно) понятным, и однозначным. Как сейчас говорят -- юзабельным. И не требовать при эксплуатации помощи бригады санитаров, состоящей из докторов наук..
То что хорошо работает в защищённом офисе -- ещё не факт, что будет работать в обычном миру..
Направление, в котором ведёт «интуитивно-понятность» для тех, кому предмет малоинтересен, но кому при этом жизненно-необходимо впарить… услугу или гаджет лучше рассматривать на более конкретных примерах.
Могу пересказать замечательную историю о [попытке] приобретения экспонометра. ☺
Да-да, я понял что сейчас всё очень плохо.. Но мы обсуждаем вопрос -- а можно ли в данных условиях сделать что-то существенно лучшее чем есть, но НЕ требующее массового высшего технического образования у клиентов или наличия под рукой санитарной бригады из докторов наук?
То что вы рассказываете -- это всё "за всё хорошее против всего плохого". Меня лично это не пугает, ибо имею высшее техническое. Но на сколько это все реалистично в плане массовости, если основная масса народу даже матан-капчу ниасилит? Что будут делать с токенами, ПИНами и политиками вчерашняя школота, офисные ТПшки, и недалёкие домохозяйки которых ни кто не трахает?
Не, на стороне сервера, а системы в целом.
Посредством выноса *некоторых* политик на сторону клиента.
И не забывайте различать удобство для профильного пользователя (которому инструмент *реально* нужен) от удобства для произвольного потенциального клиента (задача смещается в сторону *удобно* впарить).
Ну и «защита пользователя от самого себя» обычно находится в прямом противоречии с защищённостью системы. Приходится выбирать. Причём массовость диктует вполне конкретный выбор.
Обычная задачка: требуется с карты пополнить телефон, или оплатить коммуналку, или что-то еще. Профильный клиент - тот самый массовый пользователь, которому не хочется подниматься с дивана и идти к банкоматы. Задача - сделать этому пользователю безопасный и удобный вход в интернет-банк. Предложения?
И да, ношение связки токенов для кучи сервисов, как по-моему, удобством не является для абсолютного большинства людей.
Скорее смарт-карта, вариант 2 - у вас сертификат есть, а у злоумышленника - нет.
Страницы