암호화폐 거래소 계정 보안 감사: 패스키, 피싱 방지 코드와 출금 보호

Method and snapshot boundary

The capture time for this package is 2026-09-10T17:55:00Z. The sample is intentionally limited to the six centralized venues already covered in NexuAlpha's current exchange universe for this article: Binance, OKX, Coinbase, Kraken, Bybit and Bitget. The scope is account-level security documentation, not corporate custody, proof-of-reserves, wallet architecture, insurance, regulatory status, incident history, or phishing-domain takedown operations.

The audit reviewed official public sources only. The source set includes help-center, support, security, account-protection and academy pages. The categories were selected because they are directly relevant to an ordinary user deciding whether to use a venue, deposit funds, save withdrawal addresses or upgrade login protection: passkeys or 2FA, anti-phishing codes, withdrawal-destination restrictions, device or session review, time locks or delayed withdrawals after sensitive changes, and recovery boundaries.

Each cell in the matrix means "found in captured official public documentation." It does not mean the control is available in every jurisdiction. It does not mean the control is on by default. It does not mean the control is correctly configured. It does not mean the venue's internal system will catch a compromised device, a coerced withdrawal, a SIM-swap attack or a malicious browser extension. Public documentation is one layer of diligence. The next layer is a logged-in check inside the user's own account before assets move.

There is also an access limitation worth naming. Command-line checks returned HTTP 200 for OKX, Kraken and Bitget pages, HTTP 202 for Binance support pages, and HTTP 403 for some Coinbase and Bybit pages. Browser-indexed text for those Coinbase and Bybit pages was still accessible during the research pass. We therefore use the official page text, but we do not treat command-line fetch behavior as a security signal about the exchange. It is a content-access limitation, not an account-protection finding.

The disclosure matrix

What the matrix says, and what it does not say

The cleanest reading is that each venue has at least one public path for stronger login verification. The terms differ. Binance uses a passkey-required function for important scenarios. OKX describes passkeys and hardware security keys. Coinbase places passkeys alongside security keys, authenticator apps, trusted contacts, push notifications and SMS. Kraken treats passkeys as a 2FA method and recommends them over other 2FA methods. Bybit and Bitget both put passkeys inside broader account-protection programs.

That does not make the passkey row a commodity. A passkey can be used for sign-in, step-up verification, withdrawal approval, Pay mode, account recovery, or some combination of those flows depending on the venue and product. A synced passkey stored in a platform account is not operationally the same as a hardware security key stored offline. A user can also create an accidental single point of failure if they add one passkey and remove every backup path. The public pages give the vocabulary; the user's account screen decides the actual configuration.

The anti-phishing row is more differentiated. Binance, OKX, Bybit and Bitget clearly document an anti-phishing code. This is not magic protection against all social engineering. It is a user-chosen marker that appears in official communications after setup, so the user can spot messages that do not carry the expected code or carry the wrong one. It helps most when the user actually checks it before clicking. It helps less against phone calls, fake ads, poisoned search results, screen-sharing scams, compromised email accounts or malware that reads the genuine email.

Coinbase and Kraken should not be marked as "unsafe" because this captured set did not find a branded anti-phishing-code feature. That would be a lazy conclusion. The correct conclusion is narrower: in the captured official pages, Coinbase and Kraken emphasized other protections, including 2-step verification, security keys or passkeys, email hygiene, official sign-in paths, account lock, Master Key and GSL-style settings. For a user comparing documentation, the anti-phishing-code cell remains "not found in captured pages," not "absent from the company forever."

The withdrawal-control row is where many users should slow down. Login security protects the front door. Withdrawal controls protect the exit path. If an attacker enters an account, the next question is whether the attacker can add a new address, disable a control, bypass an address book or push a withdrawal immediately. Binance's whitelist withdrawal limit, Kraken's GSL, Bybit's address-book and new-address lock, and Bitget's withdrawal whitelist and cross-device verification all speak to that exit-path problem.

Coinbase's captured consumer pages were different. They documented account locking, device sign-out, disabled transfers while locked and a 24-hour send pause after unlocking. Those are meaningful protective disclosures, especially after suspected compromise. But they are not the same as a general withdrawal-address whitelist in the captured consumer help pages. A user who wants destination restrictions on Coinbase should confirm the exact account type and product flow inside Coinbase before relying on it.

Binance: broad public checklist plus withdrawal-specific controls

Binance has the most checklist-like public disclosure in this sample. Its account-security tips page names password hygiene, 2FA, passkeys or authenticator apps, anti-phishing code, withdrawal address whitelist, account activity logs and API-key hygiene. That makes the page useful for a fast user checklist. It also creates a clear editorial risk: a checklist can make a user feel done before each item is actually configured.

