Как стать автором
Обновить

Как мы создавали менеджер паролей со стойкой криптографией и мастер-паролем. Опыт команды Яндекс.Браузера

Время на прочтение 9 мин
Количество просмотров 50K
Всего голосов 87: ↑85 и ↓2 +83
Комментарии 178

Комментарии 178

Отдельное приложение будет? Интеграция с генераторами одноразовыми паролями?

Сейчас мы тестируем решение в браузере. От результатов и спроса зависят дальнейшие планы.
А что по поводу Я.Ключа для мобильных телефонов? Будет какая-нибудь интеграция, или Ключ по-прежнему останется standalone продуктом для безопасного логина?
Прямо сейчас Ключ мы не трогаем. Вокруг него разные интересные идеи, нужно подумать.
Кстати. Давным-давно было обещано, что алгоритм яндекс-ключа будет опубликован. Это произошло?
Поддерживаю. Хранить пароли просто в браузере не серьёзно, это будет актуально только для неопытных пользователей. Для более продвинутых важно иметь возможность в любой момент перейти на другой браузер, а так же хранить пароли, связанные не только с сайтами и веб-сервисами.

И тем не менее, это хорошая новость. Именно за такие фичи я когда-то установил родителям Яндекс-браузер, а не Хром.

Познавательно, красиво и… опасно. Появятся трояны, специализированные для кражи всех сохраненных паролей из браузера. Принцип достаточно прост — "подсмотреть" мастер-пароль при вводе кейлоггером или пропатчить исполняемый код браузера на диске/непосредственно в памяти. Когда пользователь введет мастер-пароль, все его пароли будут расшифрованы и переданы.

При локальном трояне и сторонние менеджеры паролей не помогут. Но! У нас в бете ещё одна штука тестируется. Она запрещает вмешиваться в процесс браузера и перехватывать клавиатуру. Это должно снизить риск.

Да, это общая проблема всех менеджеров паролей, особенно самых популярных. Про "штуку" — верится с трудом в юзермоде. Заточенный под вас троян всё это обойдет.


Я пришел к выводу, что менеджер паролей надо или иметь в бумажном виде, или на отдельном устройстве, или писать самому.

Бумажный вид не имеет надежного шифрования, а значит любой неожиданный гость: знакомый, друг, племянник или человек в погонах легко воспользуется вашими записями. Даже если не учитывать, что человек в погонах получит ваши пароли в любом случае, будь они хоть чем зашифрованы.

Безусловно хранилище с менеджером паролей необходимо более достойно защищать — права доступа явно ограничивать, как минимум, для внесения изменений (отдельный пользователь, администратор и etc); использовать фаервол для ограничения выхода в сеть всяких кейлогеров, даже если антивирусная защита их вдруг пропустила.

Согласитесь, такая методика имеет право на существование? А то read-only начитаются хабра и пойдут массово за блокнотами :)

Я думаю, не-айтишникам значительно проще защитить от несанкцированного доступа блокнот, чем файл на компе. Это нетривиальная задача. Например, с файрволлом всё не так просто — трояны наловчились отправлять данные через браузер, через виндовые системные сервисы и т.п.


Самый "правильный" вариант — отдельное устройство с шифрованием) Телефон например, если не ставить на него что попало.

Тут так и напрашивается ссылочка на аппаратный менеджер паролей. Например, Pastilda https://bitbucket.org/thirdpin_team/pastilda
Правда есть всё таки есть несколько проблем, такие как:


  • паяльник;
  • оставил пастильду включенной и разблокированной, можно быстренько прибежать и слямзить пароль.
    Но по крайней мере мастер пароль будет в безопасности всегда.
Крутая штука! Можно развить до отдельной клавиатуры со встроенным менеджером паролей :)
Разумеется, заточенный под конкретное (в том числе — самописное) решение троян сможет сломать это конкретное решение. Как говорится, «если именно вашу машину решили угнать, ее угонят».
Но от более общего трояна, ориентированного на кражу паролей из Chromium-подобных браузеров, это вполне спасет.
А защищённый режим UAC не спасает от перехвата паролей кейлогерами? Как это сделано в KeePass
Спасает, если малварь не смогла поднять локальные привелегии и работает с правами пользователя.
Появятся трояны, специализированные для кражи всех сохраненных паролей из браузера.

Что же ещё готовит для нас грядущий 2004-й год?

Такие трояны существуют с появления возможности сохранить пароль в приложениях. Автор «учебного трояна» когда-то много писал про механизмы защиты и даже сделал антименеджер паролей.
Принцип достаточно прост — "подсмотреть" мастер-пароль при вводе кейлоггером

В том же 1Password против кейлоггера есть режим ввода пароля на Secure Desktop. По их собственным словам,
"The "Unlock on Secure Desktop" feature helps protect against key loggers. The "enter master password" dialog appears on another desktop (that we temporarily create ourselves), and Windows messages do not travel across desktops. Key loggers are thus precluded from spying on the (keyboard) messages."

Очень интересно. Lastpass стал таким тяжелым и медленным.
Но было бы здорово оставить опцию сохранения ключа восстановления мастер пароля не только в локально/облако, но и на сменный носитель.
Звучит разумно!..
Мы подумаем, как можно сделать запасной ключ, но вместо облака дать пользователю возможность самостоятельно хранить его где-то.
Здорово. Ждем.
Но пока, конечно, существование таких утилит беспокоит:
ChromePass is a small password recovery tool for Windows that allows you to view the user names and passwords stored by Google Chrome Web browser. For each password entry, the following information is displayed: Origin URL, Action URL, User Name Field, Password Field, User Name, Password, and Created Time. It allows you to get the passwords from your current running system, or from a user profile stored on external drive.
You can select one or more items and then save them into text/html/xml file or copy them to the clipboard

www.nirsoft.net/utils/chromepass.html
С мастер-паролем такие утилиты не справятся.

Т.е., чтобы пользоваться такой системой постановки паролей на моих любимых сайтах, мне надо каждый раз вводить мастер-пароль? Если так, то через два-три сайта я такую заботу отключу нафиг.

Мы же не садисты :) Там можно выбрать, когда нужно спрашивать мастер-пароль: по времени, после блокировки компьютера, после перезапуска браузера.

А будет возможность вводить пароль каждый раз? Какая разница — вводить каждый раз уникальный пароль на сайт или вводить мастер-пароль и забирать реальный пароль для сайта?
А то сейчас страшно сохранять в браузере пароли, учитывая, что уже один раз забрали пароль и это мне многого стоило :)

Это очень жёсткий вариант. Посмотрим на то, сколько таких просьб к нам поступит.
В lastpass есть крутая штука — конкретные аккаунты требуют мастер пароля.
Условно, банки под паролем — остальное не жалко.
НЛО прилетело и опубликовало эту надпись здесь
Мы специально рассказываем о том, как устроено наше шифрование, чтобы ни у кого не осталось сомнений, что сохранённые пароли не будут доступны никому постороннему, даже Яндексу и мы очень стараемся, чтобы всё было надёжно и безопасно.

Поэтому да, менеджер паролей от Яндекса — это отличная идея!
Да ладно, так уж и даже Яндексу недоступны? )
Этот случайный ключ отправляется на хранение в облако Яндекс.Паспорта. А зашифрованный дубликат остается храниться в локальном профиле Браузера.

У вас же имеется доступ в локальный каталог, что греха таить? Я не ругаю и ничего против не имею, но сам факт. Кто захочет не верить, основания найдутся :)
Там немного сумбурная формулировка в посте получилась, на самом деле
1. Делается копия закрытого ключа
2. На эту копию ставится случайный 256-битный пароль
3. Этот пароль отправляется в облако Яндекса, а ключ, защищённый паролем никогда не отправляется в таком виде в облако (чтобы ключ и пароль от него не оказались в одном месте)
4. А при синхронизации этот «запароленный ключ» ещё раз шифруется при помощи мастер-пароля, чтобы таким образом «доставить» его на другие устройства, где он может потребоваться для сброса мастер-пароля.

