Telegram two-step verification: the cloud password, the recovery email and the traps

By default a Telegram account is protected by one thing: whoever receives the SMS gets in. That is a thin defence for an identity that carries your chats, your contacts and, on a working fleet, your business. Two-step verification - what Telegram calls the cloud password - is the layer that holds when the number stops being yours.

It is also the control most often set wrong. Half-configured, it looks enabled while a stranger keeps the key; set with someone else's recovery email, it is not protection at all but a lock whose spare key lives in another person's mailbox. This guide covers what it gates, what it cannot do, and the traps that make a password look stronger than it is.

What the cloud password actually gates

The cloud password is an extra secret demanded after the SMS code at every new sign-in. Under the hood Telegram verifies it over SRP: the password itself never travels to Telegram's servers, only a mathematical proof that you know it. What the password gates is narrow and specific - the minting of new authorizations. It does not encrypt anything you already have, and it does not touch keys that already exist.

That table contains the single most misunderstood line. A cloud password does nothing against a leaked session file: an authorization is a key, and a key that already exists is not asked for passwords again. Whoever holds a copy of your tdata is already inside, password or not. The only remedy there is terminating the session, which kills every copy of that key at once.

One more boundary worth knowing: QR login respects the password. Approving a new device on a protected account still requires it, so flows that mint a second session cannot slip past it. And it is not Telegram Desktop's local passcode - the passcode encrypts tdata on disk, the cloud password gates sign-ins server-side. They cover different attacks, and a serious setup uses both.

The recovery email is a spare key - to somebody

A recovery email is the escape hatch for a forgotten password: Telegram mails a code, the password resets in minutes. Without one, the only way back is a full reset (account.resetPassword), and that carries a seven-day wait during which the account accepts no new sign-ins at all. On a working account that is a week of downtime, so the email is worth having.

The flip side is exact and unforgiving: whoever controls that mailbox controls the password, and therefore the account. A recovery address you did not set is not a detail to clean up later - it is a live backdoor, and it survives almost everything you would instinctively do about it.

There is a second address type that is easy to miss. Telegram also supports signing in with an email instead of an SMS code. An account carrying somebody else's sign-in email can be entered without the phone number at all - a backdoor that has nothing to do with the cloud password and is not removed by changing it. If a status screen shows you a sign-in address you do not recognise, treat the account as still belonging to whoever owns that mailbox.

Note also what no tool can do for you: attaching a recovery email cannot be automated. Telegram answers a password-with-email request with EMAIL_UNCONFIRMED and waits for a confirmation code delivered to that mailbox, so any honest platform sets the password without an email and leaves the address to you. Add it by hand, in an official client, to a mailbox you control - ideally a separate alias per account, with its own two-factor protection. Never let one mailbox become the recovery address for a whole fleet: that concentrates every account's recovery rights in a single point of failure.

An account that came from someone else

Everything above compounds on a purchased account, where the seller had full control right up to the sale and may have arranged to keep it. What is really on sale and how origin is labelled is a separate question; this is the hygiene that applies the moment an account you did not register lands in your hands.

1. Read the current state before changing anything: is a password already set, is a recovery address attached, is a sign-in email attached, which sessions are live.
2. Remove the existing cloud password and set your own from scratch. Do not merely change it - a change keeps the previous owner's recovery address attached.
3. Terminate every authorization you did not create. A session younger than about 24 hours cannot terminate others, so run this from an established device.
4. Attach your own recovery email by hand in an official client, to a mailbox you control.
5. Only then let the account do anything that matters - and treat the first weeks as warming, not production.

Steps two and three are the ones people skip, and they are the ones that decide ownership. A password you changed rather than replaced, or one unaccounted session left alive, means you are renting the account rather than owning it. The full intake order - proxy first, quarantine after, and the signals that say an account is not salvageable - is in preparing a bought account.

A sign-in that stops at the password is an alarm

The cloud password doubles as a sensor. When an attempted sign-in reaches the password prompt and stalls there, it means the SMS code has already been obtained and used - the password is the only thing that held. That is not routine: it is evidence that the code delivery path is compromised, whether through SIM swap, an SMS-rental service reselling the number, or a phished code.

React as if the number is burned until you know where the code leaked: audit the device list, terminate anything unfamiliar, and plan the account's future on the assumption that codes to that number can reach someone else. Where the number came from usually explains how it happened.

Teleliner surfaces this signal on the account itself rather than making you go looking: when an authorization is seen sitting at the password prompt, the account is flagged. The flag means the password did its job - and that the number no longer belongs to you alone.

Telegram's quarantines after a password change

Right after you set or change a password, and right after a new session signs in, Telegram applies day-long quarantines. They look like breakage and are not.

• FRESH_RESET_AUTHORISATION_FORBIDDEN - a session younger than roughly a day cannot terminate other sessions. Revoke from an older device, or wait it out.
• PASSWORD_TOO_FRESH and SESSION_TOO_FRESH - certain sensitive operations are refused for a period after a password change or a fresh sign-in, and the error carries the remaining seconds.
• A full password reset without a recovery email waits seven days before it completes.

The practical consequence: do the security work in the right order and with time in hand. Setting a password and immediately trying to clear old sessions from that same fresh session is exactly the sequence the quarantine blocks - which is why the checklist above starts from an established device.

Two-factor on the dashboard is a different thing

Do not confuse the account's cloud password with two-factor on the tool that manages the account. They protect different doors. If a platform holds sessions for a fleet, its login is the most valuable single credential you own: one stolen dashboard password would otherwise hand over every account behind it.

In Teleliner that door has its own second factor: a standard TOTP code from any authenticator app, enabled in Settings, plus one-time backup codes issued when you turn it on. The protection lives on the user rather than on the login method, so signing in with Google instead of a password does not skip it. Sensitive operations - exporting an account's session, for instance - additionally ask for a fresh code even inside an already authenticated session, so a hijacked browser tab is not enough to walk away with your fleet. Recovery is by backup codes only, which is why they are worth storing somewhere safe.

One honest note on storage, since it is a fair question to ask of any tool that logs in on your behalf: cloud passwords, session keys and proxy credentials are stored encrypted, each record under its own key, so a stolen copy of a database is not a usable copy of a fleet.