The site's referral record is not registered; the code, benefits and commercial arrangement in the account-opening guide remain unverified. Nothing on this page depends on which platform you use, and no product is recommended. Full disclosure.
What each security control stops, and what it leaves open
Every control here answers one specific attack and is powerless against the others. Set out that way, the gaps in a given setup become obvious in about a minute.
Security features are usually presented as a list of things a platform offers, which invites you to count them. Counting is the wrong operation. Each one closes a different door, and knowing which doors are still open is the only output worth having.
Threat, protection, blind spot
The useful way to read any security setting is as an answer to a question of the form "what happens if…". Not "how secure is this", which has no answer, but "if my password leaks, what still stands between an attacker and my balance".
Set out that way, the controls stop looking interchangeable. Three of them are useless once an attacker is inside; one is the only thing that still works at that point. One is bound to a domain and therefore immune to a class of attack the others cannot see. And one category defeats all of them together, which is why it gets its own section at the end.
The controls, one at a time
| Control | What it stops | What it does not |
|---|---|---|
| Unique password | Credentials leaked from an unrelated site being replayed against this account | Anything once the password is entered on a fake site, or captured on a compromised device |
| SMS two-factor | An attacker who has only the password | Anyone who has your phone number transferred to them; the code arrives on their device and no equipment of yours is involved |
| Authenticator app | The above, plus removes the mobile carrier from the chain entirely | A code you type into a look-alike site yourself, which is then replayed in real time |
| Passkey | Look-alike login pages, because the credential is bound to the real domain and will not release for a different one | Loss of every registered device with no recovery path configured |
| Anti-phishing code | Email pretending to be from the platform, which will lack the phrase you chose | SMS, phone calls, chat messages and anything else outside email |
| Withdrawal address whitelist | Funds leaving to an attacker's address after a full account compromise | An address you were persuaded to add yourself, once the waiting period has elapsed |
| Device and session management | A session left open somewhere you no longer control | Anything happening in the current session, and it is a control you have to remember to look at |
Why SMS is the weak one, specifically
SMS two-factor is better than no second factor, and it is the one worth replacing first. The reason is precise rather than general.
Every other control on the list depends on something you hold: a device, a stored secret, a registered key. SMS depends on a phone number, which is not a thing you hold. It is an assignment maintained by a mobile carrier, and that carrier can reassign it to someone else through a customer service process you are not part of.
When that happens, nothing of yours is stolen. Your phone is still in your pocket, unmodified. The codes simply start arriving somewhere else, and the platform has no way to distinguish that from you having replaced your handset. The attack does not require any technical capability against you at all — only against your carrier's support process.
Moving to an authenticator app or a passkey removes that entire route by taking a third party out of the chain. It costs a few minutes.
Why passkeys are structurally different
Passwords, SMS codes and authenticator codes share a property: they are secrets you transmit. Whatever site you are looking at when you type one receives it. If that site is a convincing copy, it now has a working credential, and with a code that is valid for thirty seconds it can use it immediately.
This is why a well-built fake login page defeats an authenticator app. The app is not compromised, the code is genuine, and the site simply relays it to the real platform in real time.
A passkey does not work that way. The credential is bound to the domain it was created for, and the browser will not offer it to a different one. There is no code to read out, retype or relay. Against the specific attack of a look-alike page, this is not an improvement in degree; it removes the attack.
The trade-off is recovery. A passkey lives on your devices, so losing all of them without a configured recovery route puts you into an account-recovery process that is slow by design. Registering a second device, or keeping backup codes somewhere findable, is what makes this control safe to rely on.
The one that still works after everything else has failed
Read the table again with one question: which of these helps if an attacker is already logged in?
The answer is one row. Passwords, second factors and anti-phishing codes are all designed to prevent access, and once access exists they have already done everything they can do. The withdrawal address whitelist is not about access. It constrains what can be done with access.
With a whitelist enabled, adding a new destination address is itself a privileged action with its own verification and, on most platforms, a mandatory waiting period before that address can be used. An attacker holding a live session has to either use an address already on your list — which are yours — or add one and wait, during which time notifications reach you and the window to intervene exists.
This is why it comes first in our coverage self-check even though it is not the control anyone reaches for first. It is the last line, and the only one.
The control that works against you
There is one part of every account security system that is designed to let someone in without the credentials, and it is worth thinking about explicitly because it is the part attackers study.
Account recovery exists because people genuinely lose their devices, and a platform that could not restore access to legitimate users would be unusable. But recovery is by definition a route around the controls above, and its strength sets a ceiling on everything else: your account is no more secure than the process for getting back into it.
Two consequences follow, pointing in opposite directions.
The first is that a recovery process which is easy for you is easy for someone impersonating you. Where recovery depends on information about you rather than something you hold — date of birth, a transaction you remember, a document that can be obtained or forged — the account's real security is the difficulty of assembling that information, which is often lower than it feels.
The second is the opposite failure and the more common one. A recovery process that is genuinely strong is also genuinely slow, and if you have no backup codes and no second registered device, losing a phone converts your account into a support case measured in days. People discover this at the worst possible moment.
The resolution is unglamorous: configure recovery deliberately, while you still have access. Register a second device where the platform allows it, store the backup codes somewhere you will actually find them in a year, and check what the recovery process requires before you need to use it. That last one takes five minutes on the help pages and tells you how strong the ceiling above your account actually is.
The category that defeats all of them
Every control described here is built on one assumption: that the person operating the account is not the account holder.
When the person operating the account is the account holder, merely misled, the whole set stands aside in sequence. You log in with your unique password. You supply your own authenticator code. You add the destination address yourself and pass the verification to do it. You wait out the cooling-off period, perhaps growing more anxious as you do. You approve the withdrawal.
No control was bypassed. Every one of them functioned exactly as designed, and from the platform's perspective the entire sequence is indistinguishable from a legitimate transfer — because in every technical sense it was one.
Only two habits reduce this category, and neither is a setting:
- Re-enter from your own saved entry point. Anything involving money, no matter who appears to be contacting you or how, gets verified by navigating there yourself rather than following a link or a number you were given. This costs nothing and closes almost the whole category.
- Never transfer while being hurried. Urgency is not incidental to these attacks, it is the mechanism. A deadline that collapses if you take an hour to check was never a real deadline.
There is a practical corollary that most people never act on: find the legitimate support entrance while nothing is wrong. Once you know where it is, anyone contacting you from anywhere else can be checked against a known-correct location in seconds, without any technical skill.
Availability differs, and that is itself a data point
Not every platform offers every control on this list. Passkey support in particular is uneven, and whitelist implementations vary in whether the waiting period is mandatory or optional — a detail that decides most of the control's value.
So the presence of these features belongs on a pre-funding check alongside everything else. What a platform chooses to build says something, and it is cheap to look at: the account security page is public information before you fund anything.
Record the recovery path as well as the enabled state; a control you cannot recover safely can become its own failure point.
To see which categories your current setup already covers and which are still open, the self-check runs entirely in your browser. It returns a coverage list, not a score, for the reasons the table above makes obvious.
Questions
Which security setting should I enable first?
The withdrawal address whitelist, because it is the only control that still does anything after an account has already been compromised. Everything else is designed to prevent access; the whitelist constrains what can be done once access exists. Its value depends on whether the platform enforces a mandatory waiting period before a newly added address can be used.
Is an authenticator app really better than SMS?
Yes, for a specific reason. Every other control depends on something you hold; SMS depends on a phone number, which is an assignment your mobile carrier can transfer to someone else through a support process you are not part of. When that happens nothing of yours is stolen and the codes simply start arriving elsewhere. An app or passkey removes the carrier from the chain.
What makes a passkey different from a code?
Passwords and codes are secrets you transmit, so whichever site you are looking at when you enter one receives it, and a convincing fake can relay it to the real platform within its validity window. A passkey is bound to the domain it was created for and the browser will not offer it to a different one, which removes that attack rather than making it harder.
What does an anti-phishing code cover?
Only email the platform sends you. Genuine messages carry a phrase you chose, so mail arriving without it can be discarded unread. SMS, phone calls and chat messages are entirely outside its range, which is why it is worth setting up and is not a substitute for anything else.
If I enable every control, can I still lose funds?
Yes, through the one category none of them addresses: a transfer you are persuaded to make yourself. Each control assumes the operator is not you, so when the operator really is you and merely misled, they stand aside in turn while functioning correctly. Only two habits reduce it: verify anything involving money by navigating from an entry point you saved, and never transfer while being hurried.