Комментарии 69
Очень тяжело читаются не общепринятые аббревиатуры, которые экономят всего десяток букв. GP (батарейки такие), ЯД (выпивают который?), СЧ (средние частоты?).
Прочитал статью трижды, но по-прежнему хочется приложить картинку «няня, я у них поел».
..., не спасет и вместо «pin» «password» local code Telegram.
можно же написать так (получится даже короче):
..., не спасет и использование local code вместо pin.
Приложение не должно заниматься безопасностью оконечного устройства, потому что это не его задача, и задача эта решается глобально, а не «per app».
Если пользователь постоянно «сидит под рутом» или выдаёт права суперпользователя не глядя, то пользователь сам себе злобный буратино.
Прокоментируйте пожалуйста, почему keepass (не подвержен аналогичным атака)?
Отвечу сюда, на Ваш 2й комент:
Учетку, которую распарсил с virtualbox, не с мтк.
Если Вы считаете, что китай.телефоны дно, это не означает, что ими ни кто не пользуется.
Впрочем, как и с получением root-прав. Образы на virbox идут с root. Кол-во root устройств в этом мире ни единицы.
Спасибо, что не забываете комментировать все мои статьи.
Спасибо, что не забываете комментировать все мои статьи.Я прокомментировал уже сотни статей за годы нахождения на ресурсе, а вас помню как автора предыдущей статьи про «уязвимость», которую я таковой бы не счёл. Мы где-то ещё пересекались?
Если Вы считаете, что китай.телефоны дно, это не означает, что ими ни кто не пользуется.Дверными крючками вместо замков тоже кто-то пользуется, делает ли это такой запор надёжным? Использование таких ненадёжных устройств свидетельствует о том, что пользователь относится к своей безопасности беспечно, вероятно, она ему не требуется. Например, лверь сортира на даче у меня закрыта именно на крючок, сортиру больше и не нужно.
Прокоментируйте пожалуйста, почему keepass (не подвержен аналогичным атака)?
For example, consider the following very simple spyware specialized for KeePass: an application that waits for KeePass to be started, then hides the started application and imitates KeePass itself. All interactions (like entering a password for decrypting the configuration, etc.) can be simulated. The only way to discover this spyware is to use a program that the spyware does not know about or cannot manipulate (secure desktop); in any case it cannot be KeePass.
Вообще попытка защитить информацию с помощью программы исполняемой в недоверенной среде, аналогична попытке защитить секретную документацию с помощью установки супер-мега-надёжного замка на сейф, у которого не хватает одной из стен…
Тогда и local code не нужен — все данные храним в plain text.
Но local code есть, зачем?
Какую конкретно атаку?
На мой взгляд одно слабое место связано с тем, что TWRP принципиально не хочет реализовывать защиту от пароля, по причине того, что защищаться от физического доступа к устройству бессмысленно. Я с этим не согласен: в случае если физический доступ был получен временно и незаметно для владельца (что не является фантастикой — достаточно ненадолго отойти от стола, на котором лежит телефон, и мы все это делаем), то отсутствие пароля на TWRP позволит незаметно добавить в прошивку малварь, которая дождётся загрузки телефона и расшифровки раздела с данными, после чего будет иметь полный доступ ко всему. Ключевое слово здесь именно "незаметно", потому что сделать это можно в любом случае (переписав оригинальную TWRP своей версией без пароля), но если бы TWRP хранила пароль на своём разделе, то после подмены TWRP он был бы утерян, и юзер имел бы шанс узнать, что с телефоном что-то сделали — по факту того, что слетел пароль TWRP.
Какая-то слишком сложная теория заговора. Успеть за "ненадолго" ребутнуть телефон в рекавери, что-то там установить, загрузить обратно, да ещё всё это "незаметно". Разве можно не заметить, что телефон ребутался?
Если раздел данных зашифрован — определённо, это заметят. Но проблема в том, что телефон изредка сам перегружается — насколько часто такое случается зависит от телефона и прошивки, но обычно это более-менее штатная ситуация, хотя и редкая. Так что перезагрузка это ещё не признак того, что на телефон что-то устанавливали.
Вы не указали Ваш Гаджет. После того, как вы проведете шифрование устройства (настройки-безопасность-зашифровать данные). TWRP будет (должен) требовать этот пароль/pin, иначе он не сможет смонтировать раздел /data/data. И все отлично, НО! шифрование реализуется не за счет прошивки (в моем случае RR), в вашем LineageOS, а за счет secro.img. После повторной прошивки именно этого образа пароль благополучно уходит и TWRP монтирует раздел без запроса пароля и данные на ладони (ни чего не удаляется). Но это с моим гаджетом такой фоку проворачивается, с вашим возможно нет.
Зайдите на профильный ресурс 4pda, здесь Вам не помогут.
Рут — это же как раз про уязвимость среды.
Ну что за дичь? Наличие рута не делает систему более уязвимой, нельзя настолько верить маркетинговому FUD. Рут в системе есть всегда, разница только в том, кто управляет доступом к выполнению приложений с рут-правами: в большинстве прошивок это производитель телефона, а в редких исключениях либо после ручного получения рута это владелец телефона.
Возможности сторонних вредоносных программ по получению рута в этих случаях отличаются только одним: в последнем случае юзер может вручную дать разрешение такой программе работать под рутом — если юзер плохо понимает, что делает, либо ему подсунули протрояненное полезное приложение, которому действительно нужен рут.
При этом надо отметить, что, если юзер понимает, что делает, то шансы уговорить его дать рута приложению "фонарик" или подсунуть протрояненный apk на стороннем сайте пренебрежимо малы. Зато наличие рута даёт юзеру возможность поставить AFWall+, XPrivacyLua, AdAway, Titanium Backup… плюс удалить/отключить malware/spyware/adware уже встроенные производителем в прошивку, и получить значительно более защищённую систему.
Их позиция, как я понимаю, в том, что в шифровании данных на стороне приложения, если приложение находится в уязвимой среде, просто нет смысла.
dartraiden Приложение не должно заниматься безопасностью оконечного устройства, потому что это не его задача, и задача эта решается глобально, а не «per app».
Это не совсем верно. Абсолютной защиты не бывает, и даже в условиях "безопасной загрузки", когда рута нет и целостность загружаемой прошивки контролируется на всех этапах от включения телефона криптографическими подписями — всё-равно есть масса способов получения доступа к данным других приложений (начиная с того, что кейлоггер в прошивку может добавить производитель, например если от него этого требует закон, и заканчивая получением доступа через дыры в безопасности).
Поэтому защита всегда должна быть эшелонированной. Да, в случае телеграм нет смысла как-то дополнительно защищать обычные чаты — они и так доступны неопределённому кругу лиц имеющих доступ к серверам телеграм или способным принудить кого-то из них выдать данные. Но секретные чаты это другое дело, поэтому вполне разумно дать юзеру возможность шифровать их паролем, без знания которого даже рут-доступ к телефону не позволит получить к ним доступ. Да, имея рут можно поставить кейлоггер, и потом дождаться пока юзер введёт пароль сам — но это делает атаку более сложной, медленной, потенциально более заметной для пользователя… с тем же успехом можно сказать, что без рута и кейлоггера пароль из юзера можно получить с помощью паяльника, поэтому в паролях вообще нет никакого смысла.
На мой взгляд, нежелание Дурова заниматься защитой секретных чатов вызвано иными причинами — дело вовсе не в том, что из-за рута и потенциальных кейлоггеров нет смысла шифровать секретные чаты именно паролем юзера, а в том, что Дурову вообще секретные чаты не очень-то нужны, и безопасность переписки юзеров у него явно не в приоритете. Это наглядно доказывают факты:
- отсутствие поддержки секретных чатов в десктопной версии
- секретные чаты не используются по умолчанию
- отсутствие синхронизации секретных чатов, хотя есть алгоритмы позволяющие это делать без ущерба для безопасности
- отсутствие надёжного и явного контроля отпечатков (fingerprint) обеих сторон в секретном чате
- отсутствие поддержки групповых секретных чатов
В общем и целом это доказывает, что приоритетом для телеграма является удобство и простота использования (что вполне логично для массового мессенджера), а "безопасность" используется исключительно для раскрутки, как маркетинговый инструмент, и поэтому реализована в самом минимальном объёме.
Я не увидел в Вашем комментарии тех самых "объективных причин", ни одной. Синхронизировать секретные чаты возможно, и это реализовано в Signal, WhatsApp, Wire, Jabber (OMEMO), Matrix, … Групповые секретные чаты тоже возможны, и уже реализованы в Signal, Viber, WhatsApp, Briar, Wire, Jabber, Matrix, Treema… Насколько секретные чаты "в большей безопасности" на мобильном устройстве хорошо описано в статье.
Но, даже если допустить, что безопасность логов секретных чатов действительно очень важна и только залоченное и нерутованное мобильное устройство может обеспечить требуемый уровень безопасности (хотя это не так), остаётся куча вопросов:
- почему тогда секретные чаты работают на мобильных устройствах с разблокированным загрузчиком и/или рутованных? разве они не должны панически самоуничтожиться в этих условиях, ведь они ничем по защищённости не отличаются от десктопа?
- невозможность защитить логи секретных чатов не имеет значения, если юзер выбрал "не сохранять лог секретных чатов" в настройках (кстати, а такая настройка есть? должна быть, если, конечно, заботиться о безопасности), а значит десктопная версия могла бы работать хотя бы исключительно в этом режиме
- невозможность защитить логи не отменяет того факта, что намного важнее защищать сообщения при передаче по сети, и это стоит делать в любом случае — сеть атакована MITM практически гарантированно всегда и везде (СОРМ, etc.), и даже в случае шифрования до серверов телеграм вынудить их по суду или атаковать намного проще, чем получить доступ к дискам компов двух конкретных людей общавшихся в чате
Не буду спорить со сказанным в отношении WhatsApp и iMessage, но помимо них есть мессенджеры, которые сумели реализовать все эти фичи безопасным способом: Signal, Wire, Jabber, Matrix — все они используют Signal Protocol или его вариации. Упомянутые в Вашей цитате "технические сложности" телеграм вызваны тем, что он использует другой протокол, а не тем, что эти фичи невозможно реализовать безопасно.
На всякий случай уточню: необходимость модифицировать текущий протокол или заменить его на Signal Protocol не является «объективной причиной» почему данный функционал реализовать нельзя — это просто очередная фича, которую надо добавить.
А вот условия, необходимые для получения рута, такие как необходимость разблокировать и невозможность заблокировать загрузчик (из-за ущербной реализации защиты загрузки, позволяющей загружать только boot.img подписанные вендором), необходимость (на самом деле нет) установки TWRP, что делает незашифрованные устройства и устройства с некачественным шифрованием уязвимыми.
Но тем не менее это не оправдывает дурацкую уязвимость и «маркетинговый» подход к безопасности
Рут получают не только так. В некоторых прошивках он есть из коробки (и плохо, что это пока очень редко встречается). Иногда его получают взломом прошивки через уязвимость (что тоже плохо, т.к. наличие такой уязвимости позволяет получить рута и малвари).
Но суровая правда жизни в том, что рут нужен для контроля над своим устройством, но в наше время этого недостаточно — прошивки от производителей часто содержат spyware/adware, а то и малварь, поэтому замена родной прошивки на что-нибудь вроде LineageOS превращается в банальную гигиену, без которой пользоваться телефоном крайне нежелательно. И для этого, безусловно, загрузчик необходимо разблокировать.
- Запускаю Telegram на Android 6, получаю запрос на ввод пароля/отпечаток. Прикладываю отпечаток пальца, и telegram разблокировался, доступна вся переписка СЧ и облако.
- Перезапускаю Telegram, ввожу 31-значный local code, и Telegram также разблокирован.
У вас в двух идущих подряд пунктах Телеграм разблокирован. Путаница какая-то, поправьте и укажите более подробно что происходит в первом и втором случае.
Я запускаю Телеграм, разблокировал отпечатком, не зная 31-значный пароль.
Повторно открываю Телеграм (эту же учетку) и ввожу (вместо отпечатка) 31-значный пароль (показать, что учетка именно «та» с VirtualBox").
Разобрался в том, что вы имели в виду. Читать вас не просто.
Использовали ли вы отпечаток пальца для этого телеграм-аккаунта ранее, до запуска Телеграма в VirtualBox? Использовали ли вы в VitualBox учетную запись, созданную в другом Android-устройстве, в котором применяли авторизацию по отпечатку пальца?
В обоих случая — нет.
Это опять же видно на видео (например, установка telegram из GP)
Если имеет значение, то учетку на vir.box вообще создал сегодня на новую симку.
Если, все так как вы утверждаете и я вас правильно понял, то это свидетельствует о том, что ключи для end-to-end шифрования хранятся на сервере Телеграма. В виду запутанности изложения и некоторой сумбурности, требуется независимое подтверждение.
Я посмотрел видео и выдвинул три гипотезы
1) ключи для end-to-end шифрования хранятся на сервере Телеграма
2) ключ на устройстве шифруется таким образом что устройству уже известно как расшифровать этот ключ. А пароль/пин/опечаток — лишь «для пыли в глаза»
3) ne555 нас пытается обмануть (ничего личного)
4) (дополнение 2) ключи хранятся на устройстве, но установка пароля/пин блокирует лишь интерфейс, и не влияет на шифрование ключей (то есть не происходит их шифрование этим паролем/пином для дополнительной надежности(?))
А первую гипотезу, наверное, можно проверить, проделав все то же самое без интернета на мобильном устройстве?
Верно, и без инета, учетка откроется со всеми СЧ.
Я специально создал учетку в Телеграм, написал важные сообщения (готовил небольшой конкурс) Планировал после бэкапа ее уничтожить (знал, что она откроется потом в офлайне с нужными сообщениями). А далее обнаружил "это" и немного покопал.
Ни чего личного
В чем и где я пытаюсь Вас обмануть?
Я приложил статью (+ссылаюсь на первую свою статью для полноты картины)
Все на столько подробно, что Вы просто берете и проверяете.
На VirtualBox нет устр. отпечатка пальца, учетка создана впервые сразу на вирт.машине. Учетка разворачивается/открывается на другом устройстве "чужим" отпечатком. (В статье задействовано 2учетки и 3 девайса).
Я специально указал и тестил доп.такие приложения, как Ян.деньги, Сбер, Кипас на аналогичную атаку (у них тоже отпечаток в арсенале).
Я читал первую статью еще в момент выхода и хорошо помню смысл.
Учетка разворачивается/открывается на другом устройстве «чужим» отпечатком
Вот это действительно интересно. Так как согласно вот этому
Теперь можно с чистой совестью отправить его на вход в decode(), получить пин-код, сымитировать его ввод и показать пользователю его данные.
Но шифрование чего-либо при помощи отпечатка должно быть уникальным на каждом устройстве. И уж тем более если не было манипуляции с API для сенсоров, то и зашифровать ничего нельзя, чтобы потом расшифровать. Или может быть я неправ? (в рамках апи для андроид разумеется)
А проблема только в том, что данные приложения можно перенести.
2) Т.е. не шифруется вовсе.
4) Если это реализовано таким образом, то встает вопрос, где еще Телеграм умышленно понижает безопасность. Для девайсов без встроенных чипов защиты использование секретных чатов должно быть попросту недоступно. Как вариант собеседнику с более защищенным устройством должно показываться предупреждение о недостаточной надежности канала.
Верно, Телеграм уязвим к атаке "хищения ключей"
Пин-код, или пароль на открытие приложения — пыль в глаза.
А ps в статье- меня сильно воодушевил на эксперименты с другими гаджетами (попытка обойти шифрование устройств).
Возможно данной проблеме (проблеме шифрования устройства) подвержены и другие гаджеты
Да, шифрование на китайфонах это давняя и больная тема. На телефонах, построенных на чипах MTK, раньше даже загрузчик не блокировался в принципе, о какой безопасности тут можно говорить?
Но если пользователь покупает себе аппарат, предназначенный для китайского рынка, и, несертифицированный Google («ну а что, так дешевле, что я дурак что ли переплачивать за Global-версию, я всех облману и возьму дешевле, какой я молодец»), где шифрование реализовано так, что лучше бы его не было вовсе, то пользователь сам дурак.
И многое Вы знаете о сертификации Гугл?
А о свободных прошивках?
Ваши посты "однотипны" и к первой части и ко второй
И многое Вы знаете о сертификации Гугл?Например.
А о свободных прошивках?О том, что установка свободных прошивок, увы, требует разблокировку загрузчика?
Ваши посты «однотипны» и к первой части и ко второйНе потому ли, что обе части основываются на «имея права суперпользователя можно поиметь приложение»? Впрочем, я постараюсь не комментировать ваши посты на эту тему впредь (вот теперь мне как раз придётся обращать внимание на автора, чтобы исполнить обещание).
Телеграмм позиционируется как защищенный месенджер, и у него нет никаких требований по железу. Значит, это уязвимость, а не "пользователь сам дурак".
PS автор, со всем уважением, не торопитесь пожалуйста, уделите ещё немного времени для вычитки и написания слов целиком. Все эти ЯД, устр. и прочие несколько портят статью и затрудняют чтение.
Стиль изложения, конечно, сумбурный. Для тех, кто ничего не понял: автор утверждает, что версия Телеграм под Андроид не шифрует данные (переписку, ключи авторизации) на диске (или шифрует, но без использования пароля), а пароль (local password) используется только для блокировки интерфейса приложения и может быть заменен на ввод отпечатка пальца.
Таким образом, мы якобы можем скопировать конфиги Телеграм вместе с авторизационными ключами на другое устройство и войти через него, используя отпечаток пальца вместо пароля. Вообще, если это правда и авторизационный ключ не зашифрован, то нам даже копировать ничего не надо — надо лишь достать файл конфига и извлечь ключ.
Это, правда, противоречит методике взлома, описанной в прошлой статье автора, где утверждалось, что конфиг Телеграма зашифрован с помощью пин-кода. Естественно, если конфиг зашифрован пин-кодом или паролем, то перенос его на другое устройство не позволит извлечь данные.
В конце автор добавил, что по его наблюдениям, некоторые телефоны Android не шифруют данные на диске при выборе соответствующих настроек, а лишь создают видимость шифрования. Это вполне возможно: если вы покупаете несертифицированный Гуглом телефон, гарантий вам дать никто не может.
Также, в видео есть интересные моменты:
1) автор не смог с первого раза задать пароль, отменил его ввод и поставил его со второй попытки. Может быть, проблема в этом, что ошибка установки пароля что-то сломала в приложении и не позволила зашифровать данные?
2) автор сначала ведет переписку, а только потом ставит local password. Возможно, конфиги или данные по какой-то причине не успели зашифроваться. Интересно, а если поставить local password, перезагрузить телефон и потом вести переписку — этот метод продолжит работать?
3) автор после разблокировки телеграма отпечатком на втором устройстве не продемонстрировал, что можно, например, нажать на чат и увидеть сообщения в нем. Он лишь на пару секунд показал стартовый экран программы. Вы можете показать работоспособность Телеграма после разблокировки пальцем и возможность читать переписку и отправлять сообщения? Возможно, на первом устройстве просто сохранился незашифрованный скриншот интерфейса Телеграм и после переноса на второе устройство и разблокировки он показался на экране? Или, например, при изготовлении бекапа состояние памяти процесса Телеграм было сдамплено и восстановлено на втором устройстве? Автор, вы можете проверить/продемонстрировать, какие именно данные содержатся в перенесенном бекапе? Что, если перезагрузить первый телефон и сделать бекап после перезагрузки?
Было бы здорово исключить эти гипотезы.
Естественно, скопировать данные можно только если диск не зашифрован, или же если телефон разблокирован или если есть возможность обойти разблокировку. Если телефон зашифрован и выключен, скопировать данные нельзя.
В FAQ написано:
… [But please remember that we cannot protect you from] any other people that get physical or root access to your phones or computers running Telegram.
Это очевидно: если у вас есть рутовый доступ, вы можете изучать экран, перехватывать нажатия клавиш, содержимое памяти процесса Телеграм.
Q: How are secret chats different?
All secret chats in Telegram are device-specific and are not part of the Telegram cloud. This means you can only access messages in a secret chat from their device of origin. They are safe for as long as your device is safe in your pocket.
Where did my Secret Chat messages go?
Secret Chats are established between the two devices they were created on. This means that all those messages are not available in the cloud and cannot be accessed on other devices.
Moreover, Secret Chats are also tied to your current login session on the device. If you log out and in again, you will lose all your Secret Chats.
Здесь по моему написано, что секретные чаты привязаны к ключу авторизации. Если это так, то бекап/восстановление на другом устройстве может помочь в них зайти (хоть там и написано, что доступ к ним есть только на одном девайсе).
1) Да, со второго раза пароль поставил (31знак, где-то ошибся с первой попытки) пароль был — 31знак.
2) Успело (после установки local code, перезапускаю приложение и требовался ввод пароля (на вирт.машине, см.видео) Я до снятия видоса, естественно несколько раз это проделал с простым паролем, сравнивая поведение с эталоном безопасности «keepassdroid», например.
3) Да, могу. Вы посмотрите видео из первой части, там я довольно долго веду переписку из угнанного СЧ.
Документацию FAQ я также приводил в первой статье.
Про «скриншот» вообще забавно. Я вам не предлагаю на веру взять. Попробуйте, повторите и убедитесь сами.
«Статья сумбурная» А сколько статей написали Вы?
Неужели так сложно четко описать эксперимент — гипотеза, алгоритм проверки, результаты, выводы?
«Статья сумбурная» А сколько статей написали Вы?
В свое время написал несколько десятков статей в научных журналах
«Статья сумбурная» А сколько статей написали Вы?
Вам уже несколько человек сказало, что подача материала в статье не очень удачная. Просто примите это к сведению, и, если есть желание, потратьте немного сил чтобы научиться писать лучше — это ценный навык вообще по жизни, пригодится. К такой критике надо относится как к полезной обратной связи, переключаться в режим агрессивной психологической защиты нет ни смысла ни пользы.
потратьте немного сил чтобы научиться писать лучше
Потратьте несколько минут, заглянув в мои статьи, чтобы разубедиться в своих высказываниях.
И подумайте, почему я предоставил таким образом подачу материала.
Режим, который Вы упомянули я не включал, более того, я занят, над тем, с чем работал вчера (не дешифрование), и с чего меня сбила данная проблема в telegram (в комментах я об этом упомянул).
Статья читается тяжело в силу употребления автором специфического стиля повествования и изложенных эмоций (в том числе употребление сокращений и знаков пунктуации). Чтобы читалось легче и было понятнее, заинтересованным лучше перейти по указанной в статье ссылке на предыдущую статью автора, где он как раз с описанием начала его исследования вводит некоторые сокращения. Всё становятся понятнее: с чего началось, откуда сокращения, откуда эмоции и вектор атаки.
Тем кто, жаловался — вы читали статью, вырванную из контекста. (Ага, это типа продолжение и в контексте :) )
Здесь много рассуждений о том, уязвимость это или нет и имеет ли она смысл, если для этого нужен рут. На мой взгляд, — это определенно уязвимость. Когда данные, которые позиционируются как защищенные (по договору публичной оферты оглашается, что это так) и для доступа к ним нужен пароль, становятся доступными без пароля — это уязвимость.
И эта уязвимость состоит в том, что мобильное приложение идентифицирует владельца данных по биометрическим данным на устройстве, что не означает их валидность для предоставления доступа, т.к. изначально шифрование проходило по паролю и на другом устройстве.
Даже допущу, что в качестве ключа приложение просто использует сохраненный SHA1 хэш пароля после того как идентифицирует пользователя по введенному паролю (сравнивает вычисленный хэш) или по другим «системным» параметрам — отпечатку, лицу, жесту, зрачку глаза (чему угодно).
С одной стороны, это удобно для идентификации владельца любым удобным ему средством, с другой — небезопасно и может быть использовано как лазейка третьими лицами или соответствующими органами.
В любом случае, подход к аутентификации «владелец девайса», мне кажется неверным и уязвимым. Владельцев много, девайсов ещё больше, а данные могут мигрировать между ними любым способом по множеству различных причин.
ни одно приложение нельзя назвать безопасным, независимо от того, насколько сильным является шифрование.
Rar приложение (и другие) почему-то может считаться безопасным. Зашифруйте с помощью rar-архиватора все свои секреты, и потеряйте Ваш рутованный телефон. Тот, кто найдет гаджет, ничего с зашифрованными секретами (приложением rar) ни чего не сможет сделать (кроме неэффективной брутфорс атаки).
Как уместно отметили в комментах выше — нельзя настолько верить в маркетинговую чушь!
Вырвал — это значит не добавил это «При таких обстоятельствах»?
Я же ответил «потеряете Ваш РУТОВАННЫЙ девайс»
Не я один сомневаюсь в надежности Telegram, нас много!
21 сентября экс-сотрудник ЦРУ и АНБ Эдвард Сноуден выразил сомнение в надёжности хранения данных в мессенджере Telegram
Winrar «уязвимость», почитайте внимательнее про эти совершенно разные уязвимости: Доступ к данным в Telegram vs разархивирование файлов в любую директорию (которое уже поправили).
Поправят (я надеюсь) и уязвимость с local code. Telegram под шумок один баг уже исправил: подмена знаков «дефис на тире» в Дестктопной версии приложения, сделал он это во время обновления своего приложения по поводу GDRP, а «фича багная» в Десктопе висела 5лет.
И об этом ни где (вообще ни где, и ни кто не писал, что такой баг исправили), кроме самого Telegram в «Служебных сообщениях»: «Мелкие улучшения и исправления».
Read the salt (32 bytes), encrypted data and sha1 of decrypted data from a file.
Compute a PKCS5_PBKDF2_HMAC_SHA1 on the UTF8 (passcode), using the salt, 4000 iterations, keysize of 256 bytes
Use a Telegram-specific KDF to get the AesKey and AesIV (Relatively cheap — bunch of memcpy and 4x sha1)
По результатам видно, что там хранится и брутится SHA-1 хэш, а вот размер ключа 256 байт (но это не делает из SHA-1 SHA-256).
Кроме того, Ваша цитата относится к протоколу передачи сообщений и может не иметь ничего общего с принципами аутентификации для доступа к хранилищу.
Кто писал этот «официальный FAQ» для меня загадка, откровенно говоря, можно было написать, всё что угодно. Если в одном месте используют SHA-1 хэши, протокол передачи тоже попадает под сомнения.
Аналогично, позиция о root-доступе — это субъективное мнение. У меня оно другое. В данном случае, о том, что root снижает надежность предупредили, но сами понадеялись, что это никогда не случится. Как я уже писал, суть в подходе.
Я ссылку приложил «откуда этот faq»… Этот faq охватывает не только Android (бруту «поддаются» GNU/Linux/Windows Десктопные криптостойкие local code приложения).
Но о проблемах еще писали и тут
m.habr.com/ru/post/418535
Про Root у многих своя позиция (я свою выразил в первой статье), и в статье про «Мобильная лаборатория на Android...»
Предупрежден, значит вооружен.
Павел Д. хороший маркетолог, но его брат круче (только из-за этого и уважаю Telegram).
Я – «Маркетинговая чушь, обусловленная нехваткой квалифицированных технических кадров в далёком 2013г.»
Уязвимость в Telegram позволяет обойти пароль local code любой длины