大多数浏览器和
Developer App 均支持流媒体播放。
-
无需密码仍可操作
虽然密码被广泛使用,但它天生就有棘手之处,很难适应保护用户在线帐户的情形。详细了解密码对现代安全性带来的挑战,以及怎样才能不使用密码进行操作。通过采用 Web 认证标准的安全设计、基于公钥的凭证来探索帐户安全的新前沿。在此技术预览中了解 Apple 如何在 iOS 15 和 macOS Monterey 中实现这一 标准。
资源
- 2020 Data Breach Investigations Report
- Connecting to a service with passkeys
- Supporting passkeys
- Supporting Security Key Authentication Using Physical Keys
相关视频
WWDC21
-
下载
♪播放重低音音乐♪ ♪ 嗨 我是盖瑞特 验证体验团队的工程师 我很兴奋地向你介绍 我们这段时间的工作成果 Apple踏出第一步 协助整个产业脱离使用密码 现今当你登入App或网站时 你应该会需要输入密码 经典的用户名称加上密码的组合 立即可让人理解而且使用便利 大部分的人即刻就知道该怎么做 在这种状况出现的时候 但开发人员、使用者 以及整个产业 集体意识到这个伟大的便利措施 让我们能快速验证身份 登入账号 会对账号安全带来不利的影响 这些年来验证技术有了长足的进步 这个产业 学习到不少关键教训 首先 守密很困难 特别是共享的秘密 现今大部分的验证流程依赖用户 在建立新账号的时候与服务器共享 一个秘密“一组密码” 在每一次验证时 再分享一次这个秘密 每当秘密被分享一次 就会产生风险 让非目标接受者 知道那个秘密 网络钓鱼 例如假电邮、及假电话 或是误导性网站 是最常见的 恶意的一方取得他人秘密的方式 当一个如密码这样的秘密被发现之后 使用强度低的密码 或重复使用同一组密码 于不同的账号 会让问题的严重性在短时间内加剧 事实上 根据 2020年的Verizon资料外泄报告 与黑客有关的资料外泄当中 超过80% 与暴力攻击身份资料有关 或使用遗失的身份 以及偷来的身份 这些是可以避免的 验证技术持续进步中 试图降低这些风险 最初 密码通常是被记在脑海里 但后来发现大部分的人无法 为每一个账号想出来 或是记住强度高而且特别的密码 密码管理员能够替每个账号 创造强度高且独特的密码 还能侦测出某些类型的钓鱼软件 iCloud Keychain的密码管理员 内建于Apple装置 而且我们让第三方也能通过API 将他们自有的密码管理员 整合进这个系统 服务所有者也可在登入流程上 增加新的步骤 例如需要密码搭配一个额外因子 例如一个OTP 例如SMS 或是生成一个一次性验证码 macOS Monterey以及iOS 15 甚至有一个编码生成器 内建于iCloud Keychain上的 密码管理员 更进一步的资料 请观赏 由我同事艾琳所主持的影片 “使用 iCloud Keychain 验证编码安全登入” 有些App以及网站选择 通过同盟验证这种方式 将整个验证流程 发包给第三方 例如登入Apple 同盟验证把我们的秘密 交给一小群 具有高度安全性的账户保管 但在这部影片当中 我将会聚焦于 非同盟验证选项 比较它们之间的异同 它们的操作都很简单 在大部分的装置上都能使用 或多或少它们永远与你同在 但具有更强的安全性 能被人脑记住的密码 对于各个账号来说 大概强度都不够而且不够独特 可以使用密码管理员 创建强度高且独特的密码 但它的强度仅止于密码本身 及额外因子潜在性能够 提供的安全强度 一次性的编码也有帮助 但仍然会有密码会遇到的 问题 因为他们都是可输入的 可上勾的、可被分享的秘密 还有 如果密码存在于脑海中 你有可能忘记 这表示App或是网站需要分离式的 复原流程 在今日通常是一封电邮里的一个连结 这会降低账号整体的安全性 至邮件提供商同样的程度 通常不在你的控制之中 有些密码管理员以及第二因子验证 能够协助复原 但仍有类似问题 记在脑海的密码也无法 抵抗钓鱼程序 密码管理员能够侦测到钓鱼程序 例如遇到钓鱼网站时 不会出现输入密码的画面 尽管网站看起来像真的 但它们无法阻止有人 使用人工输入密码 使资料外泄 一次性编码也有类似问题 尽管现今有一些应变方案 可供使用 最后 这些方式 皆需要用户与伺服间分享秘密 让它们的保护力道 与那些依赖秘密分享的方式 没什么不同 知道这些信息之后 让我们来看看能够真正解决 密码问题的方案有什么特色 首先 取代密码的方式 在设计上就得具有安全性 密码具有一定程度的安全强度 如果严守最佳操作步骤 然而 经验告诉我们 要大家每次 都能遵守这些要求是很困难的 取代密码的方案需要在一开始 就将这种安全性建立起来 但我们仍想保有相同的操作便利性 密码能够长久存在 是因为它们容易操作 我们不想失去这个特性 操作便利包含了随时可取得 以及能在各处取得 今日 只要我知道 或能够查询到我的密码 我等于就能够确认我想登入的装置 能够接受 新装置的验证流程如果复杂度提升 将会对普及度 造成负面影响 因为大家只想迅速登入 最后 复原流程应该有最高等级水平 而不是事后想到才加上 人会犯错 坏事会发生 这个密码解决方案要能 具有足够容错度 包容人性常犯下的错误 但又不能降低整体的安全度 目前市面上安全性最高的方案之一是 安全密钥 硬设备如加密锁或密钥卡 即为第二重安全因子 通常会使用在需要高度安全的状况下 它们是以网络认证为基础 或WebAuthn标准 大家皆可使用 经过最初的学习曲线之后 大部分的人都会觉得使用便利 比起单一密码 它们具有更高的安全性 大部分的优势是来自于WebAuthn 稍候我会再进一步介绍 现代的网络浏览器也能支持安全密钥 于现今大部分的装置上 macOS及iOS的Safari能够支持USB NFC 以及Lightning安全密钥 这已经存在一段时间了 大部分的安全密钥也能够支持 一种以上的连线方式 因此一把实体钥匙能够 用于不同的装置 我们来比较WebAuthn及密码 WebAuthn最大的优点之一是 它使用密钥对 而不是共享秘密 我们来检视密码的使用流程 首先你把密码输入 通过加盐哈希的方式 模糊密码 加盐哈希的结果会被送进服务器 现在 你与服务器都有了这个秘密 尽管在服务器上的密码是模糊的 你们具有相同的责任 保护这个秘密 我们就是想摆脱这种状况 通过密钥对取代一组密码 你的装置会创建出一对密钥 其中一个是公开的 就跟你的使用者名称一样 它能够分享给任何人 它不是个秘密 另外一个是私有的 这个私有的密钥是个秘密 被你的装置保护着 你的装置不会将这把密钥 分享给任何人 包括服务器 当你建立一个账号 你的装置会生成这两个对应的密钥 它将公钥分享给服务器 现在 服务器有了这个公开的密钥 它并没有具备与密码同等级的 安全强度 因为它是公开的信息 私有密钥留在你的装置上 只有那个装置有责任保护它 之后 当你想登入时 你无需将任何秘密送进服务器 而是通过证明你的装置 认得这个私有密钥 来证明那是你的账号 因为私有密钥能与公钥对应 这种交换流程是这样的 首先 我先登入我的账号 接着 网站会要求我的装置 证明那是我的账号 它通过“盘问”这个方式来进行 证明我的装置有与公钥 对应的私有密钥 而无需提供我的私有密钥 流程是这样的 服务器送出 一个一次性的盘问 我的装置有这个私有密钥 所以它能接受这个盘问 使用 私有密钥进行“签署”盘问 只有我的私有密钥能够产生 一个能有效 登入我账号的签名 这个签名会被送回服务器 服务器上已经有我的公钥 所以它能够用公钥比对这个签名 任何拥有我公钥的人都能 轻易进行确认 看签名是否与密钥相符 然而 只有我能针对盘问创建出 有效的签名 因为只有我有私有密钥 因此 每个人都能够轻易地 确认我的身份 即使他们不知道我的秘密 最后 假设签名与我的公钥相符 服务器会告诉我 我已成功登入 请注意 我的私有密钥 从来没离开过我的装置 服务器不需要知道我的秘密 就能够确认这是我的账号 不需要知道我私有密钥的内容
因为密钥对 表示身份的创造及管理 都发生在我的装置上 私有密钥从来不曾分享给服务器 当你的服务器被侵入时 这些密钥将永远无法被猜测出来 被重复使用、被削弱 或受损 WebAuthn也将信任的根 扎在浏览器 以及操作系统上 而不是人脑 这个软件严格强制这些身份 只能够在建立出它们的网站 及app上被使用 让别人无法在错误的 网站上试着验证 因为在WebAuthn上的身份 都是密钥对 服务器不再有责任 维护验证秘密 也就表示能够减轻服务器的工作量 因为无需保障秘密的安全 攻击者也比较不想以服务器为目标 因为上面没有任何验证秘密 值得窃取 让我们来比较密钥对 与图表上其它方式的不同 经过一开始的学习曲线之后 它们是相当容易使用的 它们能够使用于你所有的 Apple装置 以及其它现代的非Apple装置 但是它们不见得能够永远在你身边 你必须购买额外的硬件 并且随时携把它带在身上 这会是最初的进入障碍 而且与密码比较起来 在便利性上是倒退一步的做法 然而安全度非常高 在安全密钥上的身份 保证 永远很难被猜到 或是重复使用于不同的账号 而且在OS层级有内建的 防钓鱼程序保护 这种安全强度是需要付出代价的 如果身份被绑在单一的安全密钥上 而该安全密钥一旦遗失了、被偷了 或受损了 上面的身份也会受到影响 使用者必须有一个备份系统 例如购买额外的安全密钥 把它收藏在别的地方 并且祈祷它们不会同时出问题 然而 多亏了WebAuthn 它们的防钓鱼程序的能力很强大 因此不需要将秘密存在服务器上 在iOS 14.5 我们扩展了 安全密钥功能 iOS上的浏览器皆可使用 在macOS Monterey及iOS 15是新功能 我们也首度推出了安全密钥API macOS及iOS上的App皆可取得 这项API亦加入了 AuthenticationServices架构上的 ASAuthorization API 家族 等同于是网络上的WebAuthn API ASAuthorization是你的一次购足商店 不管使用什么登入方式 都能在这里找到系统支持的方式 包括密码、登入Apple 以及现在提到的安全密钥 随身携带额外的硬件 做为安全密钥 不是每个人都需要 我们认为这个API适合用在 需要高强度安全性的App上 让使用者愿意牺牲一些使用便利度 换取更强的安全性 如果你是属于这个族群 见到你使用它 会让我们感到很兴奋 如今 不用密码 改用密钥对的验证方式 是验证技术的下一件大事 标准的建立依赖整个产业的 合作及努力 平台商以及服务商 要有共同目标将账号安全 带往下一个阶段 越来越多地方支持WebAuthn 包括操作系统 App平台、网络浏览器 以及网站 在接下来的影片中 我要讨论的项目 是让我感到很兴奋的内容 是Apple向后密码世界 做出的一项贡献 这项新功能让WebAuthn的安全度 内建于每个iPhone、iPad 以及Mac 因此不管身在何处 都能让它做为密码的替代方案 它就是“passkeys in iCloud Keychain” 这项新功能储存了一种新型态的身份 称为“passkey” 存在你的 iCloud Keychain上 Passkeys是WebAuthn身份 拥有这项标准提供的高度安全性 并且具有很好的使用便利性 包括备份、同步 在你所有的装置上都能使用 它们被存在iCloud Keychain 与iCloud Keychain 所有的储存项目相同 它们是端到端加密 连Apple 都无法理解 你的秘密只有你知道 而且它们很容易操作 在大多数的状况下 只需要轻敲一次、或是点击一次 即能登入 而且比起现今大部分的 密码加上第二因子的方案都要安全 都要归功于WebAuthn及iCloud Keychain结合形成的高强度安全性 因为只需要轻敲一次即能登入 与现今其它的验证方式比起来 它更为便利、快速 以及安全 让我们把这点加上图表 我刚刚说过 它的操作方式十分简单 通常只需要轻敲一次 或点击一次即可登入 我们发布的这项功能属于 macOS Monterey及iOS 15的一部分 能够使用在你所有的Apple装置 当然 为了让每一个人 都能不再使用密码 这项技术必须要能够使用在 你所有的装置上 包括那些不支持 iCloud Keychain的装置 这项功能 macOS Monterey及iOS 15没有提供 因为它内建于 你所有的Apple装置 你只要有iPhone、iPad、Mac 在身旁 就能随时取得 不需要额外的硬件 它建立在WebAuthn标准 及iCloud Keychain提供的 安全保护之上 因为它是建立在iCloud Keychain 即使你遗失了所有Apple装置 仍然能够把身份找回来 它有与平台提供的防钓鱼程序 同样防护力的安全密钥 因为它使用的是密钥对 这表示不再需要服务器 储存验证秘密 让服务器较不容易成为攻击目标 这是它的运作方式 这是Shiny 我们最爱的验证展示app 它的原始码你可以在 与这支影片相关的连结找到 首先 我需要建立我的账号 我将输入我的使用者名称 然后轻敲建立账号钮 接着会出现一份安全的 系统表格 内容是 有关身份以及我可以 将这个身份用在何处 我轻敲继续、脸部辨识 就完成了 我不用多花脑筋 而这个新账号有了高安全强度的 密钥对身份 安全的存在我的iCloud Keychain 当我回来这个App想登入时 也是同样简单 当表单出现时 会出现一个很明确的问题 包含我想要登入的这个App的名称 以及我的账号 这是我要的 所以我轻敲继续 脸部辨识 就完成了 就是这样 这就是建立及使用新身份 需要的步骤 而且因为它们是系统管理的 密钥对 它们不能被重复使用 也无法被猜测出来 当App或网站受到破坏时 它们不会受到影响 而且强大的防钓鱼程序保护 内建于操作系统以及浏览器 说到浏览器 这些身份也能在网络上使用 我现在在Safari上 在Shiny网的主页 它有采用WebAuthn 当我轻敲登入钮 我可以选择使用 刚刚建立的身份 如果我想要的话 也可以使用安全密钥 我轻敲继续、脸部辨识 我便登入成功 跟App一样 所有在iOS上的 网络浏览器App皆可使用 在Mac也可使用 这些身份被储存在iCloud Keychain 所以它们与你所有的装置同步 而且各种Mac app都能使用 在网络上用Safari也可使用 现在 让我们来看看如何实作 首先 为了让平台提供的高强度 防钓鱼保护能够使用在App上 装置上的App及网站 必须有高度关联 可由相关域名完成 使用“网络身份”相关类型 这里不会解释太多细节 想要更进一步的数据 请观赏几年前释出的 “App密码自动填入介绍” 这支影片 接下来 让我们来谈谈建立账号 这里的编码其实相当直接 让我们来拆解说明 创立账号功能需要输入三种内容 服务器抛出的一次性盘问 账号的用户名称 以及用户身份 这通常是后端账号的 标识符 首先 你需要一个需求提供者 来建立需求目标 relyingPartyIdentifier 与你的WebAuthn设定有关 但通常是你的域名 使用这个提供者建立一个注册需求 将这个需求传给验证控制者 最后 在验证控制者上设定委托以及 presentationContextProvider 然后开启你的需求 这会让先前提到的表单弹出 要求你建立一个身份 当交易结束时 你会收到一个委托回呼 上面会有新身份的详细资料 现在 登入的方式与之前很像 只需要改变一些地方 不建立registrationRequest 而是建立assertionRequest 这是在登入时会用到的 WebAuthn专业术语 这个assertionRequest只需要一个盘问 这就是你需要改变的地方 我想要花一点时间强调 验证控制者的参数 是数组 你可以在这里针对你App支持的 各种不同认证机制 输入一串需求 包括密码 以及登入Apple 先前那份表单上面就会出现 目前建立的所有身份 唯一要注意的是公共密钥注册需求 不能与未注册选项混合 好的 那么最后 来谈谈当认证完成时出现的 委托目标回呼 身份属于 所提供的验证对象 如果使用者注册了一个新的平台身份 你会收到一个平台身份注册 如果他们用既有的平台身份登入 你会收到平台身份断言 如果他们用你支持的其它 方式登入 你也能在这里 处理这种状况 不管是何种状况 你需要从身份对象上 读取需要的属性 与你在网络上的作业相同 将这些值送入服务器 验证它们 然后结束操作 这就是它的运作流程 现在 我想再提出一些细节 脱离使用密码需要时间 把细节处理好是很重要的 在macOS Monterey及iOS 15 iCloud Keychain的万能钥匙 已以技术预览被发布了 预设是关闭状态 在iOS上的设定App上的 开发人员设定有一个新的切换钮 将它切换成开启模式 你便能够在App及网站上 使用这些同步密钥 在macOS上 这个切换钮在Safari的 开发菜单上 首先 你需要在Safari的进阶设定 开启开发菜单 你会在Safari偏好设定的 进阶窗格下方 找到这个设定 然后 你能在开发菜单上 找到开启同步平台验证的 选项 请确认在测试的时候 这些功能有被开启 在macOS Monterey以及iOS 15 这些万用钥匙只能用来做测试 不能使用在生产账户上 这个预览的重点 是在于介绍验证技术 在iCloud Keychain备份平台上 实作WebAuthn 整个产业脱离使用密码 将需要缜密且一致性地应用 设计模式 并不是这支影片的介绍范围 最后 既然这是一个概况预览 我们已确认关机时它不会失控 平台注册需求会回复错误 平台断言需求呈现关闭状态下 它会被忽视 即使它与其它身份需求类型 混合在一起 所以接下来你可以这么做 以公钥为基础、能够抵抗 钓鱼程序的身份 是账号验证下一个新领域 请查阅我们的开发人员文件 以及这支影片提供的样本编码连结 做为你的起步 如果你还没有一个这样的身份 请在你的服务器上提出 一个WebAuthn实作 这样你就可以开始试着建立以 WebAuthn为基础的身份 现在 是我最喜欢的部分 请在iCloud Keychain上尝试这个 万能钥匙技术预览版 看看它与你目前在网络及App上 工作流程的契合状况 当你尝试过之后 请在开发人员论坛 及Feedback Assistant留下你们的想法 我们十分希望得到你们的响应 如同我先前说过的 这是取代密码所需的多重努力 其中的第一步 我们十分期待你们的评价 谢谢观赏 ♪
-
-
17:32 - Register an account
// Register an account func createAccount(with challenge: Data, name: String, userID: Data) { let provider = ASAuthorizationPlatformPublicKeyCredentialProvider( relyingPartyIdentifier: "example.com") let registrationRequest = provider.createCredentialRegistrationRequest( challenge: challenge, name: name, userID: userID) let controller = ASAuthorizationController( authorizationRequests: [ registrationRequest ]) controller.delegate = … controller.presentationContextProvider = … controller.performRequests() }
-
17:39 - Sign in
// Sign in func signIn(with challenge: Data) { let provider = ASAuthorizationPlatformPublicKeyCredentialProvider( relyingPartyIdentifier: "example.com") let assertionRequest = provider.createCredentialAssertionRequest(challenge: challenge) let controller = ASAuthorizationController( authorizationRequests: [ assertionRequest ]) controller.delegate = … controller.presentationContextProvider = … controller.performRequests() }
-
17:41 - Handle returned credentials
// Handle returned credentials func authorizationController(controller: ASAuthorizationController, didCompleteWithAuthorization authorization: ASAuthorization) { switch authorization.credential { case let registration as ASAuthorizationPlatformPublicKeyCredentialRegistration: let attestationObject = registration.rawAttestationObject let clientDataJSON = registration.rawClientDataJSON // Verify on your server and finish creating the account. case let assertion as ASAuthorizationPlatformPublicKeyCredentialAssertion: let signature = assertion.signature let clientDataJSON = assertion.rawClientDataJSON // Verify on your server and finish signing in. case …: … } }
-
-
正在查找特定内容?在上方输入一个主题,就能直接跳转到相应的精彩内容。
提交你查询的内容时出现错误。请检查互联网连接,然后再试一次。