Да, я слежу за этой темой. Сделаю обновление, если будет что-то интересное. Обычно общественности становится известно что-то вроде скупого «злоумышленники завладели учетной записью администратора».
Дело в том, что оператор работает в SWIFT со своего рабочего компьютера, который обычно находится в локальной сети. Кстати, в качестве одного из уровня защиты SWIFT предлагает использовать еще так называемый jump server — промежуточный сервер, через который происходит доступ. Тогда оператор не обращается к защищаемым серверам напрямую, а взаимодействует с jump server'ом.
Помимо того, что Safari совершенно бесцеремонно скрывает адресную строку, есть и другие проблемы. В других браузерах для разных сайтов, принадлежащих разным юр.лицам с одинаковым названием, может отображаться одинаковый текст в зеленой полосе EV сертификата.
По сути нет какого-то гарантированного преимущества от этих EV сертификатов, о чем собственно и пост.
Интересно узнать количество респондентов в ваших опросах. Хотя я думаю, что выборка среди студентов не будет показательной для всех.
В последнем опросе: «Что бы вы предпочли в качестве второго шага двухфакторной аутентификации для процедуры входа в систему?» два варианта ответа неразличимы между собой:
Подтверждение с помощью приложения
Аутентификация с помощью приложения
И еще я сильно сомневаюсь, что опрашиваемые пользователи испытали все эти методы аутентификации. Например, аутентификация через мобильное приложение (не одноразовые коды), очень удобна, но мало кто ее вообще видел вживую.
Похоже, что сертификаты входят в группу «Токен». Наверно автор сделала допущение, что пользователю не важно, что за токен, а важно сам факт использования дополнительного устройства в процессе аутентификации.
Мне статья показалась несколько хаотичной, несвязанной и обрывочной. Однако про ту часть, которая касается аутентификации, я бы хотел вставить свои 5 копеек.
Чтобы аутентификация была двухфакторной надо, чтобы «два способа подтверждения личности» были из разных доменов: что я знаю, что я имею, чем я являюсь(биометрия).
К способам(методам) аутентификации можно добавить одноразовые пароли, которые значительно отличаются от рандомно сгенерированных кодов, получаемых по СМС.
Отпечаток пальца — не единственный биометрический метод аутентификации, который сейчас используется. Еще есть основанные на сканировании лица, сетчатки глаза, радужной оболочки глаза, анализе голоса или почерка, замерах сердечного ритма и другие.
То, что вы называете «флеш токен», на самом деле только частный пример PKI аутентификации или аутентификации по сертификатам. Закрытый ключ может быть и на смарт карте и на криптографическом токене. В самом плохом случае закрытый ключ может храниться на флэшке.
Про push аутентификация добавлю, что обычно она основана на асимметричной криптографии, что в принципе делает ее близкой к PKI аутентификации. Хотя я встречал и варианты, когда push канал использовался для простой передачи одноразовых кодов по аналогии с СМС.
Добавлю к вашему ответу, что есть еще и другие методы аутентификации. Например, FIDO U2F просто и красиво защищает от фишинга тем, что текущий URL является одним из параметров, которые отправляет браузер. Таким образом, если пользоавтель на фишинговом сайте, то URL этого сайта не позволит пройти аутентификацию успешно.
Поэтому надо соблюдать ряд правил, а не выборочно. Одного https недостаточно. Нужно и на домен смотреть, а лучше — писать вручную или открывать из закладок.
Должны были, конечно, предупредить. Менял симку около месяца назад и обрадовался, когда меня об этом уведомили. Правда потом понял, что не могу сбросить PIN (по СМС) для мобильного приложения оплаты парковки в самый неподходящий момент.
С учетом всех минусов, все равно считаю, что в наших реалиях блокировка услуги СМС на сутки больше добро, чем зло.
Еще раз: если для аутентификации вам надо запрашивать статус токена любым способом, то вы теряете stateless. Совсем не важно, одна дата для всех токенов или для каждого индивидуальная. При масштабировании вам придется поддерживать актуальность этой даты на всех серверах.
Пожалуйста, не надо меня убеждать, что это совсем чуть-чуть информации или что это легко и просто сделать. Я не это оспариваю сейчас.
Вы предлагаете по сути хранить в БД время жизни токена. Так мы пришли к противоречию, так как предложенная вами реализация совсем не stateless.
Для задач, когда хочется и токены использовать и контролировать статус токена, удобнее использовать список отозванных токенов по аналогии CRL для сертификатов.
Последние тенденции парольной аутентификации — в отказе от требования регулярной смены паролей и требований сложности. Менять пароли следует в случае подозрения в компрометации, а не на регулярной основе.
Очень хорошая статья на эту тему: Passwords Evolved: Authentication Guidance for the Modern Era. Кажется, где-то был перевод на Хабре, но я не смог найти.
Пробежался по ссылкам компаний и был просто в шоке. Более трети сайтов (в том числе оба ваших лидера сравнения) не поддерживает HTTPS на своем сайте. Наткнулся даже на форму входа в личный кабинет, которая по HTTP пароль предлагает отправить.
Понял, как я заблуждался, ожидая увидеть где-то двухфакторную аутентификацию.
Печально, но это объясняет отсутствие такого критерия сравнения. Хотя не удивлюсь, что кто-то может такое предлагать, если спросить.
Спасибо вам за то, что поделились результатами проделанной работы.
Очень хотелось бы, чтобы критериями оценки помимо прочего были и аспекты информационной безопасности, такие как двухфакторная аутентификация при входе в личный кабинет или на RDP.
Согласен, это пожалуй более важная ошибка, чем самопиар мэйлру.
Для тех, кто не в теме:
Двухшаговая аутентификация отличается от двухфакторной тем, что при двухфакторной вы не знаете результат проверки первого фактора, пока не введете оба фактора. Результат для вас будет либо успех (оба фактора верны) либо неудача (как минимум один из факторов неверный). В двухшаговой вы сначала узнаете, что успешно ввели первый фактор и только после этого вам предлагается ввести второй фактор. То есть тут есть возможность провести атаку сначала на один фактор, а потом проводить атаку на второй. Это зачастую упрощает задачу злоумышленника и по праву считается менее защищенным способом аутентификации.
Клиент в случае с Ericom — это обычный браузер. Толстый клиент вроде mstsc не требуется. То есть такое решение не требует поддержки дополнительнго софта (rdp-клиента) и будет работать даже на каком-нибудь хромобуке или ПК, где ограничен список разрешенных программ.
Если быть точным, то задача была рализовать защищенный доступ к RDP с использованием двухфакторной аутентификации. Кроме RDP были и другие приложения и сервисы, поэтому решение было выбрано совместное с сервером многофакторной аутентификации.
Делать многофактоную аутентификацию с использованием стандартного mstsc та еще задача и обычно все решается построением VPN с двухфакторкой + обычный RDP. А значит к RDP-клиенту добавляется еще софт, необходимый на клиенте — VPN-клиент. К тому же не все методы можно использовать для такой аутентификации.
А в моем случае все ограничивается браузером. Такой себе клиентлесс RDP с многофакторной.
Добавил апдейт в статью.
То есть судя по всему, деньги-то вывели, но сколько именно неизвестно.
По сути нет какого-то гарантированного преимущества от этих EV сертификатов, о чем собственно и пост.
В последнем опросе: «Что бы вы предпочли в качестве второго шага двухфакторной аутентификации для процедуры входа в систему?» два варианта ответа неразличимы между собой:
И еще я сильно сомневаюсь, что опрашиваемые пользователи испытали все эти методы аутентификации. Например, аутентификация через мобильное приложение (не одноразовые коды), очень удобна, но мало кто ее вообще видел вживую.
Чтобы аутентификация была двухфакторной надо, чтобы «два способа подтверждения личности» были из разных доменов: что я знаю, что я имею, чем я являюсь(биометрия).
К способам(методам) аутентификации можно добавить одноразовые пароли, которые значительно отличаются от рандомно сгенерированных кодов, получаемых по СМС.
Отпечаток пальца — не единственный биометрический метод аутентификации, который сейчас используется. Еще есть основанные на сканировании лица, сетчатки глаза, радужной оболочки глаза, анализе голоса или почерка, замерах сердечного ритма и другие.
То, что вы называете «флеш токен», на самом деле только частный пример PKI аутентификации или аутентификации по сертификатам. Закрытый ключ может быть и на смарт карте и на криптографическом токене. В самом плохом случае закрытый ключ может храниться на флэшке.
Про push аутентификация добавлю, что обычно она основана на асимметричной криптографии, что в принципе делает ее близкой к PKI аутентификации. Хотя я встречал и варианты, когда push канал использовался для простой передачи одноразовых кодов по аналогии с СМС.
С учетом всех минусов, все равно считаю, что в наших реалиях блокировка услуги СМС на сутки больше добро, чем зло.
Пожалуйста, не надо меня убеждать, что это совсем чуть-чуть информации или что это легко и просто сделать. Я не это оспариваю сейчас.
Для задач, когда хочется и токены использовать и контролировать статус токена, удобнее использовать список отозванных токенов по аналогии CRL для сертификатов.
Очень хорошая статья на эту тему: Passwords Evolved: Authentication Guidance for the Modern Era. Кажется, где-то был перевод на Хабре, но я не смог найти.
Понял, как я заблуждался, ожидая увидеть где-то двухфакторную аутентификацию.
Спасибо вам за то, что поделились результатами проделанной работы.
Для тех, кто не в теме:
Двухшаговая аутентификация отличается от двухфакторной тем, что при двухфакторной вы не знаете результат проверки первого фактора, пока не введете оба фактора. Результат для вас будет либо успех (оба фактора верны) либо неудача (как минимум один из факторов неверный). В двухшаговой вы сначала узнаете, что успешно ввели первый фактор и только после этого вам предлагается ввести второй фактор. То есть тут есть возможность провести атаку сначала на один фактор, а потом проводить атаку на второй. Это зачастую упрощает задачу злоумышленника и по праву считается менее защищенным способом аутентификации.
Если быть точным, то задача была рализовать защищенный доступ к RDP с использованием двухфакторной аутентификации. Кроме RDP были и другие приложения и сервисы, поэтому решение было выбрано совместное с сервером многофакторной аутентификации.
Делать многофактоную аутентификацию с использованием стандартного mstsc та еще задача и обычно все решается построением VPN с двухфакторкой + обычный RDP. А значит к RDP-клиенту добавляется еще софт, необходимый на клиенте — VPN-клиент. К тому же не все методы можно использовать для такой аутентификации.
А в моем случае все ограничивается браузером. Такой себе клиентлесс RDP с многофакторной.