Signal исправил 6-летний баг хранения ключей шифрования в открытом тексте

Signal исправил 6-летний баг хранения ключей шифрования в открытом тексте

Signal исправил 6-летний баг хранения ключей шифрования в открытом тексте

Разработчики мессенджера Signal решили наконец повысить безопасность версии приложения для десктопов. В частности, девелоперы поменяли способ хранения ключей шифрования, за что их критиковали с 2018 года.

Ранее при установке Signal на Windows- или macOS-устройства мессенджер создавал зашифрованную SQLite-базу для хранения сообщений пользователя. Эта БД шифровалась с помощью ключа, сгенерированного программой, без пользовательского ввода.

Чтобы программа могла расшифровывать базу и использовать её для хранения данных, нужен ключ шифрования. В случае с логикой работы Signal ключ хранился в виде простого текста в локальном файле по пути «%AppData%\Signal\config.json» в Windows и «~/Library/Application Support/Signal/config.json» — в macOS.

Источник: BleepingComputer

 

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

Сначала Signal всячески пытался преуменьшать значение этого бага. Например, один из разработчиков писал:

«Ключ от БД и не задумывался как нечто закрытое. Шифрование при хранении никогда не упоминалось в качестве функциональности десктопной версии Signal».

Однако девелоперы, судя по всему, пересмотрели своё отношение после одного из твитов Илона Маска, в котором миллиардер указывал на уязвимость в мессенджере.

Своё недоумение также высказывали исследователи в области кибербезопасности — например, Томми Миск.

Теперь, по словам разработчиков, они имплементировали поддержку Electron safeStorage. Нововведение скоро должно появиться в бета-версии Signal.

Android разрешит переносить passkey между менеджерами паролей

Google приблизилась к тому, чтобы наконец-то разрешить пользователям Android переносить passkey между разными менеджерами паролей. Те самые ключи доступа, которые должны были заменить пароли и сделать жизнь проще, но заодно умудрились частично запереть пользователей внутри экосистем.

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

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

Google работает над решением этой проблемы с прошлого года. Apple уже успела внедрить перенос passkey в сторонние менеджеры в iOS 26 и macOS 26, а вот на Android функция пока официально не заработала.

Теперь стало известно, что корпорация добра уже тестирует интерфейс переноса passkey между приложениями. В Google Password Manager появились скрытые опции «Импортировать пароли и ключи доступа» и «Экспортировать пароли и ключи доступа» вместо обычных пунктов импорта и экспорта паролей.

 

 

Согласно тестам Android Authority, функцию удалось активировать и частично проверить. При импорте Google Password Manager предлагает выбрать менеджер паролей, где уже хранятся passkey. После этого пользователь переходит в выбранное приложение, например Bitwarden, и может перенести пароли, passkey и другие сохранённые данные в менеджер Google.

С экспортом всё немного хитрее: отдельной кнопки «отправить passkey в другое приложение» пока нет. Вместо этого система должна предлагать перенос, когда пользователь открывает другой поддерживаемый менеджер паролей.

Работать всё это будет через Credential Exchange Protocol — механизм обмена учётными данными между менеджерами паролей. Его поддерживают крупные игроки вроде Google, Apple и Samsung, но на старте функция может быть доступна не для всех приложений.

RSS: Новости на портале Anti-Malware.ru