Понятно, что доверие к ПО это очень субъективная вещь, но у нас есть программа вознаграждений за баги и если вдруг кто-то обнаружит, что есть уязвимость и мы как-то небезопасно обрабатываем пароли, то мы это исправим и заплатим исследователю за помощь в обнаружении уязвимости.

Ну, чтобы убедить параноиков простого объяснения вряд ли достаточно. Вам нужно показать код, провести его публичный аудит, доказать (с помощью deterministic compilation) что этот код собирается именно в тот бинарник, который присутствует в браузере, показать что кроме этого кода браузер более ничем не пользуется и не вытаскивает пароли в облако после разблокировки. Вот тогда да, тогда можно будет сказать, что ни у кого не осталось сомнений :)

Параноики не поверят нам даже при таком сценарии и будут пользоваться аппаратными хранилищами паролей, использовать пароли, которые они придумывают по известному одним им алгоритму в голове или собирать Keepass из исходников, проверяя, что там внутри :)
Ну вот неправда, не нужно этих ложных дилемм и деления всех на разгильдяев либо сумасшедших. Я себя считаю довольно-таки озабоченным безопасностью человеком, да и всякие криптокошельки и интернет-банки, где можно потерять не только доступ к фоточками, но и немало денег, стимулируют выработку полезных привычек. Тем не менее, мне было бы гораздо спокойней пользоваться программой, если бы я знал, что её код может посмотреть ещё кто-то, кроме сотрудников Яндекса.
Слова и обещания это никак не могут доказать, открытый код — может.
Как ни странно, но только 1% пользователей браузера используют специализированные расширения для хранения паролей

Сколько уязвимостей ежемесячно закрывается в Chromium? Доверие гиков, конечно, не удастся таким образом завоевать. Хотя если их всего 1% или даже того меньше, то и не так страшно.

Чтобы давить на массовость, не хватает дополнительных полей для хранения. Если уж пользователю переходить полностью на ваш менеджер, то иногда требуется хранить еще какие-нибудь сведения (пин-код карты, пин от приложения на телефоне или что-то еще). Еще было бы неплохо показывать качество выбранного пароля, чтобы пользователь понимал, что qwertyhello123 совсем некруто, как говорит, например, KeePass :)

Почему не Argon2 или OSCrypt? На мобильных устройствах отсутствует AES-NI, сейчас же есть модный и быстрый ChaCha20-Poly1305?
Дополнительные поля и типы записей будут, это востребованная функция.
По поводу визуализации качества паролей мы подумаем, спасибо.
По поводу криптографии: мы постарались использовать надёжные и многократно проверенные алгоритмы, которые уже есть в boringssl. Однако, как уже было написано в посте, мы не привязаны к определённым алгоритмам шифрования или хеширования и можем без проблем сделать апгрейд до более новых методов при необходимости.

Модный или новый алгоритм — это не всегда хорошо, мы же не на конкурс красоты пришли :)
Chromium большой, и уязвимости там обычно не в паролях ищут. Со своей стороны мы поддерживаем программу «Охота за ошибками», где тоже выплачиваем вознаграждения. В остальном продолжаем участвовать в проекте Chromium. Проще говоря, комбинируем сильные и слабые стороны.

Насколько вы сами видите актуальность своего решения на таких системах, как macOS, где уже есть свой keychain? Без необходимости запоминать master password? Конечно, необходимость ввода не столь остра, так как браузер не часто перезапускается, но тем не менее.


Или основная аудитория Window?

В зависимости от настройки, keychain может требовать пароль при каждом обращении.
А актуальность очевидная — синхронизация. По той же причине на macOS до сих пор существует 1Password и другие менеджеры паролей, несмотря на то, что keychain можно синхронизировать через iCloud и она позволяет генерировать неплохие пароли при потребности.
Действительно, в Mac OS Keychain защищён довольно неплохо, но есть ещё синхронизация паролей. В случае синхронизации, отправлять незашифрованные данные в облако это не очень хорошая идея. Как раз для решения этой проблемы отлично подходит мастер-пароль.

Разумеется, в случае, когда мастер-пароля нет, мы тоже шифруем отправляемые данные, но ключ шифрования тоже хранится в облаке, поэтому мастер-пароль намного лучше.

P.S. В случае, если вы на Mac OS заведёте мастер-пароль и снимете чекбокс «Запрашивать мастер-пароль для доступа к паролям», то он будет запомнен в Keychain, а в синхронизацию пароли будут отправляться надёжно зашифрованными и на других устройствах без ввода мастер-пароля они будут недоступны.
Как я понял, основная задумка в том, что если произойдет компрометация локального хранилища, то пароли вытащить не получится. Тут два момента:
Если нет мастер-пароля, то доступ, всё-таки, будет?
Если есть мастер-пароль и выбрана опция наличия запасного ключа, то что помешает запросить пароль от этой запасной копии из Яндекс.Паспорта?
Если нет мастер-пароля, то ключ хранится где-то в системе. Поэтому с мастер-паролем, который нигде не хранится, сильно надёжнее.

Чтобы запросить пароль у Паспорта, нужен ещё пароль от Яндекса.
Если нет мастер-пароля, то доступ, всё-таки, будет?

Без мастер-пароля физически получится только прочесть логины и адреса сайтов.
Однако, если Keychain позволит получить его, тогда да, доступ к паролям будет, поэтому выключение настройки про запрос пароля это не самая лучшая идея, если у посторонних может быть физический доступ к компьютеру. Мы предусмотрели возможность отключения запроса мастер-пароля на случай, если пользователь захочет, чтобы все данные в облаке были надёжно зашифрованы, а за безопасность устройства и паролей на нём он хочет отвечать сам.

Если есть мастер-пароль и выбрана опция наличия запасного ключа, то что помешает запросить пароль от этой запасной копии из Яндекс.Паспорта?

В общем случае — незнание пароля от Яндекса, но «угнав» учётную запись от Яндекса, злоумышленник скорее всего и так сможет через почту сменить/украсть много разных паролей от сайтов, где используется этот ящик.

Однако, если включена 2-факторная авторизация, вероятность такого сценария крайне мала.
Не вижу, чем принципиально отличается предложенная схема хранения паролей от хранения их в облаке (том же Яндекс.Паспорте)? С полностью обратной логикой хранения.
В профиле достаточно хранить только информацию, для расшифровки «дубликата» приватного ключа, который хранится в облаке. Т.е. расшифровать всё то, что храниться в облаке, можно либо с помощью мастер-пароля, который вводит пользователь и «который нигде не хранится», либо с помощью неких данных в профиле браузера, которые могут использоваться вместо мастер-пароля.

Если пользователь откажется от «дубликата», то в с облаке будут просто зашифрованные данные, а в профиле — ничего.
Разумеется, так можно, но тогда пароли будут доступны только при наличии интернета и связи с Яндексом. Браузер могут использовать в условиях, когда Яндекс недоступен или публичного интернета нет, а есть только интранет.

Выворачивание логики хранения наизнанку не усиливает безопасность, но уменьшает удобство.
Выворачивание логики хранения наизнанку не усиливает безопасность, но уменьшает удобство.

Усиливает, причем катастрофически. Исключаются векторы атаки, направленные на пользовательские устройства (коих множество), так как на них ничего нет (кроме «дубликата» мастер-пароля, но это больше вопрос проверки тех, кто приходит с дубликатом). Да и сами дубликат можно регулярно перевыпускать без участия пользователя.

а есть только интранет.

