1. App-based two-factor, not SMS
If you only ever change one setting, change this one.
SMS-delivered codes have a failure mode that has nothing to do with your phone's security: SIM swap. An attacker persuades a mobile carrier to move your number to a SIM they control — through social engineering, a bribed employee, or a weak identity check at a retail counter. Your handset does not need to be touched. It simply stops receiving service, and every code sent to that number arrives somewhere else.
This is not a theoretical concern. The US National Institute of Standards and Technology treats out-of-band authentication over the public switched telephone network as a restricted authenticator in its digital identity guidelines — a formal designation meaning it carries risks that make it unsuitable as a general recommendation. That position has been in place since the 800-63-3 generation and is carried forward in the current NIST SP 800-63B-4 revision.
An authenticator app generates codes on your device from a seed that never travels over the phone network, so the SIM-swap path simply does not apply. A hardware security key is stronger again, because it also refuses to authenticate to a look-alike domain — which defeats the phishing case as well as the SIM case.
Where the platform requires SMS as a mandatory factor, keep it, but add an app-based factor as well and make sure withdrawals require the app one. The goal is not to have no SMS; it is to have nothing valuable protected by SMS alone.
2. The withdrawal whitelist
A whitelist restricts withdrawals to addresses you have pre-approved, and imposes a waiting period before a newly added address can be used.
Understand what it actually buys you, because it is not what people assume. It does not stop an account compromise. What it does is convert an instant total loss into a delayed one, and put a window between the two. An attacker who gets in cannot send funds anywhere immediately; they have to add an address and wait. That waiting period is your entire opportunity to notice the notification, log in, and stop it.
That is the whole value proposition, and it is enough. Most account drains succeed because they complete in minutes, before the owner sees anything.
The practical cost is real: you cannot withdraw to a new address on impulse. Our position is that this is a feature, not a bug — the withdrawals people most regret are the impulsive ones, and a mandatory delay is the cheapest protection against your own bad afternoon that exists.
3. The anti-phishing code
You choose a short string; the platform includes it in the emails it sends you. Simple, and more useful than it looks.
Its power is that it is a negative test. A phishing email can copy the layout, the logo, the sender name and the tone perfectly — all of that is public. It cannot know a string that exists only between you and the platform. So the rule becomes mechanical: no code, not genuine. You do not have to assess how convincing the email looks, which is good, because assessing that is exactly what humans are bad at under time pressure.
Two things to hold to. Pick something that is not guessable from your public life — not your username, not your dog. And apply the rule even when the email is alarming, because alarming is the point of it.
4. Devices, sessions and API keys
Lower priority, still worth ten minutes.
- Review the active session and device list. The value is baseline knowledge: if you know what is supposed to be there, an unfamiliar entry means something. If you have never looked, it means nothing.
- Revoke API keys you are not using. Every live key is a credential that can act without your password or your second factor. If you experimented with a bot or a portfolio tracker once, that key is probably still there.
- Never grant withdrawal permission to an API key unless you genuinely require it, and if you do, bind it to an IP address. A trading-only key that leaks is a bad day; a withdrawal-enabled key that leaks is the end of the account.
- Sign out of devices you no longer have. Old phones, work laptops, a friend's computer.
The back door nobody hardens
Here is the part that undoes everything above: your email account.
Account recovery flows generally run through email. Password resets, two-factor resets, security-setting changes — all of them tend to be confirmable from the mailbox. So an attacker who controls your email does not need to defeat your authenticator app; they can often ask politely for a new one.
Which means the exchange account's real security level is the minimum of its own settings and your email's settings. Hardening one and ignoring the other achieves nothing. Put app-based or hardware two-factor on the email too, use a unique password, and check its forwarding rules and recovery addresses — silently adding a forwarding rule is a standard move precisely because nobody ever looks.
The same applies if you signed up using a Google, Apple or Telegram account. That account is now a key to this one, and it needs the same treatment.
Why this order, and what each one does not do
Security advice usually arrives as a list of equals. It is not a list of equals. Each of these four settings blocks a different attack, and three of them are useless against the attack the fourth one stops. Knowing which is which is what lets you stop at the right point rather than either doing nothing or buying a hardware key you will not use.
| Setting | Stops | Does nothing against |
|---|---|---|
| App-based two-factor | Credential stuffing, a leaked password, SIM swap | You typing the code into a phishing page yourself. The code is a one-time secret, and handing it over in real time defeats it entirely. |
| Withdrawal whitelist | An attacker who is fully inside the account draining it immediately | You adding a bad address yourself, or a clipboard swap at the moment you add one. The delay protects the account, not your attention. |
| Anti-phishing code | Fake emails, because a genuine one carries the string and a fake one cannot | Phishing that arrives by SMS, phone call or messaging app, where there is no email to inspect. |
| Device and session review | Nothing, on its own | Everything, on its own. Its value is detection: it tells you an intrusion happened. That is worth something only if you look. |
Read the right-hand column carefully, because it contains the actual lesson: every one of these fails against a person who is persuaded. That is why the last section of this page is about the conversation rather than the configuration. The settings raise the cost of attacking you from outside. Nothing in a settings menu defends against you being talked into it.
What we would add if you want a fifth thing
A hardware security key, if the account and the platform support one. It is the only widely available factor that resists real-time phishing, because the key checks the domain it is talking to before it will respond — which is precisely the check a human under time pressure fails. It costs money and it needs a backup key, so we put it fifth rather than first. But if you have worked through the four above and want the next real step, this is it, and everything else on the usual list is decoration next to it.
API keys, if you ever create one
Most people never will, and if that is you, skip this. For everyone else it deserves more than a line, because an API key is the one thing on an exchange account that can drain it without any login, any two-factor prompt or any interaction from you at all.
- Never enable withdrawal permission. Trading permission and withdrawal permission are separate switches, and almost no legitimate use case needs the second. A key with trade-only permission that leaks costs you a bad trade; a key with withdrawal permission that leaks costs you the balance.
- Bind the key to an IP address where you can. This turns a leaked key into a useless string for anyone not sitting on that address.
- One key per purpose, and delete the ones you have stopped using. Old keys attached to a tool you abandoned two years ago are pure exposure with zero benefit.
- Treat a key like a password, because it is one. Not in a chat message, not in a screenshot, not in a repository, not pasted into a website that offers to analyse your portfolio.
- Any site or app asking for an API key from another platform deserves suspicion by default. Some are legitimate. The question to ask is what permissions it wants, and if the answer includes withdrawal, the conversation is over.
If it has already happened
Order matters more than speed here, because the wrong first move wastes the only window you have.
- Change the password from a device you trust, and only from one you trust. Doing it on the compromised machine hands over the new password too.
- Revoke every active session and every API key. A password change alone does not always terminate sessions, and an API key with withdrawal permission does not care about your password at all.
- Check the withdrawal whitelist for entries you did not add. This is the step people skip, and it is where an attacker leaves themselves a way back in.
- Check the registered email and phone number. If either has been changed, the account recovery route now belongs to someone else and the platform needs to hear that immediately.
- Secure the email account itself, with its own password change and its own session revocation. If the email was the way in, everything else is temporary.
- Then contact support through the platform, with times, amounts and what you have already done.
What not to do: reply to anyone who contacts you about it. A compromised account attracts a second wave of "recovery" offers within hours, and they are the same people or their colleagues.
What the attack actually looks like
Almost nothing in this space involves breaking cryptography. It involves persuading you to do something. The US Federal Trade Commission's consumer guidance on crypto scams describes the same small set of patterns that show up again and again, and they are recognisable once you know the shape:
- Urgency. Your account will be suspended, your funds are at risk, act now. Manufactured time pressure exists to stop you checking. Genuine security processes do not need you to hurry.
- A different channel. Someone claiming to be support who reaches you first, on a messaging app. Real support does not contact you out of nowhere and does not move you to Telegram.
- Asking for a credential. A password, a verification code, a seed phrase, a private key, an API key. No legitimate party asks for any of these, ever, for any reason. Read a request for one as proof of fraud and stop reading.
- A guaranteed return. Anything promising a fixed, risk-free yield. The claim itself is the tell, regardless of who is making it.
- Screen sharing or remote access. "Let me help you fix it." Nothing that requires remote access to your device is help.
Two habits close most of it. Never reach an exchange through a link you were sent — type the address or use your own bookmark. And when something feels urgent, take the thirty seconds to log in independently and check whether the alarming thing is actually there. It almost never is.
What the good version sounds like
The scripts that work are not the badly spelled ones. A competent approach opens with something true — a real recent login from a real city, a real withdrawal you actually made — because a verifiable fact buys credibility for the false part that follows. It is polite, it is patient, and it never asks for anything on the first contact.
Then it produces the pivot. There is a security problem with your account; a specialist will call; the specialist will help you move your funds to a "secure address" while the investigation runs. Every step sounds like protection, and the last step is the theft. The single structural tell is the direction of travel: a genuine security process never ends with your money in a new place. If the resolution of a security incident involves you moving funds anywhere, you are not in a security incident.
The three-second rule for any inbound contact
You do not have to be clever about this, and you should not try to be. Whatever arrives — email, SMS, call, message, in-app notice — do not act on it in that channel. Close it. Reach the platform yourself, the way you always do, and see whether the thing exists. That single habit does not require you to judge whether the message was real, which is the judgement people reliably get wrong under pressure.
Our position on the popular advice to "verify the sender's address": it is weak, and we do not lead with it. Display names are trivially forged, addresses can be near-identical, and inspecting headers is not something anyone does at eight in the morning. Do not authenticate the message. Authenticate the channel, by choosing it yourself.
Questions people ask afterwards
Is SMS two-factor better than nothing?
Yes, and it is the weakest of the options because a phone number is transferred by a customer-service process rather than by cryptography. Use it only until you have set up an authenticator app, then remove it as a factor if the platform allows.
What happens if I lose the phone with my authenticator on it?
You use the recovery codes you saved when you set it up, which is why saving them offline is part of the setup rather than an optional extra. Without them, recovery is an identity-verification process measured in days.
Does the anti-phishing code stop phishing?
It stops one specific and very effective attack: an email that looks like it came from the platform. Your code appears in genuine platform emails and cannot be in a forged one. It does nothing about fake websites or fake support conversations.
Is a hardware security key worth it?
If the balance would hurt to lose, yes. It is the only factor that cannot be phished, because it verifies the site's identity before it responds. Keep a second factor registered as well, so losing the key does not lock you out.
Should I use a password manager?
Yes, and the reason is not convenience. Every account gets a distinct password, so a breach anywhere else cannot reach this account. Most compromises begin with a password reused from a site that leaked years ago.
How often should I review devices and sessions?
Whenever you get an alert you did not expect, and otherwise once in a while — quarterly is plenty. The point is not the schedule, it is that you know where the page is before you need it in a hurry.
Sources
- US National Institute of Standards and Technology, SP 800-63B, Digital Identity Guidelines: Authentication and Authenticator Management — linked in the two-factor section above; the basis for preferring an authenticator app or hardware key over one-time codes sent over the public telephone network.
- US Federal Trade Commission, What to know about cryptocurrency and scams — linked in the section on scam patterns above; consumer guidance describing the recurring patterns summarised there.
- Binance, official help centre — for how a specific setting behaves on your account, which differs by region and changes.
Nothing on this page is specific to one platform except where it names one. The reasoning is about authentication and social engineering generally, and it applies unchanged to any account holding money.