Мейтейнер GM в ответном письме говорит, чтобы
(а) ему показали эксплойт для GM
(б) советует использовать переменную окружения MAGICK_CODER_STABILITY=PRIMARY
Про третий пункт: нет, нам кажется, что привлекая внимание пользователя к тому, куда он вводит пароли, мы не делаем его более беззаботным, а наоборот, делаем его более внимательным.
Если пользователь будет знать, что вводить пароль можно только в поле, фон у которого фиолетовый в оранжевую полоску, то он не станет вводить пароль в то, что выглядит иначе.
Спасибо, что обратили внимание на Яндекс.Браузер. Хочу немного прокомментировать.
1. Конечно, этот метод имеет свои ограничения и поэтому не является единственным методом защиты от фишинга. У нас, конечно же, есть и база плохих, фишинговых сайтах, о которых мы предупредим пользователя ещё до захода на них. Но от части generic-атак, не рассчитанных прицельно на Яндекс.Браузер, этот метод может уберечь.
К тому же мы работаем над тем, чтобы расширить его, в частности, сделать некоторые из описанных вами подходов тоже неработающими.
Но от произвольно нарисованного контрола, не являющегося инпутом, это не убережет, конечно. От него вообще, кажется, может уберечь только если мы будем выводить input type=password в особом, уникальном для каждого отдельного пользователя, дизайне, а пользователь будет внимательно за этим следить и не вводить свой пароль никуда, кроме полей ввода такого особого дизайна.
Кроме того, само по себе использование одного и того же пароля на разных сайтах, часть из которых может даже не работать по https — очень небезопасная вещь. Предупреждая о таких случаях, мы заметно повышаем безопасность учетных записей пользователя.
2. Перебор паролей через эту функцию сделать не получится, т.к. браузер отличает пользовательские события от эмуляции. Нам уже сообщали о возможности такой атаки в первой версии Яндекс.Браузера с этой возможностью и мы закрыли эту уязвимость и все похожие способы использовать нашу защиту для перебора в версии 15.12.
Яндекс.Браузер собирает обезличенную статистическую информацию для улучшения качества Браузера, в которую включаются в том числе и адреса посещённых страниц. Это происходит только в том случае, если человек разрешил делать это в настройках программы (проставил галочку «Отправлять в Яндекс статистику использования»).
Из-за технической ошибки информация о некоторых таких страницах из Браузера попала в список, индексируемый роботом Яндекса. Мы уже исправили её для сайта, о котором было рассказано на Хабре, и в скором времени исправим ее полностью. Мы благодарны пользователю Хабрахабра за то, что помог найти эту ошибку
Как вы думаете, зачем эта рабочая группа была создана?
Конечно же, пропозал на std::Stroka уже отправлен!
</joke>
(а) ему показали эксплойт для GM
(б) советует использовать переменную окружения MAGICK_CODER_STABILITY=PRIMARY
http://www.openwall.com/lists/oss-security/2016/05/04/3
С этим, мне кажется, браузер может побороться, впрочем, я недостаточно глубоко в теме, чтобы уверенно это утверждать.
По перебору пишу вам в личку.
Спасибо, что обратили внимание на Яндекс.Браузер. Хочу немного прокомментировать.
1. Конечно, этот метод имеет свои ограничения и поэтому не является единственным методом защиты от фишинга. У нас, конечно же, есть и база плохих, фишинговых сайтах, о которых мы предупредим пользователя ещё до захода на них. Но от части generic-атак, не рассчитанных прицельно на Яндекс.Браузер, этот метод может уберечь.
К тому же мы работаем над тем, чтобы расширить его, в частности, сделать некоторые из описанных вами подходов тоже неработающими.
Но от произвольно нарисованного контрола, не являющегося инпутом, это не убережет, конечно. От него вообще, кажется, может уберечь только если мы будем выводить input type=password в особом, уникальном для каждого отдельного пользователя, дизайне, а пользователь будет внимательно за этим следить и не вводить свой пароль никуда, кроме полей ввода такого особого дизайна.
Кроме того, само по себе использование одного и того же пароля на разных сайтах, часть из которых может даже не работать по https — очень небезопасная вещь. Предупреждая о таких случаях, мы заметно повышаем безопасность учетных записей пользователя.
2. Перебор паролей через эту функцию сделать не получится, т.к. браузер отличает пользовательские события от эмуляции. Нам уже сообщали о возможности такой атаки в первой версии Яндекс.Браузера с этой возможностью и мы закрыли эту уязвимость и все похожие способы использовать нашу защиту для перебора в версии 15.12.
Роман Иванов,
Яндекс.Браузер
Вот комментарий пресс-службы:
Ещё раз хочу повторить, что такого быть не должно.
Если у кого-то из читающих этот пост есть аналогичные примеры — присылайте тоже.
В личку либо на емейл kukutz на yandex-team.ru.
CatHap, можно Вас попросить настоящий лог, без цензуры, в личку прислать?
—
Роман Иванов,
Яндекс.Браузер