Ничто не мешает дать пользователю опцию локального хранения всего этого зашифрованного добра (кроме функций работы с дубликатом), на случай, если нужны функции хранения паролей браузера в интранет-среде. В интранет-среде ни о какой синхронизации речи не идёт, поэтому для этой опции можно использовать отличную от обачного хранения реализацию.
Подскажите пожалуйста, планируется ли интеграция с токенами (такими как rutoken ecp, yubikey и т.п.)? Мне было бы удобно сгенерить неизвлекаемый аппаратный секретный ключ и использовать его для расшифровки записей о паролях. И запоминать / сохранять его куда-то не нужно. Все операции шифрования/расшифровки на токене.
Идей много. Точные планы зависят от количества тех или иных запросов и результатов тестирования. Подумаем, спасибо.
Пока конкретных планов нет, но мы посмотрим, что можно сделать, чтобы унести защиту на аппаратный уровень.

В Chrome встроена поддержка стандарта U2F. Не знаю, правда, является ли этот код частью Chromium.
2FA для менеджера паролей оставит "специально заточенные трояны" без работы.

Было бы неплохо, если бы были подсказки о том, что текущий пароль слабый, ну и в целом — проблемы с паролями в менеджере чтобы подсвечивались(дублирующий пароль, слабый пароль и т.п.)
Да, уже писали выше об этом. Мы подумаем.
Пожалуйста, расскажите как вы ключи для RSA генерируете (там просто почти в каждом шаге алгоритма накосяцить можно), и ещё, какой они длинны?
Мы используем RSA_OAEP_2048_SHA256
Генерируем и экспортируем ключи через стандартную библиотеку Chromium boringssl через класс RSAPrivateKey. В криптографии велосипеды изобретать плохо, правильно брать что-то стабильное и давно работающее, что мы и сделали.
Спасибо. Еще у меня такой вопрос: зачем вам AES-256, когда AES-128 хватило бы с головой?
Особенно, если учесть что у вас RSA-2048 (примерно 128 бит «криптостойкости») и SHA-256 (тоже 128 бит защиты т.к. парадокс дней рождения). Плюс на AES-256 больше атак чем на AES-128 (key schedule). Ну, и, AES-128 был бы бустрее, ибо 10 раундов вместо 14ти.
Выходит вам явно 128-битная версия больше подошла бы или у вас на этот счёт какие-то другие соображения?
Могу ошибаться, но есть такое мнение, что в случае, если внезапно придумают успешную атаку на AES-128, возможно, в 2 раза больший ключ будет чуть сложнее взломать, а может и нет, а вот более медленная расшифровка AES 256 нам скорее на руку, т.к. замедляет перебор, но не настолько, чтобы это было визуально заметно.

Ну, в общем, это скорее из области психологии: «256 бит больше 128, а значит надёжнее, пока обратное не доказано».

Про 2048 бит — да, это где-то 112 бит сложности, поэтому действительно ключ 128 бит по общей сложности подошёл бы лучше, да и не 2048, а 3072 правильнее было бы тогда. Кстати, при определённых обстоятельствах, атака на AES-256 как раз снижает стойкость именно до 112 бит, что отлично согласуется с текущей стойкостью 2048 RSA.

А вообще, мы заложили в архитектуру возможность почти безболезненно менять алгоритмы шифрования/хеширования, поэтому ни к чему не привязаны и планируем регулярно повышать сложность и применять более современные алгоритмы при необходимости.

Если уже быть совсем честным, то самое слабое звено в системе — мастер пароль. Если пользователь выбирает недостаточно сложный/длинный мастер-пароль, никакие алгоритмы и большие ключи не помогут.
Могу ошибаться, но есть такое мнение, что в случае, если внезапно придумают успешную атаку на AES-128, возможно, в 2 раза больший ключ будет чуть сложнее взломать, а может и нет, а вот более медленная расшифровка AES 256 нам скорее на руку, т.к. замедляет перебор, но не настолько, чтобы это было визуально заметно.

С точки зрения теории, на AES успешная атака уже есть (biclique), но она всего на пару бит снижает защиту (и требует уйму ресурсов во всех вариантах: 128, 192 и 256 бит).
А вот если вдруг появится квантовый компьютер, тогда да, можно будет поделить длинну ключа на два. Размер хеша тоже можно будет пополам разделить (в смысле безопасности). Но в этом случае RSA вообще нужно будет выкинуть.

По поводу «256 больше 128»: согласен, да, но нет :) не в случае с AES. Дело в том что на AES-256 есть атака, которая снижает уровень безопасности с 256и до ~100 бит, а вот на AES-128 эквивалента этой атаки нет (точнее есть, но не на полные 10 раундов). Хотя зумечу, это всё равно на практике провернуть будет слишком сложно (сегодня). Проще действительно на слабый мастер пароль нацелить усилия.
В общем, идея с размерами ключа более или менее ясна, хотя раз 256>128, то можно взять SHA512 и RSA «более толстый». Я, собственно, только по тому и поинтересовался, что на мой взгляд размеры ключей друг другу не соответствуют.

То что есть возможность заменить алгоритмы и всё это продумано с самого начала и заложено в идею — это очень даже правильно.
«версия для Linux» — версия для Debian-based Linux, уточняйте же.
Ну да, Ubuntu == Linux. Но Linux != Ubuntu.
Если быть точнее, то DEB и RPM пакеты.
авторы нового менеджера пароля пишут что пытаются защитится от злоумышленника получившего доступ к компьютеру жертвы…
но что тогда мешает злоумышленнику с доступом заинсталировать key-logger и получить мастер пароль в момент ввода в будущем? стоимость взлома в обоих случая примерно одинаковая, низкая.

в этом плане нет никакой разницы есть ли на паролях мастер пароль или нет… доступ к компьютеру позволяет обойти как первый так и второй.

я думаю сейчас самой сильной защитой от доступа к ключам является двух-факторная аутентификация, и у Гугла уже есть решение на этой базе — Smart Lock. и судя по тому что я читал эту штука заинтегрирована в Chrome. т.е. для решения задачи безопасного хранения паролей в Chrome достаточно включить двух-факторную аутентификацию, в одно-факторной версии безопасности же никогда не будет в принципе.
Мешает наша другая фича, которая тоже тестируется в бете и не дает трогать процессы браузера и использовать перехват клавиатуры.

Не очень понимаю, как вам поможет тут Smart Lock. Это про разблокировку мобильного устройства, а не про защиту паролей. В части паролей это как раз то самое решение из Chromium, о котором мы и писали. Если не ошибаюсь, там пароли хранятся на сервере в явном виде (их же можно посмотреть на сайте?). И, кажется, хранение ключа вместе с паролями на устройстве (любой софт может их забрать). Или я не туда смотрю?
Да возможно это и не совсем то: скорее всего все пароли дублируются на клиенте… Я почему то думал что эта двойная аутентификация используется чтобы шифровать сами пароли. А она скорее всего просто проверяет вход в гугл «домейн» а дальше уже как обычно, безопасность повышается только если конкретный сайт поддерживает аутентификацию напрямую через гугл-апи (многие это начинают кстати делать).

Вот интересно, можно ли сделать шифрование паролей с двух-факторным аутентификатором/динамическим ключом? Т.е. пользователь пытается получить пароль от сайта, вводит мастер пароль + на телефон приходит вопрос ввести пин, далее если пин верный телефон возвращает какой-то временный ключ открыть базу с паролями… Что-то типа кодового калькулятора как в интернет банках.

Теоретически всё возможно, я думаю. Но защита и сейчас уже не однофакторная. Одного мастер-пароля недостаточно. Нужно ещё хранилище паролей и ключи к нему.
Это та самая фича, которая сейчас в Хроме и которая не даст мне делать shift-break силами Punto Switcher?
В Хроме её точно нет.

Для параноиков можно было бы сделать так:


  1. Часть encKey хранится на телефоне
  2. Генерируется одноразовая пара ключей, и на телефон вместе с запросом приватного ключа отправляется открытая часть (с подписанным запросом).
  3. Телефон при подтверждении отправляет ее в зашифрованном виде, и браузер ее расшифровывает. Поскольку ключ одноразовый, то через что бы оно ни пересылалось, повторно это использовать будет нельзя.

