tdata, session string и авторизации: как на самом деле устроен доступ к Telegram-аккаунту

Вся автоматизация Telegram крутится вокруг двух форматов - папок tdata и session string, - но что такое телеграм-сессия на самом деле, почти никто не объясняет. Из этого пробела растут одни и те же потери: ключи, вставленные в онлайн-конвертер; аккаунты, которыми рулят два инструмента одновременно, пока Telegram не убьёт ключ; списки устройств, в которые никто не заглядывает.

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

Авторизация - это ключ, а не логин

Когда вы входите в Telegram на новом устройстве - код из SMS, затем облачный пароль, если он установлен, - клиент и сервер согласуют долгоживущий секрет, ключ авторизации (auth key): 256 байт случайных данных, которые сохраняются на устройстве. Дальше устройство подтверждает запросы только этим ключом; пароль и код из SMS больше не спрашиваются. Вся церемония входа существует ради того, чтобы выпустить ключ.

Ключ привязан к устройству, а не к аккаунту. Войдите с телефона, ноутбука и рабочего ПК - будет три независимые авторизации, каждая с полным доступом, каждая отзывается отдельно. Список в Настройки → Устройства - не косметическая история, а буквально перечень живых ключей, которые сервер продолжает принимать.

• Смена пароля не перевыпускает и не отзывает ключи - все устройства остаются в системе.
• Единственный способ убить ключ - завершить сеанс устройства; после отзыва мертвы все копии этого ключа, где бы они ни лежали.
• «Аккаунт» не лежит ни в каком файле. В файлах лежит ключ - а сервер не отличает копию от оригинального устройства.

tdata и session string: один ключ, разная упаковка

tdata - рабочая папка Telegram Desktop: ключ авторизации, id дата-центра, user id, кэши и настройки, зашифрованные локально хранимым ключом (файл key_datas). Пока не установлен локальный код-пароль, ключ расшифровки лежит в той же папке - скопировать папку значит унести доступ. Сессия внутри выпущена Telegram Desktop, поэтому несёт ещё и API-реквизиты и профиль устройства этого приложения - деталь, которая важна при переносе в другой софт.

Session string - те же реквизиты, сериализованные в одну строку base64: id дата-центра, api id, сам ключ авторизации и user id. Точная раскладка у библиотек разная (строки семейства Pyrogram и строки Telethon не взаимозаменяемы), но полезная нагрузка одна и та же.

Функционально это один и тот же ключ в разной упаковке. На маркетплейсах аккаунтов ходят оба формата - аккаунты продают в любой упаковке: архивом tdata либо строкой сессии вместе с JSON параметров устройства (проверено в августе 2026; см. что на самом деле даёт покупка аккаунтов).

Владение равно доступу: обращайтесь с файлами как с приватными ключами

У кого файл - у того аккаунт. Использование скопированной tdata или session string не вызывает ни SMS, ни запроса пароля, ни уведомления о новом устройстве, ни новой строки в списке устройств, потому что это не новый вход - это та же самая авторизация, неотличимая от оригинального устройства. Единственный след - поведенческий: активность с чужого IP или в чужом ритме.

Именно поэтому стилеры целенаправленно выгребают папки tdata, а крупная площадка вообще маркирует лоты аккаунтов по происхождению (разобрано в гайде о покупке аккаунтов). Файл сессии - не «данные аккаунта», это и есть учётные данные.

• Храните сессии только в зашифрованном виде: session string открытым текстом в заметке или таблице - это инцидент, который просто ещё не случился.
• Не коммитьте сессии в git и не пересылайте в чатах: обе операции создают копии, которые вы уже не контролируете.
• Один хранитель на файл. Если сессия прошла через несколько рук, считайте, что каждая пара рук оставила себе копию.
• При любом подозрении завершайте сеанс в «Настройки → Устройства» - отзыв убивает все копии ключа одновременно.

Механика переноса: импорт сохраняет ключ, экспорт выпускает новый

Импорт - завести существующую tdata или session string в инструмент - сохраняет авторизацию: инструмент читает ключ, дата-центр и user id и продолжает ими пользоваться, список устройств не меняется. Правильный импорт сохраняет и идентичность приложения - сессия, выпущенная Telegram Desktop, должна и дальше представляться его API-реквизитами и профилем устройства, иначе авторизация выглядит «телепортировавшейся» в другой софт. Teleliner делает именно так: у tdata-архива сохраняются его собственные API-реквизиты и отпечаток устройства, дубликаты определяются по Telegram user id, а не по номеру телефона, а сессии хранятся зашифрованными и расшифровываются только в рантайме.

Экспорт - отдать аккаунт новому устройству, пока оригинал продолжает работать, - не может безопасно переиспользовать существующий ключ: два водителя на одном ключе - ровно тот сценарий отказа, что разобран ниже. Поэтому экспорт выпускает новую авторизацию, обычно через вход по QR-коду: новое устройство получает собственный ключ. Видимое следствие - ещё одна строка в «Настройки → Устройства», ещё один живой ключ, который могут украсть.

Один ключ - один водитель

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

Увидев один ключ активным сразу с двух сетевых путей, Telegram может аннулировать его целиком - клиентские библиотеки показывают этот отказ как AUTH_KEY_DUPLICATED, - разлогинив обе стороны. Даже когда ключ выживает, два клиента дерутся за общее состояние, и этот паттерн - ровно то, что ищут системы детекта угона аккаунтов. Поэтому и опасны копии: запустить Telegram Desktop «на минутку проверить» на той же tdata, которую уже гонит автоматизированная сессия, - это не вторая авторизация, а второй водитель на одном ключе, и здоровый аккаунт может уехать в заморозку.

Поэтому правильный способ работать с аккаунтом из нескольких мест - несколько авторизаций: каждому инструменту свой ключ через нормальный вход, один водитель на ключ. Внутри Teleliner это закреплено архитектурно - сессию управляемого аккаунта держит единственный процесс-движок, и действия из дашборда идут через него, а не открывают параллельное подключение. Сетевая идентичность подчиняется тому же правилу: ключ, скачущий между выходными IP, выглядит подозрительно по той же причине - поэтому у каждого аккаунта должен быть свой постоянный прокси.

Облачный пароль - защита, которая реально работает

Двухэтапная аутентификация Telegram - облачный пароль - это дополнительный секрет, который спрашивается после кода из SMS при каждом новом входе. Он не шифрует существующие сессии и не остановит того, у кого уже есть ваша tdata; он закрывает выпуск новых авторизаций. Шлагбаум стоит ровно там, где привязка аккаунта к номеру телефона уязвимее всего: SIM-swap, перехват SMS, код входа, выуженный фишингом в реальном времени. То, откуда берётся номер, определяет, насколько реалистичны эти атаки; облачный пароль - слой, который держит, когда номер подвёл.

Две оговорки напоследок. Вход по QR-коду облачный пароль не обходит: подтверждение нового устройства на защищённом аккаунте всё равно требует ввести пароль, так что экспорт через QR мимо него не проскочит. И не путайте его с локальным код-паролем Telegram Desktop: тот шифрует tdata на диске, а облачный пароль закрывает вход на стороне сервера. Атаки они закрывают разные; серьёзная настройка использует оба.