1 What a Passkey Actually Is — Without the Metaphors
A passkey is a pair of cryptographic keys. When you create a passkey for a website, your device generates a private key that never leaves the device (or your iCloud Keychain, encrypted end-to-end) and gives the website only a public key. When you sign in, the site sends a challenge; your device signs it with the private key; the site verifies the signature with the public key. At no point does a secret travel over the network, and nothing reusable is stored on the server. This design kills two entire classes of attack at once. Phishing dies because the sign-in is bound to the genuine domain: a passkey created for paypal.com simply cannot be used on paypa1-secure-login.com, because the browser refuses to offer it — the credential and the origin are cryptographically linked, not judged by a human reading a URL. Password reuse dies because every site gets its own independent key pair; there is nothing to reuse and nothing to leak from a breached database except a public key, which is useless to an attacker. For accounts where you have enabled passkeys — including your Apple Account itself, which uses passkey-style device authentication — the old attacks of keylogging, credential stuffing, and database leaks stop working entirely.
通行密钥到底是什么——不打比方
通行密钥是一对加密密钥。当你为一个网站创建通行密钥时，设备生成一把永不离开设备（或端到端加密的 iCloud 钥匙串）的私钥，只把公钥交给网站。登录时，网站发送一个挑战；设备用私钥签名；网站用公钥验证签名。任何时刻都没有秘密在网络上传输，服务器上也不会存储任何可重用的东西。这个设计同时消灭了两类攻击。钓鱼失效，因为登录与真实域名绑定：为 paypal.com 创建的通行密钥无法在 paypa1-secure-login.com 上使用，因为浏览器拒绝提供它——凭据与源站在密码学上关联，而不是靠人眼读 URL 判断。密码复用失效，因为每个网站都有独立的密钥对；无物可复用，被拖库的数据库里也只有公钥，对攻击者毫无用处。对于启用了通行密钥的账户——包括你的 Apple 账户本身，它使用的就是通行密钥式的设备认证——键盘记录、撞库、数据库泄露这些老攻击手段完全失效。
A clear explanation of how passkeys work on Apple devices, why they eliminate phishing and password reuse, where they fall short, and a realistic migration plan for 2026.
讲清通行密钥在 Apple 设备上的工作原理、为何能消灭钓鱼和密码复用、短板在哪，以及一份务实的 2026 迁移计划。
2 The iCloud Keychain Trade-Off: Convenience Meets a Single Point of Failure
On Apple devices, passkeys sync through iCloud Keychain by default. This is the right choice for most people: your passkeys appear on every signed-in iPhone, iPad, and Mac instantly, protected by end-to-end encryption that even Apple cannot read. The trade-off is that your Apple Account becomes the master key to your whole digital life. Whoever controls the Apple Account controls every passkey synced to it — which raises the stakes on everything discussed in our account recovery guide: your trusted phone numbers, your recovery contact, your password hygiene. Two mitigations matter. First, protect the Apple Account itself with the strongest available options: a long unique password, two-factor authentication, and consider a hardware security key for the Apple Account sign-in, which blocks even SIM-swap-based interception. Second, keep at least one device offline-backup-capable: export and print 2FA backup codes for your most critical services (email, banking, password manager) and store them on paper, because paper is the one storage medium no attacker can reach remotely and no lockout can take from you. Users who treat the Apple Account as 'just another login' are the ones who lose everything at once when it is compromised.
iCloud 钥匙串的取舍：便利遇上单点故障
在 Apple 设备上，通行密钥默认通过 iCloud 钥匙串同步。对多数人这是正确选择：通行密钥立刻出现在每台已登录的 iPhone、iPad 和 Mac 上，受端到端加密保护，连 Apple 也无法读取。代价是 Apple 账户成为整个数字生活的主钥匙。控制 Apple 账户的人就控制了同步到它上面的每个通行密钥——这提高了账户恢复指南中讨论的一切的赌注：受信任号码、恢复联系人、密码习惯。两个缓解措施很重要。第一，用最强选项保护 Apple 账户本身：长且唯一的密码、双重认证，并考虑为 Apple 账户登录配备硬件安全密钥，它连基于换卡攻击的拦截也能挡住。第二，保留至少一种可离线备份的能力：为最关键的服务（邮箱、银行、密码管理器）导出并打印两步验证备份码存在纸上，因为纸是攻击者无法远程触及、锁定也无法夺走的唯一存储介质。把 Apple 账户当成'又一个普通登录'的用户，一旦它被攻破就会一次失去全部。
3 Where Passkeys Fall Short Today
Honesty about limits avoids false security. First, adoption is uneven: many banks, government services, and regional services still offer only passwords, so you will run a hybrid setup for years — which means password manager hygiene remains necessary, not optional. Second, cross-ecosystem recovery is awkward: a passkey created in iCloud Keychain on an iPhone is hard to move to a non-Apple password manager; Apple supports exporting, but not every destination imports cleanly, and shared passkeys in family situations (streaming accounts, utility logins) remain clunky compared to sharing a password. Third, the recovery path for a lost device plus lost Apple Account access is exactly the account recovery process described elsewhere in this guide series — passkeys do not bypass it, they inherit it. Fourth, physical device loss is still a real scenario: if your iPhone is stolen and unlocked, the thief can use passkeys on it; biometric prompts (Face ID) mitigate this, which is why you should always require biometrics for keychain autofill rather than device passcode fallback where possible. None of these shortcomings outweigh the benefits; they simply define the residual checklist: keep the password manager updated, keep recovery contacts set, enable biometric locks, and treat 'passkey supported' as a reason to upgrade an account, not a reason to stop thinking.
通行密钥目前的短板
对短板诚实才能避免虚假安全感。第一，采用不均衡：许多银行、政府和地区服务仍只支持密码，因此混合使用将持续多年——这意味着密码管理器的好习惯依然必要而非可选。第二，跨生态恢复别扭：在 iPhone 的 iCloud 钥匙串中创建的通行密钥很难迁移到非 Apple 密码管理器；Apple 支持导出，但不是每个目的地都能干净导入，家庭共享场景（流媒体、水电账务账户）的通行密钥共享仍比共享密码笨拙。第三，设备丢失加 Apple 账户失联时的恢复路径，正是本系列其他文章描述的账户恢复流程——通行密钥不会绕过它，而是继承它。第四，设备物理丢失仍是真实场景：如果 iPhone 被偷且处于解锁状态，小偷可以使用上面的通行密钥；生物识别提示（面容 ID）能缓解，这就是为什么应尽可能要求钥匙串自动填充使用生物识别而非回退到设备密码。这些短板都不足以抵消收益；它们只是定义了剩余清单：保持密码管理器更新、设置好恢复联系人、启用生物识别锁，并把'支持通行密钥'当作升级账户的理由，而不是停止思考的理由。
"Honesty about limits avoids false security."
「对短板诚实才能避免虚假安全感。」
4 A Realistic 2026 Migration Plan
Migrate in order of value, not alphabetically. Tier one — do this month: your primary email (it resets everything else), your password manager, your Apple Account security settings, and your bank. These four control all downstream damage; for each, enable the passkey option where offered and immediately reduce the password to a backup method. Tier two — do this quarter: social and messaging accounts (they are hijacked for scamming your contacts), cloud storage, and payment apps. Tier three — as you encounter them: shopping sites, media subscriptions, everything else; a practical trigger is to upgrade an account to a passkey the next time you sign in, rather than dedicating a weekend to it. Throughout, keep one rule: never delete the old password until the passkey has been used successfully at least twice, once on each of your primary devices — some sites create passkeys that later fail on specific browsers, and you want to discover that while the password still exists. Finally, once a service's passkey works everywhere you use it, remove saved passwords for that service from any plaintext locations: browser autofill on a shared computer, notes apps, spreadsheets. Migration is complete not when everything has a passkey, but when nothing important depends solely on a password.
务实的 2026 迁移计划
按价值排序迁移，不要按字母顺序。第一梯队——本月完成：主邮箱（它能重置其他一切）、密码管理器、Apple 账户安全设置、银行。这四项控制所有下游损失；对每一项，在提供通行密钥的地方启用，并立即把密码降级为备份手段。第二梯队——本季度完成：社交和聊天账户（它们被盗用后会被用来诈骗你的联系人）、云存储、支付应用。第三梯队——遇到再说：购物网站、媒体订阅和其他一切；实用触发器是下次登录时顺手升级该账户，而不是专门花一个周末。全程遵守一条规则：在通行密钥至少成功使用两次（每台主力设备各一次）之前，不要删除旧密码——有些网站的通行密钥后来会在特定浏览器上失败，你要在密码还在时发现这一点。最后，当某项服务的通行密钥在你使用的所有地方都正常后，把该服务的密码从所有明文位置删除：共享电脑上的浏览器自动填充、备忘录应用、电子表格。迁移完成的标准不是一切都有通行密钥，而是没有任何重要账户仅靠密码。
5 Passkeys and Your App Store Purchase Safety
Connect this back to the purchase safety topics this site focuses on. Most fraudulent App Store purchases do not start with a cracked password — they start with a phished one: a fake 'Apple ID suspended' email, a sign-in page on a lookalike domain, a password typed once into the wrong hands. Because passkeys cannot be phished, they close the front door on the majority of account-takeover purchases, unauthorized family-sharing charges, and subscription hijacks we describe in other guides. What passkeys do not change: purchases made by someone who has your unlocked device, social-engineered App Store gift card payments, and 'legitimate-looking' scam apps that bill through proper channels — for those, the defenses remain the ones we cover throughout this site: Screen Time purchase restrictions, Ask to Buy for children, reviewing purchase history weekly, and understanding refund windows. Think of it as layering: passkeys protect the account perimeter; purchase settings protect the money once the perimeter is crossed; refund knowledge is the recovery net when both fail. Users who deploy all three layers report, in our experience mapping scam patterns, almost no unresolved financial loss — each layer catches what the previous one misses.
通行密钥与应用商店购买安全的关系
把这些与本站关注的购买安全主题联系起来。多数欺诈性 App Store 消费并非始于被破解的密码，而是始于被钓走的密码：一封假'Apple ID 已停用'邮件、一个仿冒域名上的登录页、一次输入错手的密码。由于通行密钥无法被钓鱼，它们关上了大多数账户接管型消费、未授权家庭共享扣费和订阅劫持的正门，正如我们在其他指南中描述的那样。通行密钥改变不了的：拿到你已解锁设备的人进行的购买、被社会工程诱导的 App Store 礼品卡支付，以及通过正规渠道扣费的'看似合法'诈骗应用——对付这些，防线仍是本站反复讲的：屏幕使用时间购买限制、儿童的购买前询问、每周查看购买记录、理解退款窗口。可以把它想成分层：通行密钥保护账户外围；购买设置保护外围被突破后的钱；退款知识是前两者都失守时的补救网。根据我们梳理诈骗模式的经验，三层齐备的用户几乎没有无法挽回的经济损失——每一层都接住上一层漏掉的。