Но тогда разблокировка будет происходить только при условии связи компьютера с телефоном.


На самом деле, само хранение можно делегировать и Яндексу, что все равно добавит второй фактор, и требует только нахождение онлайн при вводе мастер-пароля.

для решения задачи безопасного хранения паролей в Chrome достаточно включить двух-факторную аутентификацию

Прошу подробностей как это работает? И как настроить?
Это была дикая теория, не уверен что включение этой штуки повлияет на то как хранятся сами пароли на клиенте. :)
Сам пользуюсь KeePass но понимаю что если кто-то поставит на мой компьютер логгер/троян вся мои пароли перестанут быть секретом… Надо бы найти (сделать?) 2-х факторный хранитель паролей с динамическим ключом — такие алгоритмы любят в банках использовать.
А разве OtpKeyProv для KeePass не для этого?
Обожаю некоторые сервисы, приложения и др. от Яндекса. Например Яндекс.Музыка очень хороша (единственное пришлось отказаться по причине недоступности в Украине, всё таки не очень удобно исп. прокси или впн, жду встроенного прокси в приложение:)), приятно видеть что Вы развиваетесь и не стоите на месте. Хотелось бы протестировать новый менеджер, но я буду ждать импорт из LastPass, а то не очень удобно вручную добавить 200+ сайтов:) Жду и надеюсь:)
пользуюсь Roboform на всех устройствах, более 10 лет, удобнее и надёжнее пока не встречал.

У меня два вопроса, один по паролям, второй нет…
Первый: Почему шифрование не по ГОСТ, трудности с реализацией или пока сделали как удобнее? Планируется ли он?
Второй… В нашем проекте внезапно обнаружилось при КАЖДОМ обновлении браузера происходят чудеса с шифрованием соединения по ГОСТ, в лучшем случае просто пропадает галка в настройках, в худшем ведёт себя как чистый хромиум не понимая что от него хотят. Спасает только чистая установка, это нормальная ситуация?)

Не очень понятно, зачем отказываться про проверенных и активно развиваемых сообществом библиотек и алгоритмов. Мы – часть этого сообщества.

Поддержка сайтов с шифрованием по ГОСТу (с помощью стороннего плагина) ещё в процессе отладки. По готовности расскажем отдельно (в нашем блоге браузера). Пожалуйста, о любых странностях пишите нам сразу через «Сообщить о проблеме» в меню браузера.

Корпоративный сектор, точнее государственный, тоже часть сообщества )) Однако рамки у нас очень узкие и клещи близко к уязвимым местам.
Про шифрование по ГОСТу ждём статьи, а вопрос продублирую в трекер, в рабочее время не успел ))

НЛО прилетело и опубликовало эту надпись здесь

Нет. Его одного мало. И сброс подключать тоже не обязательно.


Никто не говорит, что криптография тут принципиально новая. Но хорошая защита для браузеров – редкость.

Никакого обмана. Включите 2-факторную авторизацию и возможность сброса перестанет зависеть от пароля от Яндекса. А подобрать 256-битный пароль для запасного ключа ни у кого всё равно не получится.
Спасибо за статью, интересно почитать.
Напоминает схему с LUKS, только у вас есть дополнительный слой с RSA ключом.
Он добавлен для возможности подписи содержимого и как дополнительный шаг для замедления перебора всей схемы, или есть еще какие-то причины?
А ещё дополнительный слой с RSA позволяет менять мастер-пароль без расшифровки хранилища, т.е. без замены ключа шифрования.
Не, шифруя ключ шифрования напрямую мастер паролем без прослойки rsa тоже можно менять мастер пароль или иметь множество разных мастер паролей, как это сделано в LUKS контейнере

А можно вместе или вместо повседневного мастер-пароля что-нибудь другое, например google authentificator?

Так или иначе есть огромное множество нативных программ, в которых требуется аутентификация. Браузеры безусловно забирают львиную долю авторизаций на среднестатистическом компьютере, однако даже в самом браузере сначала нужно залогиниться :) На мой взгляд, нативное приложение с расширением выглядело бы более функционально.

Что касается использования пароля в ключе для декрипта — я для себя не увидел убедительной аргументации против этого. Всегда можно взять часть пароля, скомбинировать его с уникальным Hardware ID, добавить различных смещений и прочих ништяков, и в итоге получить смесь которая вполне будет сравнима со случайной генерацией. Подобные же методы позволяют применить многократную криптографию, например: сначала дешифруем файл по одной связке, получаем лист с данными закриптованными уже совсем другой связкой, при запросе декриптим и выдаем. Это должно не только значительно усложнить получение доступов злоумышленникам, но и дополнительно обезопасит данные привязав их к машине пользователя, т.е. даже если пароль будет скомпрометирован здесь будет дополнительная ступень защиты.
Примерно подобный метод защиты я применил в менеджере паролей для личного пользования: github.com/Hackness/KeepYourPassword
А вопрос с переносимостью данных для пользователя можно будет решить например отдельной системой переноса по одноразовому суперпаролю, rsa или подобным.
P.S. Ну и, конечно, истинный параноик будет хранить важные данные только в том, что сам может скомпилировать :)

Вы так заботитесь о простых пользователях, но не хотите переводить общие термины на их язык. Обычный пользователь быстрее поймёт для чего нужен общий пароль чем мастер-пароль. Тем более не все знают перевод слова мастер.

Слово «мастер» уже давно не надо переводить :) Любой термина без контекста ничего не значит. Турбо. Протект. Режим чтения. Описание, обучение и практика решают эту задачу.
Можно сделать термин «мастер-пароль» tooltip'ом, при наведении на который будет всплывающая подсказка про то, что это такое. Коллега здесь прав, те 90% людей, на которые вы ориентируетесь, могут не понять, что же это за мастер-пароль.
У нас там целое обучение будет :)
а 1Password к вашему браузера как-то можно прикрутить?
Как именно? На iOS он поддерживается в Браузере (в меню «Поделиться» найти можно).
У меня windows + 1Password 4.6.2.626
но я не нашел 1Password расширение для яндекс браузера
через меню в поиске ввел 1Password — находит что-то другое
yadi.sk/i/grc6lAgm3QaEV3
вероятно поиск расширений отрезает первую цифру и ищет слово password :-(
кстати поиск ведет зачем-то на оперу addons.opera.com/ru/search/?query=1password
а опера ведь давно того…

Так мы и Chrome Web Store прекрасно поддерживаем. Оттуда можно установить.
Как ни странно, но только 1% пользователей браузера используют специализированные расширения для хранения паролей (LastPass, KeePass, 1Password, ...)
Напомним, что те же 1Password, KeePass и LastPass даже в сумме используют не более процента пользователей
Это вы исходя из количества установок расширений для браузера такой вывод делаете? Или Яндекс.Браузер отправляет в Яндекс информацию о том, какими программами кроме их браузера пользуется пользователь?
Программы на компьютере искать не нужно. Речь про расширения. Мы знаем, какие расширения работают в Яндекс.Браузере. ID расширений и количество установленных копий.
можно узнать ID (url) расширения 1Password?
Выше ответил. Из Chrome Web Store можно установить хоть обычное 1Password, хоть новое 1Password X.
Спасибо. круто! работает!
а почему поиск расширений из яндекс.браузера ведет на левый сайт от opera.com?
Но это не левый сайт. Мы официально поддерживаем Opera Addons и их формат расширений NEX. Даже доработки с их стороны были.
хм ок, ну тогда можно при поиске расширений из я.браузер искать сразу в 2-х местах. в opera и Chrome Web Store?
Только своими силами.
Мы знаем, какие расширения работают в Яндекс.Браузере.
Тогда на основании чего вы делаете вывод:
Напомним, что те же 1Password, KeePass и LastPass даже в сумме используют не более процента пользователей
Цифр у меня, конечно, нет, но я и люди из моего окружения используем KeePass(X) без установки каких-то расширений. Экстраполируя получается, что далеко не один 1%, а гораздо больше?
Речь только про браузерные расширения. Самым популярным решением является LastPass. Сильно сомневаюсь, что отдельный KeePass сопоставим с ним. Подобные инструменты используют только очень опытные пользователи, а их очень мало.
Функционал, безусловно полезный, особенно для обычных пользователей.
Однако, у популярных решений есть одно преимущество:
они подходят для хранения всех видов паролей, а не только паролей к сайту.
Вопрос, как хранить пароль к какой-нибудь программе, запускаемой локально на компе? Как вводить пароль от приложений на телефоне? У того же KeePass в версии для Android есть своя клавиатура. Да, это далеко не самый удобный вариант, но открывать браузер (а это довольно тяжёлое приложение), в нём открывать менеджер паролей и ctrl+c — ctrl+v из него в приложение, этот вариант будет ещё хуже.
Напрашивается решение «отпочковать» менеджер паролей в отдельную программу, у которой будет тесная интеграция с яндекс.браузером. Или интегрировать его в яндекс.клавиатуру, на крайняк. Планируется как-то решать этот вопрос в будущем?
А ещё вопрос, на который я не нашёл ответа: что делать, если от одного и того же сайта надо хранить несколько паролей?
Вопрос, как хранить пароль к какой-нибудь программе, запускаемой локально на компе?


Да, есть идея добавить и другие типы данных. Посмотрим на спрос.

Как вводить пароль от приложений на телефоне?


При желании это можно поддержать. Чтобы Браузер вызывался из других приложений для заполнения форм. Как сейчас работают сторонние решения. Опять же точные планы потом станут понятны.

А ещё вопрос, на который я не нашёл ответа: что делать, если от одного и того же сайта надо хранить несколько паролей?


Никаких проблем с разными учётками для одного сайта у нас нет :)
Отличные новости. Большое спасибо. Я уже, наверное, замучил поддержку Яндекса своими жалобами на убогость парольного менеджера.