The more important Binance source for this audit is the withdrawal-settings page. It states that users can enable a withdrawal whitelist so withdrawals are restricted to whitelisted addresses. It also documents address management, address labeling, network selection, one-step withdrawals and a whitelist withdrawal-limit function. The time-window disclosure matters because delay is the control that gives a user a chance to react after a suspicious address change. Binance lists 24, 48 and 72-hour options around newly added whitelist addresses.

The passkey-required page is also operationally important. Binance says the function can require passkey verification for login and withdrawal. It also warns that losing access to passkeys can prevent login. That is not a reason to avoid passkeys; it is a reason to build a recovery plan before depending on one. A high-value account should not be protected by one fragile device with no tested fallback.

The finding for Binance is therefore "clear disclosure across the inspected categories," with one caveat: the article did not log in, did not test defaults and did not verify regional availability. Users still need to confirm whether withdrawal whitelist, passkey-required verification, one-step withdrawal and whitelist-delay settings are available and enabled in their own account.

OKX: strong passkey and anti-phishing documentation, narrower withdrawal detail in this capture

OKX's captured public pages are strong on passkey mechanics. The web passkey guide covers creating, verifying, renaming and removing passkeys. It also warns that removing a passkey without another passkey verification can trigger a 24-hour restriction on withdrawals and P2P trading. The physical-security-key page explains that hardware keys can be used for passkey-based authentication and for identity verification during logins, withdrawals and sensitive operations.

The account-security guide adds mobile verification, face verification and anti-phishing code. That combination gives OKX a clear passkey/2FA row and a clear anti-phishing row. It also shows that OKX separates different security contexts: phone or mobile confirmation, biometric/face checks, passkeys, and hardware-key workflows.

The narrower finding is around withdrawal-destination controls. In the captured set, OKX documentation was clear that withdrawals can involve security verification and that passkey removal can trigger withdrawal restrictions. It did not, in this article's captured sources, provide a full withdrawal-address whitelist walkthrough comparable to Binance's withdrawal-settings article or Bybit Protect's withdrawal-security list. That does not prove OKX lacks address controls; it means this particular public-source set did not support a stronger claim.

For users, the practical OKX check is straightforward: before depositing material funds, open the OKX security center and withdrawal settings in the logged-in account. Confirm whether passkeys, hardware keys, anti-phishing code, mobile verification, withdrawal address controls and any delay windows are enabled for the exact region and product being used.

Coinbase: excellent 2-step and lockout documentation, fewer destination-control signals in captured consumer pages

Coinbase's captured pages are unusually explicit about 2-step verification options. The 2-step verification page covers security keys, passkeys, trusted contacts, authenticator apps, push notifications and SMS. It also frames security keys and passkeys as stronger options than SMS. The page is useful because it explains recovery-adjacent choices, including trusted contacts, instead of only telling users to add an authenticator.

The account-security page reinforces the same direction: use a strong password, secure the email account, prefer a security key or passkey for 2-step verification, enable mobile PIN or biometric protection, and keep devices clean. The compromised-account page adds a separate emergency control. If the account is locked, Coinbase says the user can still sign in and review information, but trading, crypto transfers and account-setting changes are paused. It also says locking signs out devices and that crypto sends are paused for 24 hours after unlocking.

That is strong disclosure around login protection, recovery and post-compromise containment. The missing piece in the captured consumer pages is a general withdrawal-address whitelist or branded anti-phishing-code feature. Coinbase may expose different controls in institutional, Prime, Vault or other product contexts, and the broader Coinbase ecosystem has product-specific address-book ideas. This article deliberately does not import those into the consumer account-security cell unless the captured consumer pages support it.

The user lesson is not "Coinbase is weak." The user lesson is "check the product surface." A Coinbase.com user, a Coinbase Advanced user, a Coinbase Prime client and a wallet user may face different controls. Before moving funds, the user should confirm 2-step method priority, trusted contacts, device access, account-lock path, send restrictions and any destination-control options in the exact product they use.

Kraken: layered 2FA, Master Key and GSL are the center of the story

Kraken's documentation has a distinctive architecture. It does not simply say "enable 2FA." It separates sign-in 2FA, trading 2FA, funding 2FA, step-up 2FA, Master Key and Global Settings Lock. That makes the documentation more complex, but also more precise.

The funding 2FA page contains one of the most important warnings in the sample: withdrawal 2FA requires a code for withdrawing funds, but it does not prevent adding cryptocurrency withdrawal addresses. Kraken says the user needs Global Settings Lock for that. This is exactly the kind of distinction that prevents false confidence. A user might believe "withdrawal 2FA" protects the entire withdrawal path. Kraken's documentation narrows the claim: it protects withdrawal action, while address-addition protection depends on GSL.

