Securing Your Crypto Account: API Keys, 2FA and Withdrawal Allowlists

The most effective lever in securing an exchange account is not a longer password but the permission set on your API keys. A read only key can neither trade nor withdraw, no matter who holds it. Everything else, from two factor sign in to a withdrawal allowlist, builds on that foundation.

Why is the API key the most important point?

Because it stays valid indefinitely and works in the background. Unlike a browser sign in it draws no attention when used, and unlike a password it necessarily lives in a second system, namely the software that consumes it.

That is precisely why permissions matter more than secrecy alone. Secrecy is an assumption about the future, a restricted permission is a fact. Having both puts you in good shape. Relying on secrecy alone means having no plan for the moment it fails.

Menu paths differ between exchanges and change regularly. What follows describes the principles. The concrete steps live in your exchange's documentation, and a practical integration is walked through in connecting the Bitget API.

Which permissions does a journal actually need?

Read only. A journal analyses what already happened and needs access to positions, fills and account movements for that. It never has to initiate anything.

A simple setup rule follows: trading off, withdrawals off, anything that writes off. If an interface does not offer that separation, that is a reason to reconsider the integration rather than a reason to grant more rights.

Two points get overlooked regularly. First, each purpose deserves its own key so you can revoke one without interrupting everything else. Second, on exchanges that additionally require a passphrase, that passphrase needs the same protection as the key itself, since the two function as a pair.

What does restricting to network addresses achieve?

It renders a leaked key useless in most places. Many exchanges allow a key to be valid only from specified network addresses, and after permissions themselves this is frequently the most effective setting available.

It makes practical sense when the software consuming the key operates from a fixed address. With a hosted service that is usually the case, and the addresses to enter are published in its documentation.

The caveat: if the address changes, the connection breaks without warning. Anyone using this setting should therefore know how an interrupted sync manifests, and not mistake it for an error in the analysis itself.

How often should you rotate keys?

On a fixed rhythm rather than by feel, and additionally whenever something prompts it. A quarter is a common interval and short enough not to be forgotten.

More important than the rhythm, though, is the clearing out. Three cases call for deletion rather than rotation:

• Unused keys. Any key no software still needs is pure risk with nothing on the other side.
• Keys from trial runs. They get created while experimenting and are almost never revisited.
• Keys at services you no longer use. Ending a subscription does not delete the key at your exchange.

Keep a short list of your own for this: which key sits with which service, with which rights, since when. That list is the only place you retain an overview, because the exchange does not show you what a key was for.

Where should keys and passphrases live?

In a password manager and nowhere else. That sounds obvious and in practice is not, because the secret half of a key is displayed exactly once on most exchanges and therefore gets parked somewhere in a hurry.

That parking is the problem. A text file on the desktop, a message to yourself, a screenshot in your photo library: all three are unencrypted, are frequently backed up automatically, and therefore end up in systems nobody considered at the moment of creation.

Two rules avoid most of these cases. First, keys and passphrases go straight from the exchange interface into the password manager, and from there into the software that needs them. Second, if the secret half does get copied somewhere anyway, that is a reason to delete the key and create a new one rather than to tidy up.

Independently of all that: no legitimate provider asks you in a chat or a message for the secret half of a key, for your passphrase, or for a two factor code. A request like that is not an exception even when it comes with a plausible explanation attached.

How do you spot unauthorised access early?

Through deviations you only notice if you know what normal looks like. Three sources help, and they complement each other.

• Exchange notifications about sign ins, new keys and withdrawal requests. Those settings belong switched on even if they feel noisy at first.
• Your own key list reconciled regularly against the overview in the exchange interface. A key listed there and missing from yours is the single most important finding available.
• Your journal as an independent cross check. An event that appears in the account but not in your own planning shows up during reconciliation.

That third point is rarely treated as a security measure, but it is exactly that. Anyone reconciling their trades daily already holds a second view of the account that does not originate from the exchange itself.

Which two factor method makes sense?

The methods differ substantially in how much they withstand, and the difference outweighs the convenience they cost.

A hardware security key is the strongest widely available option, because the confirmation is bound to the real address of the site and will not work on a replica. That exact case, a convincing fake sign in page, is the single most common attack pattern there is.

An authenticator app producing time based codes is the workable alternative and far better than nothing. It does not, however, protect you from typing the code into a replica page.

Confirmation by text message is the weakest option, because it is tied to a phone number rather than to you. Where an alternative exists, take it.

Whichever method you use: recovery codes belong somewhere that is not the same device. A second factor whose emergency codes sit inside the same phone is not a second factor when it counts.

Why use a withdrawal allowlist?

Because it secures the last stage. Even if someone gains access to the account, funds can only go to addresses entered beforehand, and adding one typically carries a waiting period.

That waiting period is not a drawback but the entire point. It creates a window in which unauthorised access can be noticed before funds leave the account.

So set the list up while nothing has happened, and keep it short. Any address you no longer need should come off. And plan withdrawals so the waiting period does not get in your way the first time you actually need one.

What do you do if a key is exposed?

Order decides the outcome, because the first two steps have effect while the later ones only establish what happened.

1. Delete the key rather than merely changing its rights. Deletion takes effect immediately and completely.
2. Check withdrawals and review the allowlist. An address you do not recognise there is the most urgent item on the list.
3. Change the password and end active sessions as far as your exchange supports it.
4. Review every remaining key, because an exposed key rarely appears on its own.
5. Notify the exchange and document the sequence with timestamps.

Only after that comes the question of how it happened. It matters, but it holds nobody up.

What does this have to do with your journal?

More than it first appears. A journal drawing its data through an integration depends on that integration working, and every security measure can interrupt one. A rotated key, a changed network address, a frozen account: in all three cases data goes missing unless you hold it elsewhere.

So every security measure deserves a look at the completeness of your records afterwards. A crypto trading journal with a full history is the only body of data that outlives a suspended or closed exchange account.

Check as well whether the integration genuinely caught up after a rotation. Missing events otherwise only surface once metrics stop reconciling, for instance with the funding payments described in funding rates explained, or with the separation between spot and derivatives covered in crypto futures vs spot.