Вот, что я хотел бы видеть в парольном менеджере своего браузера.

  1. Возможность сохранение текстового комментария
  2. Возможность завести запись вручную. Это вот для меня самая киллер-фича
  3. Возможность завести новую запись, скопировав данные из существующей записи
  4. Время создания записи
  5. Время последнего изменения пароля
  6. Время последнего использования пароля
  7. Счетчик количества случаев использования пароля
  8. Экспорт/импорт в простом текстовом виде
  9. Массовое редактирование


Решение о том, когда можно и нужно ли подставлять пароль, должен принимать пользователь, а не браузер. Сейчас у меня дома есть несколько IoT девайсов с веб-управлением, защищенных самоподписанными сертификатами. Очень раздражает, что Яндекс.Браузер не дает подставлять туда сохраненные пароли. Зато, если перейти по http — то пожалуйста. Так все соседи скоро будут знать пароль от моего принтера, роутера и телевизора.

И что еще важно, браузер должен хранить не только пароли, но и сертификаты. Хранилище сертификатов Windows — это проходной двор, куда кладут всякий мусор все, кому не лень. Хранить там доверенные сертификаты или личные сертификаты с приватными ключами крайне опасно. А значит, нужно их держать в профиле браузера, как это делает Firefox. С сертификатами чуть посложнее. Нужно иметь возможность делать с сертификатами все то же самое, что и с паролями, и, сверх того, указывать, на каких доменах их можно использовать.

Пошел устанавливать бету.
И еще нужна возможность вручную заблокировать/разблокировать пароли. Простой кнопочкой в тулбаре.
Не могли бы вы еще за скооперироваться с вашими коллегами, занимающимися лингвистикой и создать (и лучше — отдельным приложением) генератор длинных, случайных, но грамматически правильных русскоязычных парольных фраз? Грамматическая правильность, конечно, снижает энтропию, но это лечится удлинением фразы. Такой генератор, похоже, является единственным способ добиться запоминаемости и надежности этого самого мастер-пароля.
Русскоязычные пароли? В смысле, кириллица? С ними же будут проблемы на сайтах.

Кстати, а мастер-пароль русскоязычный можно использовать?

Сходил, проверил. Сейчас – нет.
Странно. У меня получилось.
На сайта даже просто длинные парольные фразы часто проблемы создают. Так что не для сайтов, а на сам менеджер паролей. Впрочем, можно делать транслитерацию латиницей, но у нее столько вариантов, что слова для генерации фраз нужно будут долго и старательно подбирать. Чтобы пользователи не спотыкались каждый раз, вспоминая, какой именно вариант при задании пароля был использован.
Насколько на самом деле случаен «случайный» ключ, которым вы шифруете основное хранилище? Какие-то данные из активности пользователя подмешиваются при генерации? В противном случае все упрется в уязвимости генератора псевднослучайных чисел системы. Как быть уверенным пользователю, что он реально надежен, ведь его выбирают за меня и даже не показывают?
Мы используем системный генератор случайных чисел, но мысль про подмешивание пользовательских данных мне понятна и нравится. Посмотрим, может быть добавим.

Что касается уверенности в ключе: если вы настроены серьёзно и переживаете за наши алгоритмы, можно открыть через SQLite базу Ya Login Data и
создать свои ключи руками
а) сгенерировать случайный 256 битный ключ
б) сгенерировать пару ключей RSA
в) посолить и похешировать желаемый мастер-пароль
г) поставить хеш в качестве passphrase на ключ
д) записать всё это в базу

Достаточно было бы подмешивать движения мыши в момент первоначальной настройки, а ключ визуализировать, например, в виде цветной матрицы. Сразу будет видно, что от малейшего движения мыши картинка полностью меняется. Но это, наверное, слишком по-гиковски для аудитории браузера :)
Слава великому Яндексу! Года два назад писал им об этом.
Отсутствие мастер-пароля (как у Огнелиса), это единственное, что мешало мне начать пользоваться Яндекс.Браузером.
За что вы убили женщину?


Разгадка.
Далее ключ encKey зашифровывается с помощью асимметричного алгоритма RSA-OAEP. Для этого Браузер создает пару ключей: открытый pubKey и закрытый privKey. Ключ encKey защищается с помощью открытого ключа, а расшифровать его можно только с помощью закрытого.

Открытый ключ pubKey защищать не нужно, потому что он не подходит для расшифровки, а вот с закрытым privKey история другая. Чтобы защитить его от кражи, доступ к нему блокируется согласно стандарту PKCS#8 с помощью парольной фразы unlockKey, которая в свою очередь является результатом хэширования мастер-пароля с помощью функции PBKDF2-HMAC-SHA256 (100 тысяч повторов; с добавлением соли и id хранилища). Если мастер-пароль случайно совпадает с уже украденным паролем от какого-либо сайта, добавление соли скроет этот факт и усложнит взлом. А благодаря многократному хэшированию достаточно длинного мастер-пароля трудоемкость взлома unlockKey сопоставима со взломом ключа encKey.
менеджер теперь не надо искать в настройках: кнопка доступна в главном меню…
и >> Сегодня новый менеджер паролей можно попробовать в бета-версии Яндекс.Браузера для Windows и macOS…
установил версию 17.11.1.775 beta со стр. https://browser.yandex.ru/beta/
НО! Так и не увидел менеджера "в главном меню"
печалька..

А перезапуск не помогает? Если нет, то странно. Напишите нам, пожалуйста, через «Сообщить о проблеме» в меню.

Помог перезапуск винды… Как я понимаю браузеру потребовалось чуть больше прав )))
ирония в том что первое сообщение при старте:
"Приложение punto.exe пыталось сделать снимок вашего экрана..."
Я конечно понимаю что настройки по умолчанию многих программ несовершенны,
и моя паранойя весьма умеренна… но улыбнуло )))


Обязательно протестирую ваш менеджер паролей, стало даже интересно !

