С точки зрения безопасности, на каждом сайта рекомендуется использовать свой уникальный пароль. Если злоумышленники украдут один пароль, то только к одному сайту они и получат доступ. Проблема в том, что запомнить десятки надёжных паролей очень сложно. Кто-то честно придумывает новые пароли и записывает их руками в блокнот (а потом теряет вместе с ним же), другие – используют один и тот же пароль на всех сайтах. Трудно сказать, какой из этих вариантов хуже. Решением проблемы для миллионов обычных пользователей может быть встроенный в браузер менеджер паролей, но его эффективность зависит от того, насколько он прост и надёжен. И в этих вопросах у предыдущего решения были пробелы, о которых мы и расскажем ниже.
Почему мы создаем новый менеджер паролей?
В текущей реализации менеджера паролей для Windows, унаследованной из Chromium, сохранённые пароли защищены браузером достаточно просто. Они зашифрованы средствами операционной системы (к примеру, на Windows 7 используется функция CryptProtectData, основанная на алгоритме AES), но хранятся не в изолированной области, а просто в папке профиля. Казалось бы, в этом нет проблемы, ведь данные зашифрованы, но ключ для расшифровки тоже хранится в операционной системе. Любая программа на компьютере может перейти в папку профиля браузера, взять ключ, локально расшифровать пароли, отправить их на сторонний сервер, и никто этого не заметит.
А ещё многие пользователи хотели бы, чтобы случайный человек, не обладающий специальной подготовкой, но получивший кратковременный доступ к браузеру (например, родственник или коллега по работе), не смог авторизоваться на важных сайтах с помощью сохранённых паролей.
Обе эти проблемы решаются с помощью мастер-пароля, которым защищаются данные, но который нигде не хранится. И это стало нашим первым требованием к новой архитектуре хранения паролей в Яндекс.Браузере. Но не единственным.
Каким бы безопасным ни был новый менеджер паролей, его популярность зависит от того, насколько просто им пользоваться. Напомним, что те же 1Password, KeePass и LastPass даже в сумме используют не более процента пользователей (хотя LastPass мы предлагаем в нашем встроенном каталоге дополнений). Или другой пример. Вот так в старой реализации Браузер предлагает сохранить пароль:
Опытные пользователи или согласятся, или откажутся, или сделают хоть что-то с этим уведомлением. Но в 80% случаев его просто не замечают. Многие пользователи даже не знают, что в браузере можно сохранять пароли.
Отдельно стоит сказать про функциональность. Сейчас даже добраться до списка своих паролей не так уж и просто. Нужно открыть меню, кликнуть по настройкам, перейти в дополнительные настройки, найти там кнопку управления паролями. И только тогда человек получит доступ к примитивному списку аккаунтов, которые нельзя отсортировать по логину, нельзя добавить текстовое примечание, отредактировать тоже нельзя. К тому же менеджер паролей должен помогать придумывать новые пароли.
И ещё кое-что. Для нас было важно, чтобы новая архитектура соответствовала принципу Керкгоффса, то есть, чтобы её надежность не зависела от знаний злоумышленников о применяемых алгоритмах. Криптосистема должна оставаться безопасной даже в том случае, когда им известно всё, кроме применяемых ключей.
Почему мы не взяли готовое решение?
Существуют продукты с открытым исходным кодом, которые поддерживают мастер-пароль и расширенную функциональность. Их можно было бы интегрировать в браузер, но они нам не подошли по ряду причин.
В первую очередь на ум приходит KeePass. Но его хранилище зашифровано целиком, а у нас в Браузере синхронизация работает построчно. А значит, надо либо спрашивать мастер-пароль при каждой синхронизации, либо шифровать записи раздельно. Второй вариант добрее к пользователям. Более того, для массового продукта важно, чтобы пользователь знал о возможности подставить сохранённый пароль до разблокировки базы мастер-паролем, поэтому часть информации должна оставаться незашифрованной.
У специализированных дополнений для работы с паролями есть возможность сбросить мастер-пароль, если пользователь его забыл. Но для этого нужно скачать, спрятать и не потерять резервный код или файл. Это нормально, когда речь идет об опытных пользователях, но это сложно для всех остальных. Поэтому нам нужно было придумать альтернативное решение. Спойлер: в итоге нам удалось найти решение, при котором мастер-пароль сбросить можно, но даже Яндекс не сможет получить доступ к базе. Но об этом чуть позже.
А ещё любое стороннее решение в любом случае пришлось бы серьезно дорабатывать, чтобы нативно интегрировать в браузер (переписать на C++ и Java) и сделать его достаточно простым для пользователей (полностью заменить весь интерфейс). Как бы удивительно это ни звучало, но написать новую архитектуру хранения и шифрования паролей проще, чем сделать всё остальное. Поэтому логичнее не пытаться связать два изначально несовместимых продукта в один, а доработать свой.
Новая архитектура с использованием мастер-пароля
В хранении самих записей нет ничего необычного. Мы используем надежный и быстрый алгоритм AES-256-GCM для шифрования паролей и примечаний, адреса и логины не шифруем для удобства применения, но подписываем для защиты от подмены. Похожим образом устроена схема хранилища в том же 1Password.
Самое интересное – это защита 256-битного ключа encKey, который необходим для расшифровки паролей. Это ключевой момент безопасности паролей. Если злоумышленник узнает этот ключ, то легко взломает всё хранилище независимо от сложности алгоритма шифрования. Поэтому защита ключа основана на следующих базовых принципах:
– Доступ к ключу шифрования блокируется мастер-паролем, который нигде не хранится.
– Ключ шифрования не должен быть математически связан с мастер-паролем.
В простых сервисах и приложениях ключ шифрования получают путем хэширования мастер-пароля, чтобы хоть так замедлить атаку перебором. Но математическая зависимость ключа от мастер-пароля всё же упрощает взлом, скорость которого в этом случае зависит лишь от надежности хэширования. Применение ферм из заточенных на взлом ASIC-процессоров сейчас уже не редкость. Поэтому в нашем случае ключ encKey не является производным от мастер-пароля и генерируется случайно.
Далее ключ encKey зашифровывается с помощью асимметричного алгоритма RSA-OAEP. Для этого Браузер создает пару ключей: открытый pubKey и закрытый privKey. Ключ encKey защищается с помощью открытого ключа, а расшифровать его можно только с помощью закрытого.
Открытый ключ pubKey защищать не нужно, потому что он не подходит для расшифровки, а вот с закрытым privKey история другая. Чтобы защитить его от кражи, доступ к нему блокируется согласно стандарту PKCS#8 с помощью парольной фразы unlockKey, которая в свою очередь является результатом хэширования мастер-пароля с помощью функции PBKDF2-HMAC-SHA256 (100 тысяч повторов; с добавлением соли и id хранилища). Если мастер-пароль случайно совпадает с уже украденным паролем от какого-либо сайта, добавление соли скроет этот факт и усложнит взлом. А благодаря многократному хэшированию достаточно длинного мастер-пароля трудоемкость взлома unlockKey сопоставима со взломом ключа encKey.
Зашифрованные пароли, зашифрованный ключ к ним encKey, зашифрованный закрытый ключ privKey и открытый ключ pubKey хранятся в профиле браузера и синхронизируются с другими устройствами пользователя.
Чтобы было проще разобраться во всём этом, приведем схему расшифровки паролей:
У подобной архитектуры с использованием мастер-пароля есть ряд преимуществ:
– 256-битный ключ шифрования хранилища генерируется случайно и обладает высокой криптостойкостью по сравнению с паролями, придуманными человеком.
– При брутфорсе мастер-пароля злоумышленник не узнает результат, если не пройдется по всей цепи (пароль-PBKDF2-RSA-AES). Это очень долго и очень дорого.
– Если функция хэширования будет скомпрометирована, мы в любой момент можем перейти на альтернативный вариант хэширования с сохранением обратной совместимости.
– Если злоумышленник узнает мастер-пароль, то сменить его можно без сложной и рискованной процедуры расшифровки всего хранилища, потому что ключ шифрования данных не связан с мастер-паролем, а значит, не скомпрометирован.
– Ключ шифрования хранится в зашифрованном виде. Ни Яндекс, ни злоумышленник, похитивший пароль от Яндекса, не смогут получить доступ к синхронизированным паролям, поскольку для этого нужен мастер-пароль, который нигде не хранится.
Но у варианта с мастер-паролем есть один «недостаток»: пользователь может забыть мастер-пароль. Это нормально, когда речь идет о специализированных решениях, которые используют опытные пользователи, хорошо осознающие риск. Но в продукте с многомиллионной аудиторией это неприемлемо. Если мы не предусмотрим резервный вариант, то многие пользователи Яндекс.Браузера либо откажутся от использования мастер-пароля, либо «потеряют» однажды все свои пароли, а виноват в этом будет Браузер (вы удивитесь, но именно Яндекс часто оказывается крайним в ситуации, когда человек забыл пароль от аккаунта). И придумать решение не так уж и просто.
Как сбросить мастер-пароль без раскрытия паролей?
В некоторых продуктах эта проблема решается с помощью хранения расшифрованных данных (или даже мастер-пароля) в облаке. Этот вариант для нас не подходил, потому что злоумышленник может украсть пароль от Яндекса, а вместе с ним и пароли от всех сайтов. Поэтому нам нужно было придумать такой способ восстановления доступа к хранилищу паролей, при котором никто, кроме самого пользователя, не смог бы это сделать. Сторонние менеджеры паролей предлагают для этого создать резервный файл, который пользователь должен самостоятельно хранить в надежном месте. Хорошее решение, но обычные пользователи такие резервные ключи будут неизбежно терять, поэтому у нас всё намного проще.
Ещё раз вспомним цепочку зависимостей ключей. Хранилище паролей зашифровано с помощью случайного ключа encKey, который нигде не хранится в явном виде. Этот ключ защищён с помощью закрытого ключа privKey, который также не хранится в явном виде и в свою очередь защищён с помощью сложного хэша от мастер-пароля. Когда человек забывает мастер-пароль, он фактически лишается возможности расшифровать ключ privKey. Это значит, что в качестве резервного варианта можно хранить дубликат ключа privKey. Но где? И как его защитить?
Если поместить расшифрованный privKey в облако, то безопасность паролей будет зависеть от аккаунта Яндекса. А ровно этого мы и не хотели допускать. Если же хранить его в явном виде локально, то вся защита с мастер-паролем теряет какой-либо смысл. Нет такого места, где можно было бы безопасно хранить этот ключ в явном виде. Значит, его надо шифровать. Для этого Браузер создает случайный 256-битный ключ, которым защищает дубликат privKey. Теперь самое интересное. Этот случайный ключ отправляется на хранение в облако Яндекс.Паспорта. А зашифрованный дубликат остается храниться в локальном профиле Браузера. Получается, что ни в облаке, ни на компьютере нет готовой пары для расшифровки паролей, и безопасность не страдает.
При таком варианте сбросить мастер-пароль можно было бы только там, где и создан дубликат ключа privKey. Мы же хотели добавить такую возможность и синхронизированным устройствам. Создавать резервный ключ на каждом устройстве вручную неудобно: можно случайно остаться с тем устройством на руках, на котором забыли создать дубликат. Отправлять зашифрованный дубликат на другие устройства с помощью синхронизации нельзя: в облаке уже хранится ключ к нему, и в целях безопасности им нельзя встречаться в одном месте. Поэтому зашифрованный дубликат privKey проходит через ещё один слой шифрования. В этот раз – с помощью хэша от мастер-пароля. Мастер-пароль не хранится в облаке, поэтому полученную «матрешку» уже можно смело синхронизировать. На других устройствах в момент первого ввода мастер-пароля дополнительный слой шифрования будет снят.
В итоге, когда пользователь забудет мастер-пароль, ему будет достаточно запросить сброс пароля через браузер и подтвердить свою личность с помощью пароля от Яндекса.
Браузер запросит ключ у Яндекс.Паспорта, расшифрует им дубликат ключа privKey, с его помощью расшифрует ключ от хранилища encKey, а дальше создаст новую пару pubKey и privKey, последний из которых будет защищён новым мастер-паролем. Хранилище паролей при этом не расшифровывается, что снижает риск потери данных. К слову, принудительно сменить encKey и перешифровать данные тоже можно: достаточно отключить и заново включить мастер-пароль в настройках.
Получается, что сбросить мастер-пароль сможет только сам пользователь и только на том устройстве, где он хотя бы раз его вводил. Конечно же, резервный ключ создавать не обязательно, если пользователь уверен в себе. Даже мастер-пароль можно не использовать, хотя мы и не рекомендуем от него отказываться.
Новая архитектура и мастер-пароль – не единственные изменения в новом менеджере. Как мы уже рассказывали выше, удобство в использовании и расширенные возможности важны не меньше.
Новый менеджер паролей
Прежде всего, мы отказались от незаметной серой панели с предложением сохранить пароль. Теперь пользователь увидит предложение рядом с полем пароля. Не заметить такое уже трудно.
Да и сам менеджер теперь не надо искать в настройках: кнопка доступна в главном меню. Список сохранённых аккаунтов теперь поддерживает сортировку по логину, адресу и примечанию. Мы также добавили редактирование записей.
Подсказка: примечания отлично подходят в качестве альтернативы меткам, потому что поддерживают поиск.
А ещё Браузер теперь помогает создавать уникальные пароли.
В первой бета-версии мы успели далеко не всё. В будущем мы поддержим экспорт и импорт паролей для совместимости с популярными сторонними решениями. Также у нас есть идея добавить настройки генератору паролей.
Мобильный менеджер паролей
Конечно же, новая логика и поддержка мастер-пароля появятся не только на компьютере, но и в версиях Яндекс.Браузера для Android и iOS. С небольшой адаптацией. К примеру, можно использовать не только мастер-пароль, но и отпечаток пальца. Мы также запретили программно делать скриншоты на странице со списком паролей – можно не бояться вредоносных приложений.
Сегодня новый менеджер паролей можно попробовать в бета-версии Яндекс.Браузера для Windows и macOS (версия для Linux традиционно собирается на базе стабильного кода, поэтому выйдет чуть позже). В ближайшее время он также заработает в альфа-версии Браузера для Android (а ещё через некоторое время появится и в бете для iOS).
Мы постоянно ищем баланс между простым, но надежным инструментом для миллионов пользователей и расширенными возможностями для тех, кому они нужны. Пожалуйста, поделитесь с нами видением идеального менеджера паролей, который именно вы хотели бы видеть в браузере.
И ещё кое-что. Мы приглашаем специалистов в области безопасности помочь нам найти уязвимости в новом менеджере паролей в рамках программы "Охота за ошибками". С вашей помощью менеджер паролей станет ещё безопаснее. Спасибо!
Комментарии (113)
Scf
12.12.2017 13:30Познавательно, красиво и… опасно. Появятся трояны, специализированные для кражи всех сохраненных паролей из браузера. Принцип достаточно прост — "подсмотреть" мастер-пароль при вводе кейлоггером или пропатчить исполняемый код браузера на диске/непосредственно в памяти. Когда пользователь введет мастер-пароль, все его пароли будут расшифрованы и переданы.
BarakAdama Автор
12.12.2017 13:38При локальном трояне и сторонние менеджеры паролей не помогут. Но! У нас в бете ещё одна штука тестируется. Она запрещает вмешиваться в процесс браузера и перехватывать клавиатуру. Это должно снизить риск.
Scf
12.12.2017 13:45Да, это общая проблема всех менеджеров паролей, особенно самых популярных. Про "штуку" — верится с трудом в юзермоде. Заточенный под вас троян всё это обойдет.
Я пришел к выводу, что менеджер паролей надо или иметь в бумажном виде, или на отдельном устройстве, или писать самому.
melt
12.12.2017 14:40Бумажный вид не имеет надежного шифрования, а значит любой неожиданный гость: знакомый, друг, племянник или человек в погонах легко воспользуется вашими записями. Даже если не учитывать, что человек в погонах получит ваши пароли в любом случае, будь они хоть чем зашифрованы.
Безусловно хранилище с менеджером паролей необходимо более достойно защищать — права доступа явно ограничивать, как минимум, для внесения изменений (отдельный пользователь, администратор и etc); использовать фаервол для ограничения выхода в сеть всяких кейлогеров, даже если антивирусная защита их вдруг пропустила.
Согласитесь, такая методика имеет право на существование? А то read-only начитаются хабра и пойдут массово за блокнотами :)Scf
12.12.2017 15:01Я думаю, не-айтишникам значительно проще защитить от несанкцированного доступа блокнот, чем файл на компе. Это нетривиальная задача. Например, с файрволлом всё не так просто — трояны наловчились отправлять данные через браузер, через виндовые системные сервисы и т.п.
Самый "правильный" вариант — отдельное устройство с шифрованием) Телефон например, если не ставить на него что попало.
looogle
12.12.2017 16:04Тут так и напрашивается ссылочка на аппаратный менеджер паролей. Например, Pastilda https://bitbucket.org/thirdpin_team/pastilda
Правда есть всё таки есть несколько проблем, такие как:
- паяльник;
- оставил пастильду включенной и разблокированной, можно быстренько прибежать и слямзить пароль.
Но по крайней мере мастер пароль будет в безопасности всегда.
NeuroHunter
12.12.2017 15:25Разумеется, заточенный под конкретное (в том числе — самописное) решение троян сможет сломать это конкретное решение. Как говорится, «если именно вашу машину решили угнать, ее угонят».
Но от более общего трояна, ориентированного на кражу паролей из Chromium-подобных браузеров, это вполне спасет.
navion
12.12.2017 17:47Появятся трояны, специализированные для кражи всех сохраненных паролей из браузера.
Что же ещё готовит для нас грядущий 2004-й год?
Такие трояны существуют с появления возможности сохранить пароль в приложениях. Автор «учебного трояна» когда-то много писал про механизмы защиты и даже сделал антименеджер паролей.
Steed
13.12.2017 09:35Принцип достаточно прост — "подсмотреть" мастер-пароль при вводе кейлоггером
В том же 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."
gotch
12.12.2017 13:35Очень интересно. Lastpass стал таким тяжелым и медленным.
Но было бы здорово оставить опцию сохранения ключа восстановления мастер пароля не только в локально/облако, но и на сменный носитель.
brun4eg
12.12.2017 13:40+1Звучит разумно!..
Мы подумаем, как можно сделать запасной ключ, но вместо облака дать пользователю возможность самостоятельно хранить его где-то.gotch
12.12.2017 14:49Здорово. Ждем.
Но пока, конечно, существование таких утилит беспокоит:
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
GreedyIvan
12.12.2017 14:28Т.е., чтобы пользоваться такой системой постановки паролей на моих любимых сайтах, мне надо каждый раз вводить мастер-пароль? Если так, то через два-три сайта я такую заботу отключу нафиг.
BarakAdama Автор
12.12.2017 14:31Мы же не садисты :) Там можно выбрать, когда нужно спрашивать мастер-пароль: по времени, после блокировки компьютера, после перезапуска браузера.
mannaro
12.12.2017 15:35А будет возможность вводить пароль каждый раз? Какая разница — вводить каждый раз уникальный пароль на сайт или вводить мастер-пароль и забирать реальный пароль для сайта?
А то сейчас страшно сохранять в браузере пароли, учитывая, что уже один раз забрали пароль и это мне многого стоило :)BarakAdama Автор
12.12.2017 15:57Это очень жёсткий вариант. Посмотрим на то, сколько таких просьб к нам поступит.
MonkAlex
12.12.2017 16:00В lastpass есть крутая штука — конкретные аккаунты требуют мастер пароля.
Условно, банки под паролем — остальное не жалко.
ClearAirTurbulence
12.12.2017 14:50Менеджер паролей от поисковика, делающего деньги на рекламе и пользовательских данных*? Отличная идея!
*Я не говорю, что это что-то плохое, каждый делает деньги, как может :)brun4eg
12.12.2017 14:58Мы специально рассказываем о том, как устроено наше шифрование, чтобы ни у кого не осталось сомнений, что сохранённые пароли не будут доступны никому постороннему, даже Яндексу и мы очень стараемся, чтобы всё было надёжно и безопасно.
Поэтому да, менеджер паролей от Яндекса — это отличная идея!melt
12.12.2017 15:25Да ладно, так уж и даже Яндексу недоступны? )
Этот случайный ключ отправляется на хранение в облако Яндекс.Паспорта. А зашифрованный дубликат остается храниться в локальном профиле Браузера.
У вас же имеется доступ в локальный каталог, что греха таить? Я не ругаю и ничего против не имею, но сам факт. Кто захочет не верить, основания найдутся :)brun4eg
12.12.2017 15:43Там немного сумбурная формулировка в посте получилась, на самом деле
1. Делается копия закрытого ключа
2. На эту копию ставится случайный 256-битный пароль
3. Этот пароль отправляется в облако Яндекса, а ключ, защищённый паролем никогда не отправляется в таком виде в облако (чтобы ключ и пароль от него не оказались в одном месте)
4. А при синхронизации этот «запароленный ключ» ещё раз шифруется при помощи мастер-пароля, чтобы таким образом «доставить» его на другие устройства, где он может потребоваться для сброса мастер-пароля.
Понятно, что доверие к ПО это очень субъективная вещь, но у нас есть программа вознаграждений за баги и если вдруг кто-то обнаружит, что есть уязвимость и мы как-то небезопасно обрабатываем пароли, то мы это исправим и заплатим исследователю за помощь в обнаружении уязвимости.
Kanedias
12.12.2017 16:17Ну, чтобы убедить параноиков простого объяснения вряд ли достаточно. Вам нужно показать код, провести его публичный аудит, доказать (с помощью deterministic compilation) что этот код собирается именно в тот бинарник, который присутствует в браузере, показать что кроме этого кода браузер более ничем не пользуется и не вытаскивает пароли в облако после разблокировки. Вот тогда да, тогда можно будет сказать, что ни у кого не осталось сомнений :)
brun4eg
12.12.2017 17:34Параноики не поверят нам даже при таком сценарии и будут пользоваться аппаратными хранилищами паролей, использовать пароли, которые они придумывают по известному одним им алгоритму в голове или собирать Keepass из исходников, проверяя, что там внутри :)
AllegroMod
13.12.2017 07:53Ну вот неправда, не нужно этих ложных дилемм и деления всех на разгильдяев либо сумасшедших. Я себя считаю довольно-таки озабоченным безопасностью человеком, да и всякие криптокошельки и интернет-банки, где можно потерять не только доступ к фоточками, но и немало денег, стимулируют выработку полезных привычек. Тем не менее, мне было бы гораздо спокойней пользоваться программой, если бы я знал, что её код может посмотреть ещё кто-то, кроме сотрудников Яндекса.
melt
12.12.2017 15:10Как ни странно, но только 1% пользователей браузера используют специализированные расширения для хранения паролей
Сколько уязвимостей ежемесячно закрывается в Chromium? Доверие гиков, конечно, не удастся таким образом завоевать. Хотя если их всего 1% или даже того меньше, то и не так страшно.
Чтобы давить на массовость, не хватает дополнительных полей для хранения. Если уж пользователю переходить полностью на ваш менеджер, то иногда требуется хранить еще какие-нибудь сведения (пин-код карты, пин от приложения на телефоне или что-то еще). Еще было бы неплохо показывать качество выбранного пароля, чтобы пользователь понимал, что qwertyhello123 совсем некруто, как говорит, например, KeePass :)
Почему не Argon2 или OSCrypt? На мобильных устройствах отсутствует AES-NI, сейчас же есть модный и быстрый ChaCha20-Poly1305?brun4eg
12.12.2017 15:18+1Дополнительные поля и типы записей будут, это востребованная функция.
По поводу визуализации качества паролей мы подумаем, спасибо.
По поводу криптографии: мы постарались использовать надёжные и многократно проверенные алгоритмы, которые уже есть в boringssl. Однако, как уже было написано в посте, мы не привязаны к определённым алгоритмам шифрования или хеширования и можем без проблем сделать апгрейд до более новых методов при необходимости.
Модный или новый алгоритм — это не всегда хорошо, мы же не на конкурс красоты пришли :)
BarakAdama Автор
12.12.2017 15:37Chromium большой, и уязвимости там обычно не в паролях ищут. Со своей стороны мы поддерживаем программу «Охота за ошибками», где тоже выплачиваем вознаграждения. В остальном продолжаем участвовать в проекте Chromium. Проще говоря, комбинируем сильные и слабые стороны.
Develar
12.12.2017 15:24Насколько вы сами видите актуальность своего решения на таких системах, как macOS, где уже есть свой keychain? Без необходимости запоминать master password? Конечно, необходимость ввода не столь остра, так как браузер не часто перезапускается, но тем не менее.
Или основная аудитория Window?
NeuroHunter
12.12.2017 15:29В зависимости от настройки, keychain может требовать пароль при каждом обращении.
А актуальность очевидная — синхронизация. По той же причине на macOS до сих пор существует 1Password и другие менеджеры паролей, несмотря на то, что keychain можно синхронизировать через iCloud и она позволяет генерировать неплохие пароли при потребности.
brun4eg
12.12.2017 15:30Действительно, в Mac OS Keychain защищён довольно неплохо, но есть ещё синхронизация паролей. В случае синхронизации, отправлять незашифрованные данные в облако это не очень хорошая идея. Как раз для решения этой проблемы отлично подходит мастер-пароль.
Разумеется, в случае, когда мастер-пароля нет, мы тоже шифруем отправляемые данные, но ключ шифрования тоже хранится в облаке, поэтому мастер-пароль намного лучше.
P.S. В случае, если вы на Mac OS заведёте мастер-пароль и снимете чекбокс «Запрашивать мастер-пароль для доступа к паролям», то он будет запомнен в Keychain, а в синхронизацию пароли будут отправляться надёжно зашифрованными и на других устройствах без ввода мастер-пароля они будут недоступны.
GreedyIvan
12.12.2017 15:56Как я понял, основная задумка в том, что если произойдет компрометация локального хранилища, то пароли вытащить не получится. Тут два момента:
Если нет мастер-пароля, то доступ, всё-таки, будет?
Если есть мастер-пароль и выбрана опция наличия запасного ключа, то что помешает запросить пароль от этой запасной копии из Яндекс.Паспорта?BarakAdama Автор
12.12.2017 16:11Если нет мастер-пароля, то ключ хранится где-то в системе. Поэтому с мастер-паролем, который нигде не хранится, сильно надёжнее.
Чтобы запросить пароль у Паспорта, нужен ещё пароль от Яндекса.
brun4eg
12.12.2017 16:14Если нет мастер-пароля, то доступ, всё-таки, будет?
Без мастер-пароля физически получится только прочесть логины и адреса сайтов.
Однако, если Keychain позволит получить его, тогда да, доступ к паролям будет, поэтому выключение настройки про запрос пароля это не самая лучшая идея, если у посторонних может быть физический доступ к компьютеру. Мы предусмотрели возможность отключения запроса мастер-пароля на случай, если пользователь захочет, чтобы все данные в облаке были надёжно зашифрованы, а за безопасность устройства и паролей на нём он хочет отвечать сам.
Если есть мастер-пароль и выбрана опция наличия запасного ключа, то что помешает запросить пароль от этой запасной копии из Яндекс.Паспорта?
В общем случае — незнание пароля от Яндекса, но «угнав» учётную запись от Яндекса, злоумышленник скорее всего и так сможет через почту сменить/украсть много разных паролей от сайтов, где используется этот ящик.
Однако, если включена 2-факторная авторизация, вероятность такого сценария крайне мала.GreedyIvan
12.12.2017 16:53Не вижу, чем принципиально отличается предложенная схема хранения паролей от хранения их в облаке (том же Яндекс.Паспорте)? С полностью обратной логикой хранения.
В профиле достаточно хранить только информацию, для расшифровки «дубликата» приватного ключа, который хранится в облаке. Т.е. расшифровать всё то, что храниться в облаке, можно либо с помощью мастер-пароля, который вводит пользователь и «который нигде не хранится», либо с помощью неких данных в профиле браузера, которые могут использоваться вместо мастер-пароля.
Если пользователь откажется от «дубликата», то в с облаке будут просто зашифрованные данные, а в профиле — ничего.brun4eg
12.12.2017 17:15Разумеется, так можно, но тогда пароли будут доступны только при наличии интернета и связи с Яндексом. Браузер могут использовать в условиях, когда Яндекс недоступен или публичного интернета нет, а есть только интранет.
Выворачивание логики хранения наизнанку не усиливает безопасность, но уменьшает удобство.GreedyIvan
12.12.2017 17:35Выворачивание логики хранения наизнанку не усиливает безопасность, но уменьшает удобство.
Усиливает, причем катастрофически. Исключаются векторы атаки, направленные на пользовательские устройства (коих множество), так как на них ничего нет (кроме «дубликата» мастер-пароля, но это больше вопрос проверки тех, кто приходит с дубликатом). Да и сами дубликат можно регулярно перевыпускать без участия пользователя.
а есть только интранет.
Ничто не мешает дать пользователю опцию локального хранения всего этого зашифрованного добра (кроме функций работы с дубликатом), на случай, если нужны функции хранения паролей браузера в интранет-среде. В интранет-среде ни о какой синхронизации речи не идёт, поэтому для этой опции можно использовать отличную от обачного хранения реализацию.
Madzi
12.12.2017 16:05Подскажите пожалуйста, планируется ли интеграция с токенами (такими как rutoken ecp, yubikey и т.п.)? Мне было бы удобно сгенерить неизвлекаемый аппаратный секретный ключ и использовать его для расшифровки записей о паролях. И запоминать / сохранять его куда-то не нужно. Все операции шифрования/расшифровки на токене.
BarakAdama Автор
12.12.2017 16:15Идей много. Точные планы зависят от количества тех или иных запросов и результатов тестирования. Подумаем, спасибо.
brun4eg
12.12.2017 16:16Пока конкретных планов нет, но мы посмотрим, что можно сделать, чтобы унести защиту на аппаратный уровень.
sabio
13.12.2017 13:32В Chrome встроена поддержка стандарта U2F. Не знаю, правда, является ли этот код частью Chromium.
2FA для менеджера паролей оставит "специально заточенные трояны" без работы.
tundrawolf_kiba
12.12.2017 16:12Было бы неплохо, если бы были подсказки о том, что текущий пароль слабый, ну и в целом — проблемы с паролями в менеджере чтобы подсвечивались(дублирующий пароль, слабый пароль и т.п.)
CryptoPirate
12.12.2017 16:56Пожалуйста, расскажите как вы ключи для RSA генерируете (там просто почти в каждом шаге алгоритма накосяцить можно), и ещё, какой они длинны?
brun4eg
12.12.2017 17:31Мы используем RSA_OAEP_2048_SHA256
Генерируем и экспортируем ключи через стандартную библиотеку Chromium boringssl через класс RSAPrivateKey. В криптографии велосипеды изобретать плохо, правильно брать что-то стабильное и давно работающее, что мы и сделали.CryptoPirate
12.12.2017 18:51+1Спасибо. Еще у меня такой вопрос: зачем вам AES-256, когда AES-128 хватило бы с головой?
Особенно, если учесть что у вас RSA-2048 (примерно 128 бит «криптостойкости») и SHA-256 (тоже 128 бит защиты т.к. парадокс дней рождения). Плюс на AES-256 больше атак чем на AES-128 (key schedule). Ну, и, AES-128 был бы бустрее, ибо 10 раундов вместо 14ти.
Выходит вам явно 128-битная версия больше подошла бы или у вас на этот счёт какие-то другие соображения?brun4eg
12.12.2017 23:07Могу ошибаться, но есть такое мнение, что в случае, если внезапно придумают успешную атаку на AES-128, возможно, в 2 раза больший ключ будет чуть сложнее взломать, а может и нет, а вот более медленная расшифровка AES 256 нам скорее на руку, т.к. замедляет перебор, но не настолько, чтобы это было визуально заметно.
Ну, в общем, это скорее из области психологии: «256 бит больше 128, а значит надёжнее, пока обратное не доказано».
Про 2048 бит — да, это где-то 112 бит сложности, поэтому действительно ключ 128 бит по общей сложности подошёл бы лучше, да и не 2048, а 3072 правильнее было бы тогда. Кстати, при определённых обстоятельствах, атака на AES-256 как раз снижает стойкость именно до 112 бит, что отлично согласуется с текущей стойкостью 2048 RSA.
А вообще, мы заложили в архитектуру возможность почти безболезненно менять алгоритмы шифрования/хеширования, поэтому ни к чему не привязаны и планируем регулярно повышать сложность и применять более современные алгоритмы при необходимости.
Если уже быть совсем честным, то самое слабое звено в системе — мастер пароль. Если пользователь выбирает недостаточно сложный/длинный мастер-пароль, никакие алгоритмы и большие ключи не помогут.CryptoPirate
13.12.2017 11:23Могу ошибаться, но есть такое мнение, что в случае, если внезапно придумают успешную атаку на 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 «более толстый». Я, собственно, только по тому и поинтересовался, что на мой взгляд размеры ключей друг другу не соответствуют.
То что есть возможность заменить алгоритмы и всё это продумано с самого начала и заложено в идею — это очень даже правильно.
justhabrauser
12.12.2017 18:42-1«версия для Linux» — версия для Debian-based Linux, уточняйте же.
Ну да, Ubuntu == Linux. Но Linux != Ubuntu.
forester11
12.12.2017 19:42авторы нового менеджера пароля пишут что пытаются защитится от злоумышленника получившего доступ к компьютеру жертвы…
но что тогда мешает злоумышленнику с доступом заинсталировать key-logger и получить мастер пароль в момент ввода в будущем? стоимость взлома в обоих случая примерно одинаковая, низкая.
в этом плане нет никакой разницы есть ли на паролях мастер пароль или нет… доступ к компьютеру позволяет обойти как первый так и второй.
я думаю сейчас самой сильной защитой от доступа к ключам является двух-факторная аутентификация, и у Гугла уже есть решение на этой базе — Smart Lock. и судя по тому что я читал эту штука заинтегрирована в Chrome. т.е. для решения задачи безопасного хранения паролей в Chrome достаточно включить двух-факторную аутентификацию, в одно-факторной версии безопасности же никогда не будет в принципе.BarakAdama Автор
12.12.2017 20:55Мешает наша другая фича, которая тоже тестируется в бете и не дает трогать процессы браузера и использовать перехват клавиатуры.
Не очень понимаю, как вам поможет тут Smart Lock. Это про разблокировку мобильного устройства, а не про защиту паролей. В части паролей это как раз то самое решение из Chromium, о котором мы и писали. Если не ошибаюсь, там пароли хранятся на сервере в явном виде (их же можно посмотреть на сайте?). И, кажется, хранение ключа вместе с паролями на устройстве (любой софт может их забрать). Или я не туда смотрю?forester11
13.12.2017 00:28Да возможно это и не совсем то: скорее всего все пароли дублируются на клиенте… Я почему то думал что эта двойная аутентификация используется чтобы шифровать сами пароли. А она скорее всего просто проверяет вход в гугл «домейн» а дальше уже как обычно, безопасность повышается только если конкретный сайт поддерживает аутентификацию напрямую через гугл-апи (многие это начинают кстати делать).
Вот интересно, можно ли сделать шифрование паролей с двух-факторным аутентификатором/динамическим ключом? Т.е. пользователь пытается получить пароль от сайта, вводит мастер пароль + на телефон приходит вопрос ввести пин, далее если пин верный телефон возвращает какой-то временный ключ открыть базу с паролями… Что-то типа кодового калькулятора как в интернет банках.
BarakAdama Автор
13.12.2017 07:48Теоретически всё возможно, я думаю. Но защита и сейчас уже не однофакторная. Одного мастер-пароля недостаточно. Нужно ещё хранилище паролей и ключи к нему.
iandarken
13.12.2017 14:45Это та самая фича, которая сейчас в Хроме и которая не даст мне делать shift-break силами Punto Switcher?
Arxitektor
12.12.2017 19:54для решения задачи безопасного хранения паролей в Chrome достаточно включить двух-факторную аутентификацию
Прошу подробностей как это работает? И как настроить?forester11
13.12.2017 00:32Это была дикая теория, не уверен что включение этой штуки повлияет на то как хранятся сами пароли на клиенте. :)
Сам пользуюсь KeePass но понимаю что если кто-то поставит на мой компьютер логгер/троян вся мои пароли перестанут быть секретом… Надо бы найти (сделать?) 2-х факторный хранитель паролей с динамическим ключом — такие алгоритмы любят в банках использовать.
saipr
12.12.2017 20:19Мы используем надежный и быстрый алгоритм AES-256-GCM для шифрования паролей и примечаний, адреса и логины не шифруем для удобства применения, но подписываем для защиты от подмены.… Чтобы защитить его от кражи, доступ к нему блокируется согласно стандарту PKCS#8 с помощью парольной фразы unlockKey, которая в свою очередь является результатом хэширования мастер-пароля с помощью функции PBKDF2-HMAC-SHA256 (100 тысяч повторов; с добавлением соли и id хранилища).
Я не понял, а где кузнечики и магмы и наши российскик шмаки и маки?
iSm1le
12.12.2017 21:01Обожаю некоторые сервисы, приложения и др. от Яндекса. Например Яндекс.Музыка очень хороша (единственное пришлось отказаться по причине недоступности в Украине, всё таки не очень удобно исп. прокси или впн, жду встроенного прокси в приложение:)), приятно видеть что Вы развиваетесь и не стоите на месте. Хотелось бы протестировать новый менеджер, но я буду ждать импорт из LastPass, а то не очень удобно вручную добавить 200+ сайтов:) Жду и надеюсь:)
PostProductionService
12.12.2017 21:01пользуюсь Roboform на всех устройствах, более 10 лет, удобнее и надёжнее пока не встречал.
Brodyagos
12.12.2017 21:02У меня два вопроса, один по паролям, второй нет…
Первый: Почему шифрование не по ГОСТ, трудности с реализацией или пока сделали как удобнее? Планируется ли он?
Второй… В нашем проекте внезапно обнаружилось при КАЖДОМ обновлении браузера происходят чудеса с шифрованием соединения по ГОСТ, в лучшем случае просто пропадает галка в настройках, в худшем ведёт себя как чистый хромиум не понимая что от него хотят. Спасает только чистая установка, это нормальная ситуация?)BarakAdama Автор
12.12.2017 21:08Не очень понятно, зачем отказываться про проверенных и активно развиваемых сообществом библиотек и алгоритмов. Мы – часть этого сообщества.
Поддержка сайтов с шифрованием по ГОСТу (с помощью стороннего плагина) ещё в процессе отладки. По готовности расскажем отдельно (в нашем блоге браузера). Пожалуйста, о любых странностях пишите нам сразу через «Сообщить о проблеме» в меню браузера.
Brodyagos
12.12.2017 21:18Корпоративный сектор, точнее государственный, тоже часть сообщества )) Однако рамки у нас очень узкие и клещи близко к уязвимым местам.
Про шифрование по ГОСТу ждём статьи, а вопрос продублирую в трекер, в рабочее время не успел ))
3dcryx
12.12.2017 22:48Очень долго не мог понять в чем обман (он по определению есть, т.а ничего принципиально нового в криптографии не изобретали лет 10 и теперь не изобретут наверно никогда). Тут все просто. Вы добавили пароль сброса равный паролю от Яндекса.
BarakAdama Автор
12.12.2017 23:00Нет. Его одного мало. И сброс подключать тоже не обязательно.
Никто не говорит, что криптография тут принципиально новая. Но хорошая защита для браузеров – редкость.
brun4eg
12.12.2017 23:11Никакого обмана. Включите 2-факторную авторизацию и возможность сброса перестанет зависеть от пароля от Яндекса. А подобрать 256-битный пароль для запасного ключа ни у кого всё равно не получится.
MrFrizzy
13.12.2017 03:00Спасибо за статью, интересно почитать.
Напоминает схему с LUKS, только у вас есть дополнительный слой с RSA ключом.
Он добавлен для возможности подписи содержимого и как дополнительный шаг для замедления перебора всей схемы, или есть еще какие-то причины?BarakAdama Автор
13.12.2017 08:05А ещё дополнительный слой с RSA позволяет менять мастер-пароль без расшифровки хранилища, т.е. без замены ключа шифрования.
MrFrizzy
13.12.2017 13:12Не, шифруя ключ шифрования напрямую мастер паролем без прослойки rsa тоже можно менять мастер пароль или иметь множество разных мастер паролей, как это сделано в LUKS контейнере
klirichek
13.12.2017 06:35А можно вместе или вместо повседневного мастер-пароля что-нибудь другое, например google authentificator?
LoRain
13.12.2017 07:50Так или иначе есть огромное множество нативных программ, в которых требуется аутентификация. Браузеры безусловно забирают львиную долю авторизаций на среднестатистическом компьютере, однако даже в самом браузере сначала нужно залогиниться :) На мой взгляд, нативное приложение с расширением выглядело бы более функционально.
Что касается использования пароля в ключе для декрипта — я для себя не увидел убедительной аргументации против этого. Всегда можно взять часть пароля, скомбинировать его с уникальным Hardware ID, добавить различных смещений и прочих ништяков, и в итоге получить смесь которая вполне будет сравнима со случайной генерацией. Подобные же методы позволяют применить многократную криптографию, например: сначала дешифруем файл по одной связке, получаем лист с данными закриптованными уже совсем другой связкой, при запросе декриптим и выдаем. Это должно не только значительно усложнить получение доступов злоумышленникам, но и дополнительно обезопасит данные привязав их к машине пользователя, т.е. даже если пароль будет скомпрометирован здесь будет дополнительная ступень защиты.
Примерно подобный метод защиты я применил в менеджере паролей для личного пользования: github.com/Hackness/KeepYourPassword
А вопрос с переносимостью данных для пользователя можно будет решить например отдельной системой переноса по одноразовому суперпаролю, rsa или подобным.
P.S. Ну и, конечно, истинный параноик будет хранить важные данные только в том, что сам может скомпилировать :)
VisborN
13.12.2017 07:50Вы так заботитесь о простых пользователях, но не хотите переводить общие термины на их язык. Обычный пользователь быстрее поймёт для чего нужен общий пароль чем мастер-пароль. Тем более не все знают перевод слова мастер.
BarakAdama Автор
13.12.2017 07:52Слово «мастер» уже давно не надо переводить :) Любой термина без контекста ничего не значит. Турбо. Протект. Режим чтения. Описание, обучение и практика решают эту задачу.
migs911
13.12.2017 15:29Можно сделать термин «мастер-пароль» tooltip'ом, при наведении на который будет всплывающая подсказка про то, что это такое. Коллега здесь прав, те 90% людей, на которые вы ориентируетесь, могут не понять, что же это за мастер-пароль.
pavel_pimenov
13.12.2017 12:21а 1Password к вашему браузера как-то можно прикрутить?
BarakAdama Автор
13.12.2017 12:48Как именно? На iOS он поддерживается в Браузере (в меню «Поделиться» найти можно).
pavel_pimenov
13.12.2017 13:12У меня windows + 1Password 4.6.2.626
но я не нашел 1Password расширение для яндекс браузера
через меню в поиске ввел 1Password — находит что-то другое
yadi.sk/i/grc6lAgm3QaEV3
вероятно поиск расширений отрезает первую цифру и ищет слово password :-(
кстати поиск ведет зачем-то на оперу addons.opera.com/ru/search/?query=1password
а опера ведь давно того…
BarakAdama Автор
13.12.2017 13:41+1Так мы и Chrome Web Store прекрасно поддерживаем. Оттуда можно установить.
kafeman
13.12.2017 13:04Как ни странно, но только 1% пользователей браузера используют специализированные расширения для хранения паролей (LastPass, KeePass, 1Password, ...)
Напомним, что те же 1Password, KeePass и LastPass даже в сумме используют не более процента пользователей
Это вы исходя из количества установок расширений для браузера такой вывод делаете? Или Яндекс.Браузер отправляет в Яндекс информацию о том, какими программами кроме их браузера пользуется пользователь?BarakAdama Автор
13.12.2017 13:32Программы на компьютере искать не нужно. Речь про расширения. Мы знаем, какие расширения работают в Яндекс.Браузере. ID расширений и количество установленных копий.
pavel_pimenov
13.12.2017 13:37можно узнать ID (url) расширения 1Password?
BarakAdama Автор
13.12.2017 13:46+1Выше ответил. Из Chrome Web Store можно установить хоть обычное 1Password, хоть новое 1Password X.
pavel_pimenov
13.12.2017 13:55Спасибо. круто! работает!
а почему поиск расширений из яндекс.браузера ведет на левый сайт от opera.com?BarakAdama Автор
13.12.2017 14:35Но это не левый сайт. Мы официально поддерживаем Opera Addons и их формат расширений NEX. Даже доработки с их стороны были.
pavel_pimenov
13.12.2017 14:45хм ок, ну тогда можно при поиске расширений из я.браузер искать сразу в 2-х местах. в opera и Chrome Web Store?
kafeman
13.12.2017 14:38Мы знаем, какие расширения работают в Яндекс.Браузере.
Тогда на основании чего вы делаете вывод:Напомним, что те же 1Password, KeePass и LastPass даже в сумме используют не более процента пользователей
Цифр у меня, конечно, нет, но я и люди из моего окружения используем KeePass(X) без установки каких-то расширений. Экстраполируя получается, что далеко не один 1%, а гораздо больше?BarakAdama Автор
13.12.2017 14:57Речь только про браузерные расширения. Самым популярным решением является LastPass. Сильно сомневаюсь, что отдельный KeePass сопоставим с ним. Подобные инструменты используют только очень опытные пользователи, а их очень мало.
migs911
13.12.2017 13:33Функционал, безусловно полезный, особенно для обычных пользователей.
Однако, у популярных решений есть одно преимущество:
они подходят для хранения всех видов паролей, а не только паролей к сайту.
Вопрос, как хранить пароль к какой-нибудь программе, запускаемой локально на компе? Как вводить пароль от приложений на телефоне? У того же KeePass в версии для Android есть своя клавиатура. Да, это далеко не самый удобный вариант, но открывать браузер (а это довольно тяжёлое приложение), в нём открывать менеджер паролей и ctrl+c — ctrl+v из него в приложение, этот вариант будет ещё хуже.
Напрашивается решение «отпочковать» менеджер паролей в отдельную программу, у которой будет тесная интеграция с яндекс.браузером. Или интегрировать его в яндекс.клавиатуру, на крайняк. Планируется как-то решать этот вопрос в будущем?
А ещё вопрос, на который я не нашёл ответа: что делать, если от одного и того же сайта надо хранить несколько паролей?BarakAdama Автор
13.12.2017 13:37Вопрос, как хранить пароль к какой-нибудь программе, запускаемой локально на компе?
Да, есть идея добавить и другие типы данных. Посмотрим на спрос.
Как вводить пароль от приложений на телефоне?
При желании это можно поддержать. Чтобы Браузер вызывался из других приложений для заполнения форм. Как сейчас работают сторонние решения. Опять же точные планы потом станут понятны.
А ещё вопрос, на который я не нашёл ответа: что делать, если от одного и того же сайта надо хранить несколько паролей?
Никаких проблем с разными учётками для одного сайта у нас нет :)
sergey-b
13.12.2017 22:59Отличные новости. Большое спасибо. Я уже, наверное, замучил поддержку Яндекса своими жалобами на убогость парольного менеджера.
Вот, что я хотел бы видеть в парольном менеджере своего браузера.
- Возможность сохранение текстового комментария
- Возможность завести запись вручную. Это вот для меня самая киллер-фича
- Возможность завести новую запись, скопировав данные из существующей записи
- Время создания записи
- Время последнего изменения пароля
- Время последнего использования пароля
- Счетчик количества случаев использования пароля
- Экспорт/импорт в простом текстовом виде
- Массовое редактирование
Решение о том, когда можно и нужно ли подставлять пароль, должен принимать пользователь, а не браузер. Сейчас у меня дома есть несколько IoT девайсов с веб-управлением, защищенных самоподписанными сертификатами. Очень раздражает, что Яндекс.Браузер не дает подставлять туда сохраненные пароли. Зато, если перейти по http — то пожалуйста. Так все соседи скоро будут знать пароль от моего принтера, роутера и телевизора.
И что еще важно, браузер должен хранить не только пароли, но и сертификаты. Хранилище сертификатов Windows — это проходной двор, куда кладут всякий мусор все, кому не лень. Хранить там доверенные сертификаты или личные сертификаты с приватными ключами крайне опасно. А значит, нужно их держать в профиле браузера, как это делает Firefox. С сертификатами чуть посложнее. Нужно иметь возможность делать с сертификатами все то же самое, что и с паролями, и, сверх того, указывать, на каких доменах их можно использовать.
Пошел устанавливать бету.sergey-b
13.12.2017 23:18И еще нужна возможность вручную заблокировать/разблокировать пароли. Простой кнопочкой в тулбаре.
inkelyad
14.12.2017 10:33Не могли бы вы еще за скооперироваться с вашими коллегами, занимающимися лингвистикой и создать (и лучше — отдельным приложением) генератор длинных, случайных, но грамматически правильных русскоязычных парольных фраз? Грамматическая правильность, конечно, снижает энтропию, но это лечится удлинением фразы. Такой генератор, похоже, является единственным способ добиться запоминаемости и надежности этого самого мастер-пароля.
BarakAdama Автор
14.12.2017 10:33Русскоязычные пароли? В смысле, кириллица? С ними же будут проблемы на сайтах.
sergey-b
14.12.2017 15:14Кстати, а мастер-пароль русскоязычный можно использовать?
inkelyad
14.12.2017 16:15На сайта даже просто длинные парольные фразы часто проблемы создают. Так что не для сайтов, а на сам менеджер паролей. Впрочем, можно делать транслитерацию латиницей, но у нее столько вариантов, что слова для генерации фраз нужно будут долго и старательно подбирать. Чтобы пользователи не спотыкались каждый раз, вспоминая, какой именно вариант при задании пароля был использован.
Akr0n
15.12.2017 08:51Насколько на самом деле случаен «случайный» ключ, которым вы шифруете основное хранилище? Какие-то данные из активности пользователя подмешиваются при генерации? В противном случае все упрется в уязвимости генератора псевднослучайных чисел системы. Как быть уверенным пользователю, что он реально надежен, ведь его выбирают за меня и даже не показывают?
brun4eg
15.12.2017 12:11+1Мы используем системный генератор случайных чисел, но мысль про подмешивание пользовательских данных мне понятна и нравится. Посмотрим, может быть добавим.
Что касается уверенности в ключе: если вы настроены серьёзно и переживаете за наши алгоритмы, можно открыть через SQLite базу Ya Login Data и
создать свои ключи рукамиа) сгенерировать случайный 256 битный ключ
б) сгенерировать пару ключей RSA
в) посолить и похешировать желаемый мастер-пароль
г) поставить хеш в качестве passphrase на ключ
д) записать всё это в базуAkr0n
15.12.2017 12:47Достаточно было бы подмешивать движения мыши в момент первоначальной настройки, а ключ визуализировать, например, в виде цветной матрицы. Сразу будет видно, что от малейшего движения мыши картинка полностью меняется. Но это, наверное, слишком по-гиковски для аудитории браузера :)
KoToSveen
15.12.2017 09:43Слава великому Яндексу! Года два назад писал им об этом.
Отсутствие мастер-пароля (как у Огнелиса), это единственное, что мешало мне начать пользоваться Яндекс.Браузером.
MobyDick
Отдельное приложение будет? Интеграция с генераторами одноразовыми паролями?
BarakAdama Автор
Сейчас мы тестируем решение в браузере. От результатов и спроса зависят дальнейшие планы.
NeuroHunter
А что по поводу Я.Ключа для мобильных телефонов? Будет какая-нибудь интеграция, или Ключ по-прежнему останется standalone продуктом для безопасного логина?
BarakAdama Автор
Прямо сейчас Ключ мы не трогаем. Вокруг него разные интересные идеи, нужно подумать.
inkelyad
Кстати. Давным-давно было обещано, что алгоритм яндекс-ключа будет опубликован. Это произошло?
niksamokhvalov
Поддерживаю. Хранить пароли просто в браузере не серьёзно, это будет актуально только для неопытных пользователей. Для более продвинутых важно иметь возможность в любой момент перейти на другой браузер, а так же хранить пароли, связанные не только с сайтами и веб-сервисами.
И тем не менее, это хорошая новость. Именно за такие фичи я когда-то установил родителям Яндекс-браузер, а не Хром.