Two-factor on your panel account: TOTP and recovery codes

Your servers are protected by whatever protects the account that administers them. That account can stop, wipe and delete everything you have, and on most panels it can do it faster than you can open a ticket about it. So the honest way to think about your password is that it is the only thing standing between a stranger and all of it, and passwords leak constantly through breaches at sites that have nothing to do with hosting. Two-factor authentication turns a stolen password into a failed login. It takes about a minute to turn on, and the only part that needs thought is the recovery codes - because the common way people lose an account to two-factor is not an attacker, it is a new phone.

What a stolen panel password actually reaches#

Before deciding how much protection is proportionate, it is worth being specific about the blast radius. A panel account is not one server.

Someone with your password has the console on every server, which means every admin command. They have the file manager, which means your world, your database credentials sitting in a config file, your bot tokens in an environment file. They have the backups, including the ability to download them and to delete them. Deleting a server deletes its backups with it, locked ones included, so "restore from backup" is not a defence against somebody who owns the account. That asymmetry is the whole argument: the attacker needs one working password, and you need everything.

The overwhelmingly common route in is not a targeted attack. It is a password you also used on a forum that was breached in 2019, tried automatically against thousands of sites. That attack does not survive a second factor, which is why a second factor is worth sixty seconds of your evening.

What TOTP actually is#

The panel takes a six-digit code from an authenticator app. The standard behind it is TOTP, defined in RFC 6238 on top of the earlier HOTP standard, and understanding the mechanism removes most of the confusion around it.

At enrolment the server generates a random secret and shows it to you as a QR code, with the same value available as a string of base32 characters for typing in by hand. Your app stores that secret. From then on, both sides do the same arithmetic independently:

1. Take the current Unix time and divide it by the step, normally 30 seconds, discarding the remainder. That is the counter.
2. Compute an HMAC of the counter using the shared secret, normally with SHA-1.
3. Truncate the result down to six digits.

Nothing travels between your phone and the panel. The app is not online, does not know which server it is authenticating to, and works in aeroplane mode in a basement. The only things that must match are the secret and the clock. Servers usually accept the previous and the next step as well as the current one, which gives you roughly a ninety-second tolerance for clock drift and slow typing.

The QR code encodes a URI that carries every parameter:

otpauth://totp/Panel:you@example.com  ?secret=JBSWY3DPEHPK3PXP  &issuer=Panel  &algorithm=SHA1  &digits=6  &period=30

In reality that is one unbroken line; it is wrapped here to be readable.

Turning it on, and the two minutes of care it deserves#

1. Open the account area of the panel at panel.renode.space and find two-factor authentication.
2. Scan the QR code with your authenticator app.
3. Scan it with a second device or app before you continue. The same secret can live in two places, and this is the single best insurance against a lost phone. An old tablet in a drawer, or a desktop password manager that stores TOTP, both work.
4. Write the base32 secret itself on paper and put it with your important documents. A secret can be typed into any new app later; a QR code you no longer have cannot.
5. Enter the current code to confirm. Enrolment is not finished until the server has seen a code it agrees with.
6. Save the recovery codes now, before you close the page. Assume you will not be shown them again.

Step three is the one people skip, and it is the one that keeps them out of a support queue six months later.

Recovery codes: the part people get wrong#

Recovery codes are single-use strings that stand in for a TOTP code when you cannot produce one. Each one works once. They exist because phones get lost, dropped, wiped and replaced, and because an authenticator app with no backup takes its secrets with it.

Where to put them, in order of preference:

• Printed on paper, in the place you keep documents you would not lose in a house move. Unfashionable and extremely effective.
• In a password manager you do not access only from the same phone that holds the authenticator. If the phone is both your authenticator and your only route into your vault, a single lost phone takes both factors.
• In an encrypted file on a machine that is backed up. A text file in cloud storage with no encryption is not this.

Where not to put them: a note on the phone running the authenticator, a Discord message to yourself, the same screenshot folder as everything else, or a sticky note under the desk where you also stream from.

Practical habits worth having. Cross a code off the list when you use one, because trying a spent code looks identical to trying a wrong one and sends you round in circles. If you get down to your last two, regenerate the set. And if you ever have to use one because your phone is gone, do the enrolment again from scratch on the new device rather than living without a working app.

Choosing an authenticator app#

Any app that implements TOTP will work, because the standard is the standard. The things that differ are backup, export and whether the app will still exist in three years.

• Open-source apps with encrypted local backups are the safe default. Aegis on Android has an encrypted vault and an export file you control. 2FAS and Ente Auth run on both platforms and are actively maintained.
• Vendor apps with cloud sync trade some control for convenience. Google Authenticator gained account sync after years of having no backup at all, which stranded a great many people; Microsoft's app has had backup for longer. If you use one, confirm the backup is actually switched on rather than assuming.
• Password managers that store TOTP put both factors in one vault. This is a real trade-off and the answer depends on the vault: if the manager is itself protected by a strong master password and its own second factor on a different device, it is fine and it is what a lot of careful people do. If the vault unlocks with a four-digit PIN on the same phone, you have one factor with extra steps.
• Desktop-only options such as KeePassXC will generate codes from a secret you paste in, which is useful as the second enrolment in step three above.