через «Сообщить о проблеме» в меню
думаю это не проблема )) просто для информации остальным, ну и вам — чтобы учесть в документации
например фразой типа "возможно потребуется перезагрузить ОС ..." )))

В любом случае спасибо за хороший продукт !

Далее ключ encKey зашифровывается с помощью асимметричного алгоритма RSA-OAEP.

Почему здесь выбрано асимметричное шифрование? Где в схеме существенным образом используется публичный ключ?


Но математическая зависимость ключа от мастер-пароля всё же упрощает взлом, скорость которого в этом случае зависит лишь от надежности хэширования… Поэтому в нашем случае ключ encKey не является производным от мастер-пароля и генерируется случайно.

Но является производным от мастер-пароля (via PBKDF2) самый первый ключ unlockKey. Почему к нему не применимы рассуждения про ASIC-фермы?


Где можно почитать исходники?

Публичный ключ пока больше не используется, но мы планируем его использовать для поддержки множественных ключей шифрования. Больше рассказать не могу, к сожалению.

Исходники браузера мы не публикуем.
Планируется ли что-то, что позволит нескольким людям получать доступ к хранилищу паролей? Например, частая ситуация, когда небольшая команда работает над проектом и хотела бы передавать друг другу пароли и ключи от инфраструктуры. Есть ли какие-то существующие решения, позволяющие такое?
Если дёшево, то может общий аккаунт для синхронизации сделать? Вообще, это идея, которую можно развивать в рамках корпоративной версии нашего браузера.
Очень интересная статья, спасибо. Все комментарии осилить не смог… пока… :)

Однако, весь смысл Вашей идеи в принципе «разделяй и властвуй»: один ключ шифрования вы оставляете себе в облаке, другой (зашифрованную копию личного ключа RSA) — в браузере. Слой RSA нужен лишь для замедления перебора, хотя с точки зрения криптографии лучше подходит симметричная криптосистема. Я надеюсь, что в Вашем решении открытый ключ RSA pubKey «благополучно» уничтожается и забывается, ведь в противном случае, злоумышленнику предоставляется возможность отдельно решать задачу поиска личного ключа RSA.

