2011: Двухфакторная аутентификация слишком сложна, считают администраторы
60% из ста опрошенных компанией GrIDsure руководителей информационных служб обеспокоены чрезмерной сложностью методов двухфакторной аутентификации пользователей, а более половины из них считают, что реализация ее обойдется слишком дорого (данные 2011 года). При этом каждый пятый скептически оценивает шансы двухфакторной аутентификации решить проблемы традиционной аутентификации по одному паролю. Тем не менее, 36% опрошенных считают многоуровневую аутентификацию важнейшим факторов обеспечения безопасности доступа. 32% ставят на первое место обучение сотрудников, и только 7% высказываются за полное отключение удаленного доступа.
Аутентификации по паролю уже недостаточно для защиты ценных данных, заключают в GrIDsure. Однако решающим фактором оказывается стоимость системы. Большинство из имеющихся на рынке решений слишком сложны и дороги в реализации и поддержке. Любая система, требующая наличия аппаратного ключа или отправки паролей на мобильный телефон, лишь делает процесс аутентификации более громоздким.
Лишь 34% опрошенных уверены, что сотрудники в состоянии сделать все необходимое для защиты компании от компьютерных угроз.
Расположение веб-сервера IIS и рабочих серверов 1С на разных машинах
В некоторых случаях, несмотря на корректно указанного пользователя операционной системы в пользователе информационной базы, при попытке входа в опубликованную базу через браузер аутентификация операционной системы не проходит. Такая ситуация может возникать, если веб-сервер IIS и сервер 1с находятся на разных машинах. В таком случае в технологическом журнале рабочего процесса можно наблюдать следующую картину:
56:39.487001-0,CONN,2,process=rphost,p:processName=accounting,t:clientID=39,t:applicationName=WebServerExtension,t:computerName=webserver,t:connectID=16,Txt=Srvr: SrcUserName1: [email protected]:39.487002-0,CONN,2,process=rphost,p:processName=accounting,t:clientID=39,t:applicationName=WebServerExtension,t:computerName=webserver,t:connectID=16,Txt=Srvr: DstUserName1: [email protected](DOMAIN701.COM\testuser2)56:39.596004-0,CONN,2,process=rphost,p:processName=accounting,t:clientID=39,t:applicationName=WebServerExtension,t:computerName=webserver,t:connectID=16,Txt=Srvr: DstUserName2: NT AUTHORITY\ANONYMOUS LOGON(NT AUTHORITY\ANONYMOUS LOGON)56:39.659003-0,EXCP,2,process=rphost,p:processName=accounting,t:clientID=39,t:applicationName=WebServerExtension,t:computerName=webserver,t:connectID=16,Exception=a01f465c-ed70-442e-ada5-847668d7a41c,Descr=’src\VResourceInfoBaseServerImpl.cpp(991):a01f465c-ed70-442e-ada5-847668d7a41c: Идентификация пользователя не выполненаНеправильное имя или пароль пользователя’
При возникновении такой ситуации необходимо проверить следующие настройки:
1) Убедиться, что процессы сервера 1С запущены от имени доменной учетной записи, входящей в группу Domain Users.
2) Убедиться, что веб-сервер IIS настроен корректно.
В публикации информационной базы найти настройки аутентификации
В настройках аутентификации отключить анонимную аутентификацию и включить Windows-аутентификацию. В Windows-аутентификации упорядочить доступных провайдеров так, чтобы на первом месте был Negotiate.
Пул приложений публикации не нуждается в настройках, в нем можно оставить все по умолчанию.
После изменения настроек перезапустить веб-сервер с помощью команды iisreset в командной строке.
3) Убедиться, что в контроллере домена в свойствах компьютера, на котором запущен веб-сервер, на вкладке делегирование установлено «Доверять компьютеру делегирование любых служб (только Kerberos)»
Для этого откройте оснастку Active Directory Users and Computers (dsa.msc), в компьютерах найдите веб-сервер, перейдите в его свойства и на вкладке Делегирование установить значение «Доверять компьютеру делегирование любых служб (только Kerberos)» и нажать применить.
4) Убедиться, что на клиенте в свойствах обозревателя разрешена встроенная проверка подлинности Windows.
После выполнения всех действий необходимо перезагрузить клиентский компьютер (рабочие серверы перезагрузки не требуют) и убедиться, что аутентификация операционной системы успешно выполняется.
Важно: аутентификации Windows при расположении веб-сервера IIS и рабочих серверов на разных машинах в тонком клиенте работает, начиная с версии 8.3.10.2620 (для тестирования)
2013: Двухфакторная аутентификация мобильных транзакций
Ученые из корпорации IBM разработали и представили в октябре 2013 года новую мобильную технологию защиты с помощью аутентификации на основе стандарта беспроводной связи малого радиуса действия (near-field communication, NFC). Технология обеспечивает дополнительный уровень защиты доступа в корпоративную сеть или частное облако при проведении транзакций посредством мобильных устройств, поддерживающих NFC, и бесконтактных смарт-карт.
Согласно результатам отчета исследовательской компании ABI Research, в 2014 г. количество используемых устройств с функцией NFC превысит 500 миллионов. Эти данные, а также тот факт, что к 2017 г. 1 млрд. мобильных пользователей будет совершать банковские транзакции с помощью своих устройств*, подтверждают растущий риск утери данных в связи с мошеннической деятельностью.
Для решения этой проблемы сотрудники лаборатории IBM в Цюрихе, которые также создали операционную систему, обеспечивающую функционирование и безопасность сотен миллионов смарт-карт, разработали дополнительный уровень защиты мобильных транзакций, подразумевающий двухфакторную аутентификацию.
Многие пользователи уже применяют двухфакторную аутентификацию при работе на компьютере, к примеру, вводя не только пароль, но и код подтверждения, полученный в SMS-сообщении. Ученые из IBM применили тот же принцип при обработке номера персональной идентификации (PIN-кода) и использовании бесконтактной смарт-карты. Смарт-карта может быть выпущена банком для обслуживания в банкоматах или работодателем в качестве удостоверения сотрудника.
Как работает технология
Пользователь держит смарт-карту вблизи NFC-считывателя своего мобильного устройства. После ввода PIN-кода карта генерирует одноразовый код, затем направляя его серверу посредством мобильного устройства.
Технология IBM основывается на абонентском шифровании передачи данных между смарт-картой и сервером по стандарту Advanced Encryption Standard (AES), одобренному Национальным институтом стандартов и технологий (NIST). Современные мобильные технологии, представленные на рынке, требуют наличия у пользователя, к примеру, генератора случайных паролей, что не всегда удобно и в некоторых случаях менее надежно.
Результаты нового исследования IBM Institute for Business Value, проведенного среди «мобильных» предприятий, подтвердили, что организации осознают важность обеспечения высокого уровня безопасности мобильных транзакций. По итогам опроса специалистов, безопасность находится на втором месте в списке наиболее сложных задач предприятия.
Изменение переменных, свойств объектов и асинхронные вычисления выражений
Новый механизм отладки позволяет вам изменять значения переменных в процессе отладки. В прежнем механизме такая возможность отсутствовала.
Для удобного просмотра и изменения локальных переменных, что представляется наиболее частой задачей, мы реализовали окно «Локальные переменные».
Внешне оно очень похоже на привычное вам «Табло». Но, во-первых, это окно уже автоматически заполнено всеми локальными переменными, а во-вторых, значения переменных вы можете теперь менять.
Значения примитивных типов вы можете изменить прямо в ячейке «Значение»:
А для изменения других значений вы можете воспользоваться окном ввода выражений:
Приятным бонусом является то, что в этом окне полностью функционирует контекстная подсказка.
Точно таким же образом вы можете изменять и значения любых (не только локальных) переменных, свойств, доступных для записи. В окне вычисления выражений (которое вызывается командой Shift+F9) вы можете менять значения переменных как в ячейке «Значение», так и с помощью отдельного диалога.
Кстати, само вычисление выражений теперь выполняется асинхронно. Это означает, что конфигуратор заказывает вычисление предмета отладки. И некоторое время это вычисление ожидается на сервере. Если вычисление выполнено, то результаты сразу поступают в конфигуратор. Если вычисление выполняется продолжительное время, то результаты этих вычислений асинхронно приходят в конфигуратор позже. Такой подход позволяет вам не ожидать длительных вычислений в конфигураторе, и продолжить свою работу.
Сильные и слабые стороны многофакторной аутентификации
К преимуществам можно отнести её способность защитить информацию, как от внутренних угроз, так и от внешних вторжений. Определенной слабостью можно считать необходимость использования дополнительных программно-аппаратных комплексов, устройств хранения и считывания данных. В то же время, в настоящий момент статистика взломов систем, применяющих двухфакторную аутентификацию, отсутствует или ничтожна.
Многофакторная или расширенная аутентификация уже сегодня применяется рядом российских компаний в сфере финансов при создании сервисов интернет-банкинга, мобильного банкинга, файлообмена и т.п. решений для конечных пользователей. Она основана на совместном использовании нескольких факторов аутентификации (знаний, средств или объектов хранения одной из информационных составляющих легитимной процедуры аутентификации), что значительно повышает безопасность использования информации, по меньшей мере, со стороны пользователей, подключающихся к информационным системам по защищенным и незащищенным каналам коммуникаций.
В качестве примера может послужить процесс двухфакторной аутентификации пользователя, реализованный в рядом российских банков: вход в личный кабинет пользователя посредством сети интернет возможен после ввода пароля на странице, после чего (в случае подтвержденной правомерности), следует передача одноразового пароля (в виде SMS) на мобильный телефон, ранее зарегистрированный пользователем.
Аналогичные схемы контроля и управления полномочиями пользователя, его дальнейших действий в корпоративных или других информационных системах, могут быть реализованы с применением самых различных средств и методов, выбор коих достаточно широк, как по технологичности, стоимости, исполнению, так и по возможным комбинациям перечисленных свойств.
Сессия работы пользователя может также контролироваться на предмет соответствия, как IP-адреса последней успешно завершенной сессии, так и MAC-адреса соответствующего сетевого оборудования. Далее могут идти действия подтверждения или отказа в доступе к информационным ресурсам, но доверия к этим двум параметрам контроля быть не может в силу их технологической слабости: IP-адрес можно подменить, а MAC-адрес просто переписать в ходе работы системы, и даже без перезагрузки. Тем не менее, в качестве неких контрольных значений эти сведения могут быть использованы.
Обратная сторона многофакторной аутентификации
Первой проблемой многофакторной аутентификации является способ ее реализации. В настоящее время самым популярным вторым фактором, используемым поставщиками сервиса, является одноразовый пароль one time password — OTP.
Применяя данный тип 2FA пользователь вводит на первом уровне аутентификации персональный пароль. На следующем этапе он должен ввести маркер ОТР, обычно отправляемый с помощью SMS на его мобильное устройство. Идея способа понятна. ОТР будет доступен только тому, кто, как предполагается в теории, ввел недоступный постороннему пароль.
Однако, увы, отправлять OTP в SMS, вообще говоря, небезопасно, так как часто сообщения отправляются открытым текстом. Даже начинающие хакеры могут прочесть подобные текстовые сообщения, ведь фактически все, что им нужно — целевой номер телефона.
Кроме того, многофакторная аутентификация не в состоянии предотвратить атаки класса MitM, которые часто используются в ходе фишинговых компаний с помощью электронной почты. В случае успеха атаки пользователь перейдет по мошеннической ссылке и попадет на сайт, похожий на онлайн-портал банка. Там пользователь введет информацию о входе в систему и другие конфиденциальные данные, которые будут использоваться злоумышленником чтобы получить доступ к реальному сайту.
И хотя данная атака будет возможна для осуществления только ограниченный период времени, она все же возможна.
Пошаговая настройка прав доступа в 1С
Расскажем, как настроить права доступа на примере программы «1С:Бухгалтерия 8 редакция 3.0»
Однако обратите внимание, что аналогичным образом настраиваются права доступа для пользователей и в других программных продуктах 1С. Например, инструкция также подойдет к «1С:Управление торговлей», «1С:Зарплата и управление персоналом», «1С:ERP» и другим ПП.
Шаг №1. Настройка пользователей и прав
В самом начале необходимо зайти в раздел настроек программы и выбрать раздел «Настройка пользователей и прав».
Это действие можно также выполнить на вкладке «Администрирование», если у вас есть необходимые права для действий.
Если Вы делаете настройку прав своей 1С впервые, рекомендуем оставить бесплатную заявку в поддержку по 1С через сервис Бит.Личный кабинет. Вам перезвонит консультант по 1С и поможет.
Шаг № 2. Пользователи
Для того, чтобы увидеть, к какую группу доступа входит отдельный пользователь, нужно перейти в раздел «Пользователи». Здесь можно создать нового пользователя 1С или выполнить редактирование для уже существующего или целой группы.
Важно! Вы сможете управлять данными списками и вносить изменения только в том случае, если сами имеете права администратора.
Чтобы создать необходимую группу пользователей, их можно выбрать из базы. Здесь нужно проверить, что установлены флажки «Вход в программу разрешен» и «Показывать в списке выбора». Если их не будет, то при авторизации пользователь себя не увидит.
Шаг № 3. Роли для группы
Итак, в нашей программе пользователи входят в группы с разрешенным доступом. Например, можно создать группу бухгалтеров, администраторов, кассиров, логистов и т.д. Отметим, что один и то же пользователь может относиться к нескольким разным группам. У каждой из групп прописываются роли.
Что такое роль? Это метаданные. От конфигурации вашей 1С будет зависеть, сколько их и какие они
Обычно их довольно много, поэтому важно не запутаться. Ведь вы можете назначить только одну лишнюю роль, а пользователю уже откроется доступ ко многим действиям.
Чтобы узнать, какие права откроются пользователю, нужно перейти во вкладку «Описание».
Роли могут быть базовыми, которые позволяют только просматривать документ. Могут быть специальными, когда открывается доступ для редактирования.
Шаг № 4. Профиль групп доступа
Допустим, что вам необходимо разрешить группе бухгалтеров редактировать реквизиты объектов. Для этого зайдите в раздел «Профиль групп доступа». Установите флажок «редактировать реквизиты объектов».
Примечание: для редактирования ролей целесообразно предварительно скопировать нужную роль, и уже скопированную роль менять. При этом кнопка «Только выбранные» должна быть «отжатой» (см скриншот ниже), поскольку в типовых профилях показываются только используемые роли.
Шаг № 5. Ограничение на уровне записей
Речь идет о RLS (Record Level Security). Вы найдете необходимую колонку в «Отчете по правам пользователя», в разделе «Права доступа». Чтобы работать с ограничение на уровне записей, нужно установить соответствующий флажок во вкладке.
Для чего необходима эта функция? Это дополнительные условия, которые могут поставить ограничения на конкретный объект в базе данных. Очень удобно, если нужно закрыть доступ к файлу отдельного пользователя или группы. При этом программа предупредит, что данные настройки могут замедлить работу системы.
Почему? В этом случае система 1С каждый раз будет запрашивать информацию о том, разрешено ли пользователю просматривать какой-то файл.
Вы также можете перемещать пользователя по группам в 1С, чтобы изменить права доступа.
Шаг № 6. Новые роли
Чтобы не путаться в бесконечном разнообразии ролей, рекомендуем создать собственные роли. Для этого зайдите в дерево метаданных.
Разграничить права в новой роли можно путем выставления необходимых флажков напротив нужного вам права.
Задать ограничение можно в правом нижнем углу. Здесь работает механизм настройки прав доступа по отношению к конкретным данным.
К примеру, вы можете ограничить изменение документа только по одной организации.
Используйте конструктор ограничений доступа. Он поможет выбрать необходимые условия для доступа. Кроме того, программа предложит вас шаблоны ограничений, которые останется только выбрать и добавить.
Примечание: для создания новых ролей в режиме Конфигуратора необходимо включить возможность изменения конфигурации.
Создание новых ролей возможно так же в пользовательском режиме (с ограничениями) — см. примечание в «Шаг №4».
Авторизация пользователя при обращении к web сервису 1С
Если попытаться получить доступ к web сервису опубликованному под Apache не исправляя файл default.vrd, то появиться стандартный диалог авторизации:
Диалог авторизации на web сервисе 1С
В тестовой базе был заведен тестовый пользователь IUSR с полными правами с пустым паролем. Если ввести в диалог в качестве логина этого пользователя, то авторизация пройдет успешно и отобразиться либо XML файл, либо ссылка на него (см. выше).
Можно исключить запрос авторизационной информации вбив логин и пароль прямо в файл default.vrd, что, конечно, не рекомендуется с точки зрения безопасности, но иногда необходимо.
http://v8.1c.ru/8.2/virtual-resource-system http://www.w3.org/2001/XMLSchema http://www.w3.org/2001/XMLSchema-instance |
Это все. В моем случае каких-то дополнительных правок конфиг файлов не потребовалось.
В некоторых статьях указывалось, что нужно убрать из httpd.conf опцию «Options None«. У меня работает в обоих вариантах, т.е. когда строка присутствует и когда она удалена.
Архитектура процесса отладки
Новая архитектура отладки выглядит следующим образом:
В отладке участвуют отладчик, предметы отладки и новый элемент — сервер отладки.
Прямой передачи информации между отладчиком и предметами отладки нет. Всё взаимодействие организуется через сервер отладки. Это основной элемент механизма. На сервере отладки организована очередь сообщений, через которую отладчик и предметы отладки передают информацию друг другу.
И сам отладчик, и предметы отладки взаимодействуют с сервером отладки по протоколу HTTP
Таким образом теперь неважно, где эти предметы отладки расположены.. Взаимодействие с сервером отладки выполняется по инициативе отладчика и предметов отладки
Для этого организуются дополнительные соединения. Их основное назначение — узнать, не появилась ли для них информация на сервере отладки. И если появилась, получить эту информацию.
Взаимодействие с сервером отладки выполняется по инициативе отладчика и предметов отладки. Для этого организуются дополнительные соединения. Их основное назначение — узнать, не появилась ли для них информация на сервере отладки. И если появилась, получить эту информацию.
Таким образом, взаимодействие получается одностороннее. Информация всё время передаётся с сервера отладки в отладчик, и в предметы отладки.
Правильный линк на сервис
В некоторых статьях путь к web сервису указан как: http://имя_сервера:порт/имя_при_публикации/alias?wsdl.
В моем случае:
- Имя сервера: s-1s-1-hw
- Порт: 8080
- Имя при публикации: wsApache
- Alias из файла default.vrd: service.1cws
Соответственно, НЕПРАВИЛЬНАЯ ссылка на web сервис 1С такая: http://s-1c-1-hw:8080/wsApache/service.1cws?wsdl
Если использовать такой линк, то 1C 8.2 выдаст сообщение вида:
Правильный вариант:
http://имя_сервера:порт/имя_при_публикации/ws/alias?wsdl.
Это обращение эквивалентно обращению по имени сервиса из default.vrd:
http://имя_сервера:порт/имя_при_публикации/ws/name?wsdl.
В моем случае:
Name из файла default.vrd: Service
Соответственно, ПРАВИЛЬНЫЙ линк для доступа к web сервису 1С будет такой:
http://s-1c-1-hw:8080/wsApache/ws/service.1cws?wsdl
или такой
http://s-1c-1-hw:8080/wsApache/ws/service?wsdl
Если указать ссылку с суффиксом ?wsdl, то в веб браузере отобразиться XML файл с описанием опубликованного сервиса.
Если указать ссылку без суффикса ?wsdl, то при правильной настройке должна появится страница с гиперссылкой на опубликованный сервис:
Политики доступа
Политики доступа содержат сведения о том, кому и на какие разрезы доступа назначены права. Разрезы задают границы областей данных, с которыми разрешено работать пользователям: виды внутренних документов, виды входящих документов и т.д.
С помощью политик доступа можно задать как общие настройки прав для рабочих групп и подразделений, так и доступ к определенному виду документа или вопросу деятельности конкретному пользователю.
Существуют следующие политики доступа:
- Общие разрешения — для быстрой настройки прав.
- Специальные разрешения — для гибкой настройки прав.
- Локальные администраторы — для назначения прав, которые не зависят от настроек рабочих групп.
Рекомендуется назначать права не отдельным пользователям, а подразделениям, рабочим группам, ролям исполнителей. Пользователю может быть выдано одно или несколько разрешений, которые в совокупности образуют его персональные настройки прав.
На закладке «Общие разрешения» приведены разрезы доступа, на которые назначаются права.
Каждому пользователю можно указать уровень доступа: Чтение, Редактирование, Регистрация. Разрешения одного разреза доступа можно скопировать другому.
Для более тонкой настройки предназначены Специальные разрешения. За их включение/отключение отвечает настройка «Использовать специальные разрешения в политиках доступа». Открыть её можно выбрав «Настройка и администрирование – Настройка программы – Права доступа».
Как работают политики доступа
При расчете прав политики доступа применяются следующим образом. Если для пользователя или его рабочей группы есть специальные разрешения, то действуют они. Если специальных разрешений нет, действуют общие разрешения.
Общие разрешения работают так: доступ к объекту (документу, мероприятию и т. д.) дается пользователю или его рабочей группе, у которого есть доступ ко всем разрезам доступа объекта: организации, грифу, вопросу деятельности.
Специальные разрешения действуют следующим образом:
- На пользователя может действовать сразу несколько специальных разрешений.
- Настройки нескольких специальных разрешений не расширяют друг друга.
Рекомендуется использовать Специальные разрешения только в том случае, если нужную Вам комбинацию нельзя настроить с помощью Общих разрешений.
Локальные администраторы
Назначить локальных администраторов значит назначить пользователям доступ, который не зависит от рабочих групп и настроек прав папок. Например, начальнику договорного отдела можно назначить неограниченный доступ на чтение всех договоров организации. Начальник получит доступ к договору, даже если не входит в его рабочую группу.
Возможность включается одноименной настройкой: «Настройка программы – Права доступа – Локальные администраторы».
Локальные администраторы назначаются в политиках доступа. Принцип настройки повторяет специальные разрешения:
- разрешение назначается для конкретного предмета,
- можно выбрать произвольные комбинации разрезов доступа,
- пользователю можно выдать несколько разрешений по одному предмету.
Обратите внимание: разрешения локальных администраторов не отменяют общие и специальные разрешения, а дополняют их
Настройка политик в разрезе подразделений
Политики доступа удобно настраивать в разрезе подразделений.
По умолчанию использование разреза «Подразделения» отключено. Для включения достаточно установить флажок: «Настройка программы – Права доступа – Используемые разрезы доступа – Подразделения». В общих разрешениях в контекстном меню разреза «Подразделения» доступна команда «Заполнить по умолчанию».
При выполнении этой команды для каждого подразделения, не содержащего подчиненных, добавляются разрешения для всех его сотрудников.
2016
SMS-пароли признаны небезопасными
Национальный Институт стандартов и технологий США (The National Institute of Standards and Technology, NIST) представил летом 2016 года предварительную версию будущего Digital Authentication Guideline (документа, который установит новые нормы и правила в отношении цифровых методов аутентификации): механизм SMS OTP изначально для аутентификации не предназначался и не может считаться полноценным фактором аутентификации.
В документе содержится прямое указание на то, что использование SMS-сообщений для двухфакторной аутентификации может являться «недопустимым» и «небезопасным» (секция документа 5.1.3.2).
Основные опасения экспертов Национального института стандартов и технологий сводятся к тому, что номер телефона может быть привязан к VoIP-сервису, кроме того, злоумышленники могут попробовать убедить поставщика услуг в том, что номер телефона изменился, и подобные уловки нужно сделать невозможными.
Хотя документ рекомендует производителям использовать в своих приложениях токены и криптографические идентификаторы, авторы поправок также отмечают, что смартфон или другое мобильное устройство всегда могут быть украдены, или могут временно находиться в руках другого человека» — говорится в документе NIST.
Механизмов компрометации SMS паролей существует достаточно много, и они уже были неоднократно использованы в основном для похищения денежных средств клиентов российских банков. Достаточно перечислить лишь несколько методов взлома SMS паролей:
- Замена SIM карты с использованием поддельных документов
- Использование уязвимостей в протоколе OSS-7
- Переадресация вызовов у оператора мобильной связи
- Ложные базовые станции
- Специализированные троянские программы для смартфонов, перехватывающие SMS пароли
Еще одним методом может считаться взлом шлюза между банком и оператором связи.
То обстоятельство, что механизм SMS-паролей используется всеми банками, открывает для хакеров широкие перспективы. Очевидно, что написав один раз троян для смартфона, его можно использовать для атаки на все российские банки, при его (трояна) минимальной кастомизации.
При этом можно предсказать, что первыми «под раздачу» будут попадать крупные банки – большая клиентская база последних позволяет мошенникам рассчитывать на весомый результат даже при небольших остатках на счетах клиентов.
Одноразовые пароли через SMS
- задержки в доставке
- возможность перехвата на уровне канала связи или ввода в систему
- возможность перехвата на уровне оператора мобильной связи
- возможность переоформления сим-карты клиента на мошенника по поддельной доверенности (и перехвата SMS)
- возможность направления клиенту SMS-сообщений с подменного номера
- рост операционных затрат пропорционально клиентской базе
Одноразовые пароли через PUSH
- негарантированная доставка
- прямой запрет Apple//Microsoft на использование для передачи конфиденциальной информации
- предназначение – только информирование
Исследователи продемонстрировали простую атаку для обхода двухфакторной аутентификации
Ученые из Амстердамского свободного университета Радхеш Кришнан Конот (Radhesh Krishnan Konoth), Виктор ван дер Вен (Victor van der Veen) и Герберт Бос (Herbert Bos) продемонстрировали практическую атаку на двухфакторную аутентификацию с использованием мобильного устройства. Исследователи продемонстрировали атаку «Человек в браузере» (Man-in-the-Browser) против смартфонов на базе Android и iOS.
Проблема с двухфакторной аутентификацией возникла из-за увеличения популярности смартфонов и желания владельцев синхронизировать данные между различными девайсами. Двухфакторная аутентификация полагается на принцип физического разделения устройств для защиты от вредоносного ПО. Однако синхронизация данных делает подобную сегментацию абсолютно бесполезной.
Исследователи продемонстрировали атаку с использованием установки уязвимого приложения через Google Play. Им удалось успешно обойти проверку Google Bouncer и активировать приложение для перехвата одноразовых паролей.
Для атаки на iOS исследователи использовали новую возможность OS X под названием Continuity, позволяющую синхронизировать SMS-сообщения между iPhone и Mac. Если этот функционал активирован, злоумышленнику достаточно иметь доступ к компьютеру, чтобы прочитать все SMS сообщения.
Согласно исследователям, приложение для хищения одноразовых паролей было добавлено в Google Play 8 июля 2015 года и оставалось доступно для пользователей в течение двух месяцев, до выхода видео с демонстрацией атаки.
Компания Apple была уведомлена 30 ноября 2015 года, однако исследователи не получили ответ.
2017: Google отказывается от SMS при двухфакторной авторизации
планирует летом 2017 года вместо одноразовых кодов проверки, рассылаемых с помощью SMS, пользователям выводит экранные уведомления с просьбой подтвердить логин. Подобный подход считается более надёжным, нежели отправка секретных кодов через SMS, поскольку их сложнее перехватить.
В сообщениях от Google будут указываться устройство, с которого осуществляется логин, его физическое местоположение, а также время попытки входа. Пользователям необходимо будет внимательно следить за этой информацией, чтобы не допускать несанкционированного входа посторонних.
Переход на экранные уведомления предложат только тем пользователям Google, у которых двухфакторная аутентификация уже активирована. Предложение принимать не обязательно — предусмотрена опция сохранения отправки кода через SMS.
Права пользователя в 1С
Скажем несколько слов о правах пользователей. Что означает ограничение прав доступа? В разрезе программных продуктов 1С, это запрет на совершение действий с какими-либо файлами и объектами. Например, можно закрыть пользователю доступ для изменения документа, копирования и даже просмотра. Соответственно, расширить права доступа означает дать разрешение на просмотр, изменение документа, копирование, сохранение и т.д.
При правильной настройке 1С система всегда ответит пользователю, если ему нельзя совершить то или иное действие с объектом: «у вас недостаточно прав для редактирования».