Account security: two-factor, withdrawal whitelist, API keys

The order, and why it matters

Do these in this sequence: authenticator-based two-factor first, withdrawal whitelist second, API keys last — and by "last" I mostly mean "not at all".

The reason for that order is not aesthetic. The whitelist carries a cooling-off period whenever you enable it or add an address to it. That delay is the entire mechanism: an attacker who has your account cannot add their own address and empty it in the same session. But the delay applies to you just as strictly, so the moment to accept it is a quiet week when you have nothing to move. Turn it on the evening before a token unlock and you have built a cage around yourself rather than around anyone else.

Two-factor goes first because the whitelist settings themselves are protected by it. Setting up a lock before the door is hung achieves less than it appears to.

Two-factor: not the SMS one

Three kinds are usually offered and they are not equivalent.

SMS is the one to move away from, and the reason is worth understanding rather than memorising. Your phone number is not really yours — it is assigned to you by a carrier, and a person who convinces that carrier's support desk that they are you can have it reassigned in an afternoon. Every code then arrives on their handset. This is not exotic; it is a routine technique, and it is why an SMS-protected account with a meaningful balance is a soft target.

An authenticator app generates codes on the device itself with no network involved, so there is no carrier in the loop to be persuaded of anything. When you enable it, save the backup codes or the setup key somewhere offline — on paper, in a drawer. That single step is the difference between a lost phone being an inconvenience and being a multi-day identity-verification ordeal.

A hardware key is better still and is worth the cost once the balance justifies it. If you go that way, register two and keep the second somewhere else. A single hardware key is a single point of failure wearing a security badge.

The withdrawal whitelist

Switched on, the whitelist restricts withdrawals to addresses you have pre-approved. Somebody who takes over your account cannot simply paste in their own wallet and send; they have to add an address and then wait out the cooling-off period, which is a window in which you can notice, log in, and stop it.

Two practical points. First, enable it before your first deposit, so the waiting period runs down while you have nothing at stake. Second, add the addresses you actually use at the same time — your own hardware wallet, an exchange you regularly move to — so that when you eventually need to withdraw, the list already contains the destination.

What people get wrong is treating it as something to configure in a crisis. By the time there is a crisis, the delay is working against you. It is also worth saying plainly that a whitelist does nothing about somebody trading your balance into worthlessness or spending it inside the platform; it constrains the exit, not the account. It is one control among several, not a perimeter.

API keys you never needed

An API key is a credential that lets software act on your account without logging in. If you are not running a bot or a portfolio tool that specifically requires one, you have no reason to create any.

If you do need one, three rules cover most of the danger. Never grant withdrawal permission — almost nothing legitimately needs it, and a key that can withdraw is a password that can withdraw. Restrict the key to specific IP addresses if the option is offered, which makes a stolen key useless from anywhere else. And write down what each key is for at the moment you create it, because a key labelled nothing, six months old, is a decision you can no longer evaluate.

Then go and look at your existing keys. Most people who have been on an exchange for a couple of years have one or two left over from a tool they stopped using, still live, still permissioned. Delete them. There is no cost to deleting a key you are not using and a real cost to leaving it there.

What changes during a launch

Launch periods change the risk picture in ways that have nothing to do with your settings and everything to do with your attention.

You are expecting messages. You are expecting links. You are in a hurry, watching a countdown, and reading quickly — which is the precise state in which a convincing fake page succeeds. The people running those pages know when the campaigns are, because the campaigns are announced publicly, and they schedule accordingly. The volume of impersonation attempts around an announcement is not an accident of timing.

Two habits carry most of the weight here. Arrive through your own bookmark or the app, never through a link handed to you, however plausible its source. And treat anyone who contacts you first as fake by default — support does not open conversations, and it does not do so on social platforms at all. The detail of how these operations work is set out in fake airdrops and fake support staff, and the short version is that you do not need to identify the fake if you never arrive at it.

A third habit, less obvious: during a launch, resist installing anything. New wallet, new browser extension, new "claim helper" — the answer is no. Whatever you needed should have been installed a week ago in a calm moment, which is the same argument as everything else on this page.

Three ways accounts actually go

Not theory. These three account for most of what we hear about.

• A password reused somewhere else. A shopping site leaks, the same email and password appear in a list, and somebody tries them against every exchange in turn. The exchange was never breached; the reuse was the whole vulnerability. A unique password per site, kept in a password manager, closes this entirely.
• A phishing page reached from a search result or a message. The address bar reads almost right. You type the password, then you type the two-factor code, and both are relayed to the real site in real time by the attacker. Note that two-factor did not save you — this is exactly the attack it does not stop, which is why arriving through your own bookmark matters even for people with good settings.
• The SIM swap. The number is ported, SMS codes go elsewhere, the password reset runs through them. Whoever is on the other end does not need to break anything technical.

Read down that list and one thing stands out: only the third is really about the account. The other two are about a password and about where you clicked. Security settings are necessary and they are not the main variable, which is a slightly deflating conclusion for an article full of settings — but it is the accurate one, and knowing it changes what you spend your caution on.

Changing phone or number

The most common self-inflicted lockout is a new phone. The authenticator seed does not travel with your SIM, your phone number, or an ordinary cloud backup of your apps. Wipe the old handset before moving it and the codes are gone.

The sequence that works: with both phones in front of you, use the authenticator's own transfer or export function to move the entries, log in successfully on the new device to prove it works, and only then reset the old one. If your app has no transfer function, re-enrol two-factor on the exchange from scratch while you still have the working old device — disable, re-enable, scan the new code.

Changing phone number is a smaller job but worth doing deliberately: update it in the account while the old number still works, because the change is usually confirmed by a code sent to the old number. Do it after the number is disconnected and you are in the recovery process, which means identity checks and days rather than minutes.

If you are travelling and about to swap to a local SIM, do all of this before you leave. Recovering an exchange account from a hotel room in a country you have never logged in from is the hardest version of this problem, because the unfamiliar location triggers extra checks at the same time.

The occasional look round

Twice a year is enough, and it takes about five minutes.

1. Active sessions and devices. Log out anything you do not recognise or no longer use.
2. API keys. Delete whatever is no longer attached to a working tool.
3. The whitelist. Remove addresses belonging to wallets you have retired.
4. Recovery email and phone. Confirm both still reach you — an old work address here is a common quiet failure.
5. Backup codes. Check they are where you think they are, and still legible.

Put it in a calendar twice a year and it stays a five-minute job forever. Skip it for three years and it becomes an afternoon of untangling, usually undertaken in the worst possible circumstances.

Setting names and the exact length of cooling-off periods differ by platform and change over time. Everything above describes common behaviour as of August 2026 and is not a substitute for what your own account's security page tells you.