The securing-your-account page adds the Master Key and GSL story. It says GSL can prevent changes to account settings and withdrawal addresses, even after account access is compromised. It also warns that Support cannot speed up GSL removal. That warning is not a weakness. It is the cost of a lock. Strong locks are useful because they create friction, and the friction also affects the legitimate user.

The withdrawal-address article adds operational detail. It says GSL blocks adding a withdrawal address. It says trusted devices can approve new addresses automatically, while other cases may require email confirmation. It also states that a withdrawal approval link is valid for one hour and that, after some password changes without sign-in 2FA or Master Key, withdrawals to new addresses can be held for 12 hours. Kraken's disclosure is therefore strong for users who are willing to understand the layered model.

Bybit: Bybit Protect creates a broad account-protection menu

Bybit's account-security disclosure is broad and easy to map. Bybit Protect groups protections into basic, advanced and scenario-based categories. The captured pages name email/SMS authentication, Google 2FA, anti-phishing code, passkey, Secure Transaction Approval, fund password, withdrawal-address whitelist, withdraw via address book, new-address withdrawal lock and withdrawal limits.

The passkey page gives concrete setup boundaries: supported operating systems and browsers, adding passkeys, managing names and deleting passkeys. It also says users can create a maximum of 10 passkeys and that removing a passkey can trigger a 24-hour withdrawal restriction. That is useful both for setup and for recovery planning. A user can see that passkeys are not just an abstract security slogan; they have device, browser and lockout consequences.

The anti-phishing page is direct. Bybit says the code appears in official emails and SMS after setup. Its phishing guidance also says missing or incorrect codes should be treated as suspicious. Bybit's account-security guide adds trusted-device management and account deactivation for suspicious activity, which gives the device/session row stronger support than many generic security pages.

The main caveat is again not about the existence of controls. It is about account state. Bybit may tailor prompts, review flows, withdrawal restrictions, EDD requirements or risk controls by account, region and transaction. A public Bybit Protect menu is a good map. It is not a substitute for checking the logged-in account before the first large withdrawal.

Bitget: fund code, cross-device verification and 24-hour holds stand out

Bitget's public material is also broad. The account-security best-practices page covers passkeys, fund code, PIN code, anti-phishing code, cross-device withdrawal verification, a cancel-withdrawal toggle and trusted-device management. That gives Bitget clear cells for passkey/2FA, anti-phishing, withdrawal control and device review.

The fund-code detail is worth separating from ordinary login 2FA. Bitget describes fund code as a passcode used for actions like setting up or modifying 2FA and making withdrawals. That means the account has an additional action-specific credential concept. Whether that is valuable in a user's account depends on setup quality, recovery paths and actual enforcement, but the disclosure itself is clear.

The cross-device withdrawal-verification detail is also practical. Bitget describes it as a way to confirm a withdrawal address on the mobile app when withdrawing on the website, designed to reduce unauthorized address changes caused by traffic hijacking. Bitget also says the cancel-withdrawal toggle is enabled by default and allows withdrawal cancellation within one minute after initiation. The one-minute window is narrow, but it is a concrete emergency detail that users can understand and test with tiny amounts.

The academy security guide adds the time-delay pattern. Bitget discusses 24-hour holds after changing phone, email, authenticator, password or fund code. The Google Authenticator page also says login, withdrawals and sensitive changes can require authenticator verification and reminds users to save a backup key. Together, these pages show that Bitget's public disclosure emphasizes layered account credentials, device review and short withdrawal-friction windows.

How users should apply the audit before moving funds

The matrix should be used as a pre-deposit checklist, not as a scoreboard. A sensible user can run the same workflow on any venue.

First, upgrade sign-in protection. Prefer passkeys or hardware security keys where available, and keep a tested backup method. Avoid relying on SMS alone for a high-value account. If a venue lets the user have multiple passkeys, add more than one trusted device or security key before removing old methods.

Second, protect communications. If the venue supports an anti-phishing code, set it and then actually check it. If the venue does not disclose a branded anti-phishing code in the captured pages, strengthen the email account, bookmark the official sign-in route, avoid search ads for login, and verify suspicious messages through official support paths.

Third, control the exit path. Look for withdrawal whitelist, address book, trusted addresses, Global Settings Lock, new-address lock, cross-device withdrawal confirmation, fund password and withdrawal limits. The most important question is not "can I withdraw fast?" It is "can a new destination be added and used immediately after compromise?"

Fourth, learn the recovery cost before it is needed. A strong setting can slow attackers, but it can also slow the real user after a phone change, lost passkey, lost authenticator, password reset or emergency account lock. Read the reset and lockout pages while calm. Save backup codes or backup keys where the venue provides them. Keep the email account and cloud account secured because many recovery flows depend on them.