Кто-то тут писал, что криптография вряд ли в скором времени предложит что-то принципиально новое. Не разделяю этот пессимизм. Мне верится, что совсем скоро пользователям (в том числе браузеров) и вовсе не понадобятся никакие менеджеры паролей.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
А что с поддержкой мастера для браузера в MacOS?
Для macOS бета тоже есть.
о как. Пойду искать :)
скачал, но менеджера паролей там нема :(
Попробуйте перезапустить. Он там включается конфигом с сервера.
НЛО прилетело и опубликовало эту надпись здесь
Как раз столкнулся с такой же проблемой. Мало того, что нельзя экспортировать, так еще и в виде отобразить в виде списка, как это делается в Chrome, не получится.

Последняя капля…
Если мы не предусмотрим резервный вариант, то многие пользователи Яндекс.Браузера либо откажутся от использования мастер-пароля, либо «потеряют» однажды все свои пароли, а виноват в этом будет Браузер (вы удивитесь, но именно Яндекс часто оказывается крайним в ситуации, когда человек забыл пароль от аккаунта).

Если ни в этом, то в том, что человек не может забрать свои пароли, к сожалению, — точно. Меня никто не спрашивал, хочу ли я положить свои данные в ящик, из которых достать их нормальным способом уже невозможно.
В первой бета-версии мы успели далеко не всё. В будущем мы поддержим экспорт и импорт паролей для совместимости с популярными сторонними решениями.

Жаль, что будущее — понятие слишком растяжимое…
Прошло 3 года.
1. Экспорта паролей нет.
2. Есть блокировка всех других браузеров на импорт настроек и паролей.
3. Браузер по умолчанию без запроса импортирует все данные из chrome.
4. С каждым обновлением включает все новые и новые виды уведомлений. Отказался от Погоды, так на тебе Погода на выходных или Веторок или Дождик.

Друзья, так вы скоро обгоните Амиго, НиХром, Уран и прочую чешую.
1. Это правда.
2. Нет никакой блокировки. Просто другие браузеры не умеют импортировать надежно защищенные данные. Импорт — это всегда решение на чужой стороне.
3. Браузер же спрашивает об этом. Если отказаться, то никакие данные не перенесутся. Это не какая-то новая фича. Это наш очень древний механизм импорта.
4. Есть страница настроек для выбора типов уведомлений. Возможно, она не совсем удобная из-за быстрого роста возможностей. Мы думаем, как сделать её более наглядной.

Уверен, у Амиго, Нихрома и Урана (как и у любого другого Chromium-based проекта) нет такого менеджера паролей со стойкой криптографией.

У Яндекс.браузера вообще нет менеджера паролей. То поделие, которое в яндекс.браузер встроено, не работает. Приходится пароли руками копировать из сторонних хранилищ.

Конечно же, он есть.

Можете привести пример сайта, где пароль не подставляется или не сохраняется? Вебмастеры могут усложнить процесс определения полей, отступив от веб-стандартов.
А вот генератор паролей можете сделать так, чтобы можно было отдельно вызывать? Иногда вот сталкиваешься с такими вот оригинальными сайтами, когда к примеру меняешь пароль, а поле для ввода нового пароля сделано не по стандарту и генератор не показывается, приходится сторонними пользоваться.

Разве есть какой-то стандарт на то, каким должно быть поле ввода нового пароля?

Я подозреваю, что все менеджеры паролей ориентируются на вот такую вот вещь:
<input type=«password» атрибуты>

Вы невнимательно прочитали. Я сказал, что он вообще не работает. Он непригоден для использования. Обратитесь в поддержку, пусть вам покажут список жалоб. Среди них за этот год моих должно быть больше 10.


  1. Не работает на всех сайтах, где нет доверия к сертификатам. У меня таких 60 штук. Я не буду в очередном внутреннем кластере кубернетс устанавливать промышленные сертификаты, чтобы порадовать разработчиков браузера.


  2. Заходишь на страницу там форма Login, Password и remember me. Всплывает менеджер паролей, вводишь мастер-пароль, он автоматически вставляет какие-то значения и сразу выполняет вход. Я даже не вижу, каким пользователем я вхожу, и не могу выбрать remember me. И это у вас считается фичей. Естественно, я вынужден просто не вводить мастер-пароль, а вставлять нужные мне данные из другого внешнего источника. Это на всех сайтах. Поэтому я и говорю, что не работает ваше поделие, не на каком-то конкретном сайте, а в целом.


  3. если что поменялось на сайте, то привет. И автоматически не подставится, и выбрать из списка не дает. Только ручками из страницы настроек копировать. Так я захожу в сбербанк.онлайн.


  4. us.zoom.com учетные данные сохранены — подставить из парольного менеджера нельзя.


  5. синхронизация с мобильным браузером не работает. Сохранил пароль в десктопном браузере — в мобильном его нет. Или есть но не подставляется. Опять ручками искать, копировать и подставлять.



Генератор паролей вызвать нельзя. Толку от него ноль. В режиме инкогнито он как бы есть, но не вызывается. И да, это тоже фича, а не баг, поэтому идите лесом.

А подскажите почту, которую вы указывали в обращениях. Многие пункты странные. Не воспроизводятся сходу.
1. В чем проблема это сделать? Или это хороший повод удерживать пользователей, что бы не уходили? Не противоречит ли это общим принципам этики, ведь даже в фейсбук можно заказать на CD всю свою переписку, фотки и лайки. А в яндекс.браузер похож на рабство.
2. Разработчики остальных браузеров такие рукожопы по вашему мнению, что из одних браузеров:explorer, edge, firefox импортируют, а из яндекс бац и стало вломы разбираться. Может быть это вы со своей стороны сделали все на столько «очевидно», что оно не импорируется?
3. Установщик Яндекс браузер повесил машину i7 6600 с 16ГБ на 4 минуты импортируя из хрома все добро, не спросив пользователя. Не похоже ли, что яндекс.браузер берет на себя слишком много, залезая туда, куда его точно никак не просили залезть? Когда я соглашаюсь установить яндекс.браузер, я соглашаюсь установить яндекс.браузер. Я не даю согласия на то, что бы прошманать мой комп, даже если потом меня спросили что с прошманованным сделать.
4. Мне в вашей поддержке уже ответили, что настройки уведомлений браузера хранятся в cookies, при любом сбросе которых настройки обнуляются. Я делаю вывод, что этот блок написан на отшибись в пользу яндекса, что бы всегда отыметь пользователя очередным бестолковым уведомлением в интересах корпорации бобра.

Какая разница какой у вас менеджер паролей и как он защищает, если вы глубинно не уважаете своих пользователей и их право выбора распоряжаться своими данными. Я никак не могу проверить надежность вашего менеджера, но ваш подход говорит мне о том, что мне и моим данным лучше держаться от вас подальше. Особенно после того, как вы типа включили поддержку сторонних решений по блокировке рекламы, которые почему перестали работать на проектах яндекса.

Похожая песня стала с приложением музыка от яндекса. Приложение само запускается в фоне, качает новый трек и пушит в трей, что бы я резко чего-то там послушал. После скрытия уведомления и выкидывания из ОЗУ приложения, через минуту фокус повторяется.

Такое ощущение, что политика партии в том, что бы резко догнать и перегнать зеленого конкурента по уровню поглощения мозга своей компанией, даже в ущерб здравому смыслу, этики, логики, функционалу и потребности конечного потребителя.
1. Как это обычно бывает на практике, пытаешься сделать всё и сразу, а в результате до чего-то не доходят руки. Постараюсь в ближайшем будущем вернуться с хорошими новостями в этот тред (сохраню его в избранное).
2. Импорт всегда на стороне тех, кто к себе импортирует данные. Ничего специально мы тут не делали для того, чтобы кому-то навредить. Просто архитектура хранения данных у нас радикально отличается от любого Chromium-based браузера. В Хромиуме пароли в системе лежат практически в открытом виде. Любой софт может легко их к себе импортировать. Вы даже не узнаете об этом. У нас не так. Возможно, в этом причина. А может быть локальная распространённость браузера как-то влияет. Честно, не знаю, какие именно у них сложности, к нам не приходили.
3. Мне кажется, это вопрос точки зрения. Знаю людей, у которых такая логика наоборот вызывает восторг, что все данные сразу доступны и не надо копаться. Результат-то по факту один и тот же. Я бы ещё понял критику, если бы данные куда-то бэкапились, но до явного включения синка они же как были на компьютере, так и остаются там. А вот про избыточную нагрузку на систему интересно. Такого в нормальных условиях не должно было быть. Если получится в будущем зарепортить это в поддержку, то будет хорошо.
4. А вот это уточню. По моей информации, не в куках они хранятся. Они у вас сбрасывались при очистки куков или это только в ответе так было написано?

Заодно формат даты в поле <input type="date" сделайте, пожалуйста, не американским.

А это разве не от локали в системе зависит?

Во всех нормальных программах, да.

Просто мы сейчас проверили и ровно такое поведение и увидели. Есть ли номер обращения по этой проблеме?
1. Ответ ТП яндекса:

[Ticket#20110916382392884] [ru] Отчёт об ошибке из браузера
Поддержка Яндекс.Браузера
browser@support.yandex.ru
10 ноя в 19:36
******@yandex.ru
Здравствуйте, Сергей!

Дело в том, что браузере нет отдельной функции для экспорта данных, однако вы можете экспортировать закладки в HTML-файл, а из файла перенести их в любой другой браузер. Для того чтобы сохранить закладки из Яндекс.Браузера в файл, нажмите, пожалуйста, на значок меню (≡) и перейдите в меню «Закладки» → «Диспетчер закладок».

На открывшейся странице справа сверху нажмите три точки → «Экспорт закладок в файл HTML».

Затем вы можете импортировать закладки из этого файла в любой браузер или новый профиль Яндекс.Браузера.

Что же касается паролей, то в настоящее время из соображений безопасности в Яндекс.Браузере нет возможности экспорта паролей. Мы заботимся о сохранности личных данных наших пользователей.

Однако я передала команде браузера ваше письмо в качестве пожелания реализации такой функции в будущем.

Спасибо!
=============
Из соображений безопасности? Так же по соображениям «безопасности» РКН блочили телеграмм, а как только Паше не разрешили делать свою крипту, тут же сняли блокировку, хотя решение суда никто не отменял.

Или я может слишком мнительный и увлекающийся конспирологией, либо менеджер ТП прожжённый пиарщик от бога.

2. Опера и Хром предлагают импорт из Яндекса, но с ним никак не справляются. Я не знаю технических деталей вашего менеджера паролей, возможно он реально гениален. Но почему такие крупные вендоры за 3 года не пофиксили вопрос с импортом паролей из яндекс браузера — загадка? Возможно я поспешно сделал вывод, что блокировка с вашей стороны.

4. Ответ ТП яндекса:
[Ticket#20110919362696190] [ru] Отчёт об ошибке из браузера
Поддержка Яндекса
mainpage@support.yandex.ru
10 ноя в 10:44
******@yandex.ru
Здравствуйте, Сергей!

Если галочки появляются, после того, как вы их убрали, это может означать, что из вашего браузера удаляются файлы cookies. Т.е. cookies не запоминают ваши действия и могут предлагать повторить их снова. Это можно изменить в настройках — проверьте, пожалуйста, включено ли в вашем браузере сохранение cookies. Сделать это можно по инструкции в Справке.

Если вы пользуетесь программами для очистки компьютера (например, CCleaner), то они тоже могут удалять cookies. Рекомендую отключить все расширения в браузере, перезапустить его и проверить ситуацию ещё раз, должно помочь.
===============
Может менеджер не понял сути вопроса, но хранить настройки браузера в куках, которые может чистить пользователь и/или любая другая программа — бред. По-моему настройки браузера должны храниться в неком внутреннем хранилище, типа реестра виндовс, а если это мои предпочтения по уведомлениям от сервисов яндекс, то где-то в настройках профиля аккаунта на яндексе, у вас это называется Паспорт.

Кстати, раз на то пошло, я вообще не понимаю, зачем яндекс браузер ставит 2 иконки в быструю панель windows с разными значками, причем одна из них при наведении выдает Yandex (2), из чего я понимаю, что ярлык создан дважды. Кто-то дважды в инсталлятор впендурил создание ярлыков с разным именем и иконкой, но ссылаются на один файл.

Раньше у вас вместе с браузером ставился «менеджер браузера» и «быстрая кнопка», что по-моему вообще дичь несусветная.
Тут опять же нет расхождения. Сделать простой рубильник с выгрузкой в plain-text можно, но это странное решение на фоне многоступенчатого шифрования. Всегда есть риск, что рубильник дёрнет не человек, а софт. К примеру, когда-то мы добавили достаточно навязчивое предупреждение о том, что в настройках отключен SafeBrowsing. Потому что в большинстве случаев его отключали как раз не сами люди. Можно сказать, что мы обожглись на молоке и теперь дуем на воду. Есть идея, как это можно обойти, но пока не уверен, что пойдём именно по этому пути. Может быть мы и зря так трясёмся над рисками. В общем, подумаем.

Ну что же, тренд сохраняется. С новыми версиями браузера парольный менеджер продолжает пробивать очередное дно. Продолжаем наблюдение.

Что случилось на этот раз? :)

То же самое, что и всегда было, плюс новые "эффекты". Последнее предложение поддержки — отключить мастер-пароль.

Расскажите подробности, пожалуйста.

Подробности на видео. Там много личной информации. Но суть в том, что парольный менеджер при вводе формы с 3 полями ввода 7 раз показывает всплывающую информацию, 1 раз с модальным окном, при том, что на данном сайте он вообще ни разу не нужен. Ну и всякие детали, что окна именно поверх формы всплывают, загораживают форму, всплывают с анимацией, т. е. медленно, медленно, с анимацией, закрываются, что особенно бесит, произвольно меняются значения уже введенных полей, после чего их приходится заново перебивать, что в итоге производит просто невероятно раздражающий эффект. Ощущение, что не пароль вводишь, а играешь в шутер, постоянно ожидая врага, выскакивающего из разных мест.

Возможно, глупый вопрос, но видео в этом треде вроде как нет же, или я не туда смотрю?

Кончено нет.

полностью согласен, навязчивозть и ресурсоЖручесть Яндекс.Браузера - основная причина по которой убрал его с рабочего ноута, а на ноуте для серфинга по просторам интернета держу не основным браузером. В свое время поставил его только из-за того что хром испаганил работу с закладками и пароли яндекс хранил понадежнее. Но за годы использования много раз искал менее навязчивые и жручие альтернативы и таки нашел. не буду рекламировать, их достаточно. В конечном итоге все меньше использую браузер на новых устройствах. Думаю что скоро и вовсе откажусь от него как основной хранилки закладок и неважных паролей.

Жаль конечно, задумка с безопасным хранением хороша. Но реклама и навязчивость все испортили. И продолжают портить все больше.

Расскажите, пожалуйста, что вы имеете ввиду под навязчивостью? Сам им пользуюсь, всё ненужное отключается раз и навсегда.

не спорю - отключается .. и снова включается ! )))
искуственный интеллект однако ! )))))