Two things to check whatever you pick: that you can export your secrets, and that the app has not quietly retired the platform you rely on. Several authenticators have dropped their desktop builds. An app you cannot export from is an app that owns your logins.

The code is rejected, and it is almost always the clock#

TOTP has exactly two inputs, so a rejected code narrows down fast.

Clock drift. The counter is derived from the time. If the device generating codes is more than a step or so away from real time, every code it produces is wrong. Phones with automatic network time almost never drift; a phone with the time set by hand, a device that has been off for a month, or a virtual machine that was suspended will.

# Linux: check and enable network time$ timedatectl status$ sudo timedatectl set-ntp true# Windows: force a resync$ w32tm /resync

On a phone, turn on the automatic date and time setting. Some authenticator apps also have a time-correction option that measures the offset once and applies it to the codes without touching the system clock.

The wrong entry. If you administer several panels and services, your app is a list of similar-looking six-digit codes. Check the issuer line, not the position in the list.

The code expired between reading and typing. Codes near the end of their window fail for slow typists. If the countdown ring is nearly empty, wait for the next one.

A recovery code in the wrong box. Recovery codes and TOTP codes usually have separate fields. Putting one in the other spends nothing but wastes time.

Too many attempts. Logins are rate limited and there is a captcha, so a run of failures gets slower rather than faster. Stop, fix the clock, come back.

What two-factor does not protect#

Being clear about this matters, because the failure modes that remain are the ones worth spending your remaining effort on.

• Real-time phishing. A convincing fake login page can relay your code to the real site within its thirty-second window. TOTP does not prevent this; only checking the address bar does. The panel is at panel.renode.space and nowhere else. Treat any login link that arrives in a message with suspicion, and reach the panel by typing the address or from your own bookmark.
• A stolen session. Two-factor runs at login. Malware on your machine, or a browser extension with too much access, can take the session cookie afterwards. This is what the session list is for: it shows where the account is signed in and lets you end those sessions.
• API keys. An API key authenticates without a login, so it is not covered by two-factor at all. Keys can be restricted to particular addresses, and that restriction is the equivalent protection. Treat a key like a password with no second factor, because that is what it is.
• SFTP and RCON. SFTP credentials are per server, not per account, and there is no second factor on a file transfer protocol. RCON is a password on an open port. Both are separate credentials with separate hygiene - RCON, safely and environment variables and secrets cover them.
• Your email. Email is the root of most recovery flows anywhere, and hosting invoices arrive there. If your email account has no second factor, fix that before this one.
• Other people. Two-factor protects your account. A co-administrator without it is an unprotected door into the same servers, which is the subject of the next section.

Handing out help without handing out the account#

The reason people share account passwords is that they want somebody to be able to restart a server at midnight. There is a proper mechanism for that, and using it means your second factor is not undermined by a password sitting in a group chat.

Subusers get granular permissions on individual servers: console only, files only, never billing. Permissions live in a role, people live in a team, and a grant joins a team to a server, so a person can help with one server without seeing the rest of your account. Access can be time-boxed, invitations go out by link, join code or email, and every server keeps its own activity log, so "who restarted it" has an answer. Subusers and least privilege works through which permissions are safe to hand out and which ones are ownership in disguise.

The account itself has a few more things guarding it that are worth knowing exist: passwords are stored as bcrypt hashes, the login is behind a captcha and rate limits, the session list lets you sign out of everywhere at once, and API keys can be restricted by address. None of that replaces the second factor. All of it is what makes the second factor worth adding rather than the only wall.

FAQ#

Which authenticator app should I use?

Any of them, as long as you can back up or export the secrets. Aegis, 2FAS and Ente Auth are good open-source choices; the vendor apps are fine if their backup is switched on. The app matters far less than having the secret enrolled in two places and the recovery codes written down.

I lost my phone and my recovery codes. Can support restore my account?

No. With the authenticator gone and the codes gone there is no credential left for anybody to verify you with, and an account that can be talked open by a convincing story is not protected at all. This is exactly why the advice above is to enrol a second device at setup time and keep the codes off the phone.

Can I use a hardware key or SMS instead?

The panel takes codes from an authenticator app, plus single-use recovery codes. Hardware keys and SMS are not options here. That is a smaller menu than some services offer, and in practice TOTP with a second enrolled device and printed codes covers the realistic threats to a hosting account.

Do the people I share a server with need their own two-factor?

Yes, and they should have it. A subuser with a weak password and no second factor can be taken over the same way you can, and whatever you granted them is what the attacker gets. Grant the minimum, review it, and use the per-server activity log to see what has been done.

Does two-factor protect my game server itself?

Not directly. It protects the panel account that administers it. The server has its own credentials - RCON, in-game admin, database passwords, SFTP - and none of them see your second factor. Rotate those separately, particularly after anybody with access stops being involved.

Is it safe to keep the TOTP secret in my password manager?

It is a reasonable trade if the vault has a strong master password and its own protection on a different device. It is a bad one if the vault unlocks with a PIN on the same phone that would be stolen alongside it. Either way, keep the recovery codes somewhere the manager is not.