Fifth, test small. Before depositing a large balance, make a tiny deposit and a tiny withdrawal to a saved address. Confirm the prompts, delays, emails, device notices and cancellation paths. This audit can tell you what the public pages disclose. Only a small real test in your own account can reveal the actual control sequence you will face.

Known unknowns

No logged-in accounts were used. That means defaults, account-tier differences, jurisdiction-specific rules, app-version differences and actual user-interface placement were not verified. Some controls may appear only after KYC, after enabling another method, after app installation, in a specific product, or in regions where the feature is available.

No security strength was measured. We did not test phishing resistance, malware resistance, customer-support identity checks, account-recovery abuse, session hijacking, withdrawal policy enforcement, sanctions screening or chain-risk engines. A venue can write good docs and still have bad enforcement. A venue can have strong internal controls and still document them poorly.

No incident inference was made. This article does not say that a venue with more disclosed controls has fewer compromises. It also does not say that a venue with a missing public cell lacks internal protections. It says only what was supported by captured official pages at a fixed time.

The public web itself is not stable. Help-center pages can change, redirect by region, hide sections behind scripts, return different text to different clients, or block command-line access. That is why this package records accessedAt values and keeps source IDs next to claims.

FAQ

Which exchange had the clearest public account-security disclosure?

For a broad public checklist, Binance, Bybit and Bitget were easiest to map across the most cells. Kraken was very strong on layered control logic, especially the distinction between funding 2FA and Global Settings Lock. Coinbase was clearest on 2-step options and account-lock recovery. OKX was clearest on passkey and physical-security-key workflows in the captured set.

Do all six exchanges support passkeys?

The captured official pages for all six venues disclose passkeys, security keys or hardware-key style authentication. The scope differs. Some pages discuss passkeys for login, some for withdrawals, some for step-up checks and some for product-specific payment or wallet flows. Users should confirm the exact use case inside their account.

Do all six exchanges disclose anti-phishing codes?

No. Binance, OKX, Bybit and Bitget explicitly document anti-phishing codes in the captured public pages. Coinbase and Kraken did not show a branded anti-phishing-code feature in the captured consumer/security pages used for this audit, though both document other email, phishing and account-protection practices.

Is withdrawal 2FA the same as a withdrawal whitelist?

No. Withdrawal 2FA asks for an extra code or device confirmation when a withdrawal action happens. A withdrawal whitelist or address-book restriction limits where funds can go. Kraken's documentation makes this distinction especially clear by saying funding 2FA does not prevent adding withdrawal addresses and that Global Settings Lock is needed for that address-change protection.

Should users choose an exchange based only on this audit?

No. This audit is one input. Users should also compare fees, liquidity, supported assets, regulatory fit, proof-of-reserves evidence, withdrawal history, customer support, tax needs, country availability and personal threat model. Most importantly, they should verify the actual controls in their own logged-in account before moving meaningful funds.

Claim-source mapping

• c1: All six sampled venues publish account-security guidance, but the audit measures public documentation clarity only. Sources: Binance security tips, OKX account security, Coinbase 2-step verification, Kraken 2FA, Bybit Protect and Bitget security best practices.
• c2: All six venues disclose passkey, security-key or 2FA controls. Sources: Binance passkey-required, OKX passkeys and hardware-key pages, Coinbase 2-step verification, Kraken 2FA, Bybit passkey and Bitget security best practices.
• c3: Binance, OKX, Bybit and Bitget explicitly document anti-phishing codes; Coinbase and Kraken did not show that branded feature in the captured pages. Sources: Binance security tips, OKX account security, Coinbase secure account, Kraken secure life, Bybit anti-phishing and Bitget security best practices.
• c4: Binance, Kraken, Bybit and Bitget disclose withdrawal-destination controls; Coinbase's captured consumer pages instead support account lock and transfer-disable claims. Sources: Binance withdrawal settings, Coinbase lock account, Kraken funding 2FA and add-address pages, Bybit Protect/account security and Bitget security pages.
• c5: Time locks differ by venue. Sources: Binance withdrawal settings, Coinbase lock account, Kraken add-address, Bybit passkey/account security and Bitget advanced security.
• c6: Device/session disclosures vary. Sources: Binance account activity guidance, Coinbase secure-account and lock-account pages, Kraken secure-life page, Bybit account-security page and Bitget security pages.
• c7: Recovery boundaries matter and are disclosed unevenly. Sources: Binance passkey-required, OKX passkeys, Coinbase 2-step/lock pages, Kraken secure-life, Bybit passkey and Bitget Google Authenticator guidance.
• c8: Logged-in verification remains necessary. Sources: the full official source set and the article methodology.