так что насчет "раз" похоже на правду (хотя не все настройки можно найти на этот РАЗ) ,
а вот насчет "навсегда" - пожалуй сильно преувеличено )))

Поделитесь примерами, пожалуйста.

Знаете я не люблю длинные холивары и дискуссии, сейчас я вам приведу пример, вы возразите что у вас все работает и я просто что-то не так настроил, мне это напомнит недавно прочитанную статью о дружелюбности линукс .. в общем длинно и неинтересно.

Я не против яндекса и яндекс.браузера , более того активно его использую, но как уже сказал не ставлю больше на новые устройства и поостыл насчет полезности хранения коллекции вкладок и паролей (напомню - некритичных паролей)) в этом браузере, хотя до сих пор некоторые из друзей и родни его используют по моим рекомендациям.

Вы хотите примеров - я прямо сейчас не смогу вам повторить эти примеры - они возникают спонтанно и по законам очень близким к иррациональности Мерфи - в самый неудобный момент. Совсем недавно так сотый раз включилась Алиса (уже перестал считать сколько раз я ее навсегда отключал в настройках) и иногда выскакивают неожиданные рекламные баннеры от яндекса в момент и в месте где они совсем не нужны и да я вижу что они иногда очень релевантны моим якобы интересам а именно истории тыканья на ссылки в этом браузере .. что поделаешь за все бесплатное надо платить и я это понимаю и даже не против - я осознанно выбрал этот браузер для вполне определенных задач.

Но если вы хотите полного комплекса удовольствий, то попробуйте например установить браузер на новое устройство и ВНЕЗАПНО )) не регистрировать его в яндексе (ну представим что вы работаете в закрытом контуре и яндекс вам недоступен или подставьте что то свое по своей фантазии ) и уверяю вы получите сразу комплекс проблем с навязчивыми предложениями которые не так просто убрать навсегда. Более того, как я уже говорил даже в случае если вы таки зарегистрируетесь и вроде бы яндексу есть где хранить и к кому привязывать эти навсегдашние настройки, периодически после неведомых вам обновлений у вас будут появляться рекомендации и сервисы которые вы совсем не включали (предположим что вы не страдаете склерозом)) и даже помните что неоднократно отключали.

Это можно понять и принять, но это сильно снижает мотивацию использовать ваш продукт везде.

И да другие этим тоже грешат, но не так активно и заметно.

Надеюсь у вас все еще достаточно ресурсов чтобы поставить задачу тестерам и задавать здесь такие вопросы, это скорее неумение и нежелание признать проблемы.
Выше я привел единичные примеры которые досаждают мне, но уверен найдется немало людей со мной согласных. И да, я даже не надеюсь на решение этих проблем после этого комментария, т.к. отлично понимаю как устроена работа в больших компаниях вроде Гугла, Яндекса и т.п. Вы не сможете гарантировать, что завтра кому то из другого отдела, не придет мысль создать новый вариант продвижения услуг, и эти услуги не укроются ненавязчиво в отдельном меню "новые фишки яндекса", а неожиданно вдруг вылезут во время поиска нужной информации в яндексе. Причем недоумевающий пользователь из-за неожиданности непременно ткнет на всплывшее окошко и потом потеряет время убивая ненужную вкладку, или зависнет потеряв важную мысль)) Я все понимаю - это реальность ))) я не ругаю и не спорю с яндексом, просто констатирую факт.
Меня правда очень впечатлило, когда неожиданно включившаяся в очередной раз Алиса - открыла мультик для моего младшего сына, причем очень даже релевантно ))) и да, он ничего не нажимал, а я вообще в этот момент читал какую-то статью в яндекс.браузере )) Но это не то что я хотел бы от основного браузера. Увы для вас ))))

За сим прощаюсь.

Все так. У меня такие же ощущения после яндекс.браузера.

Честно говоря, не понял как баннеры и предложения связаны с браузером.

Вот пример с Алисой понял. Вы её выключили в настройках, но она активировалась сама вновь. Звучит как баг. Было бы идеально номер обращения с тех. данными, но он вряд ли у вас под рукой уже. Спасибо.

У меня есть номер обращения именно по такой ситуации. Только зачем он вам?

Взглянуть на полную историю проблемы. Кроме того, к перепискам прикрепляются внутренние тикеты, связанные с разработкой, где тоже могут быть полезные детали.

Ну вот я отправил вам в прошлом году номер тикета, в котором последнее сообщение было:

«Я выясню, чем вызвано такое поведение и вернусь к вам с ответом.»

Год прошел, и ни от поддержки никто не вернулся, ни от вас никакого отклика. Так стоит ли вообще заморачиваться?

Конец февраля этого года. На рабочем столе появился ярлык Яндекс.Дзен.

Вы случайно приложение Дзена не устанавливали в Браузере? Там можно сайты в приложения превращать, чтобы в отдельных окнах их открывать и без интерфейса браузера.

Это было однократно?

Вы просили примеры навязчивости, я вам их привел. Убеждать меня, что это нормально, так и должно быть, и я сам криворукий, ни к чему.

Вот эта плашка вообще не убирается.

И не должна. Это защита от зловредов, которые отключают safe browsing в браузере. Абсолютное большинство таких отключений происходит не руками пользователей. Эта плашка их спасает. Если дать её отключить, то зловреды отключат и её. Не самое элегантное решение, но лучше ещё никто не придумал.

Это не защита, а навязчивое требование яндекса разрешить ему собирать больше информации о том, что я делаю.

Жаль, что вам так кажется. Но смысл у этой штуки ровно один — тот, который я описал.

Вот эти настройки кто сделал?

Наткнулся на эту статью только сейчас, поэтому только сейчас вброшу такую идею: в качестве дополнительной защиты для восстановления мастер-паролей можно ввести подтверждение другим пользователем в "семье". Т.е.: если вы забыли пароль, то при восстановлении дополнительно будет отправлено сообщение другому пользователю, который находится в "семье", этот пользователь должен будет подтвердить, что вы сейчас сбрасываете мастер-пароль.

Можно ещё ограничить: это может только пользователь, который находится в семье минимум месяц

При этом нужно предусмотреть, что злоумышленник перед сбросом пароля может выйти из семьи. Как вариант, можно заблокировать сброс пароля в течение 3 дней после выхода из семьи

Зарегистрируйтесь на Хабре , чтобы оставить комментарий