«Яндекс» ввел защиту аккаунтов без использования паролей

«Яндекс» ввел защиту аккаунтов без использования паролей

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

Для использования новой функции следует включить двухфакторную аутентификацию в настройках «Яндекс.Паспорта» и установить приложение «Яндекс.Ключ». Для входа в учетную запись пользователю необходимо считать через приложение QR-код, который доступен на главной странице поисковика, в «Яндекс.Почте» или «Яндекс.Паспорте».

В случае невозможности считать QR-код, например если не работает камера смартфона или нет доступа к интернету, приложение создает одноразовый буквенный пароль, действующий всего 30 секунд, сообщает lenta.ru.

Одноразовый пароль в приложении «Яндекс.Ключ» формируется с учетом четырехзначного ПИН-кода, задаваемого пользователем. Без этого ПИН-кода невозможно войти в аккаунт, что обеспечивает безопасность при утере гаджета. Кроме того, владельцы смартфонов и планшетов Apple с Touch ID вместо ПИН-кода могут использовать сканер отпечатка пальца.

При смене устройства, пользователь должен будет повторить процедуру подключения со скачиванием «Яндекс.Ключа» и использованием ПИН-кода. В случае если хакер захочет имитировать покупку нового устройства и введет чужой логин, ему потребуется подобрать цифровой пароль. Однако при обнаружении подозрительной активности, когда «кто-то со смартфона пользователя начинает многократно логиниться, перебирая разные ПИН-коды, аккаунт будет заблокирован и может быть восстановлен только по сложной процедуре», — уточнили «Ленте.ру» в пресс-службе.

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

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

Telegram MCP-сервер fast-mcp-telegram пустил атакующих к телеграм-сессии

В fast-mcp-telegram нашли критическую уязвимость под идентификатором CVE-2026-52830: хотели защититься токенами bearer, а в итоге превратили токен в путь к файлу. В результате атакующий может получить доступ к MCP-сессии Telegram по HTTP без валидного закрытого токена.

Fast-mcp-telegram — это MCP-сервер, который подключает телеграм-аккаунты к ИИ-ассистентам и HTTP-клиентам через сессионную модель аутентификации.

В версиях до 0.19.0 включительно проверка токена устроена так: сервер берёт строку из Authorization: Bearer, добавляет к ней .session, склеивает с директорией сессий и проверяет, существует ли такой файл.

Проблема в том, что токен не нормализуется как безопасный идентификатор. Код запрещает некоторые зарезервированные имена, например telegram, но не блокирует слеши, «..», абсолютные пути и другие конструкции.

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

В типичной конфигурации дефолтная сессия лежит в файле ~/.config/fast-mcp-telegram/telegram.session. Прямой токен telegram отклоняется, но обходной вариант вроде ../fast-mcp-telegram/telegram может схлопнуться файловой системой в тот же самый файл. Если файл существует, сервер принимает такой токен и аутентифицирует атакующего как дефолтный телеграм-аккаунт.

После этого злоумышленник может читать и отправлять сообщения, вызывать MTProto API и использовать доступные инструменты, привязанные к этой сессии. Защита на уровне префиксов инструментов тут уже не спасает: она срабатывает после аутентификации, а дверь к аккаунту к тому моменту уже открыта.

Уязвимость затрагивает fast-mcp-telegram до версии 0.19.0 включительно. В версии 0.19.1 разработчики ужесточили проверку и начали обращаться с bearer-токенами как с непрозрачными идентификаторами, а не как с кусками пути.

Администраторам рекомендуют срочно обновиться, ротировать дефолтные и старые session-файлы, а также проверить логи на подозрительные bearer-значения со слешами и «…».

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