FIDO Alliance高级认证工程师就无密码认证进行了访谈
我们的用户要求我们通过Google应用程序实施两因素身份验证。 最近，我们
给了他们这个机会。 大约在同一时间，FIDO Alliance联盟发布了网站，移动应用程序和Web服务（WebAuthn和CTAP）中的无密码身份验证标准。
我们对该主题感兴趣，并
准备了有关Habré的材料 ，在其中讨论了新协议的基础方法。
然后，为澄清有关标准复杂性的一些观点，我们与FIDO Alliance的高级认证工程师Yuri Akkermann（
herrjemand ）进行了交谈。 他回答了我们有关FIDO过去，现在和将来的身份验证的几个问题。 我们提请您注意面试的内容。
/ Flickr / zhrefch / PD请告诉我们您在整个IT领域的背景和经验。 您是如何开始从事该行业的？
从15岁起我就开始编程。 放学后，我去了大学，在那里学习计算机科学和数学。 第二年，我开始对加密，信息安全问题产生兴趣，并对FIDO感到“迷迷糊糊”。 我真的很喜欢他们的协议，最后我为Python Flask编写了一个U2F库并进行了演示。
我的工作受到FIDO的赞赏。 而且，他们只是在寻找认证工程师。 最后，我负责技术认证。
您处理与FIDO身份验证相关的主题已有多长时间了？ 您在制定新标准的过程中解决了哪些任务？
我从事FIDO协议已有三年了-其中两个是FIDO Alliance。 我的主要职责是技术认证和自动化工具，用于测试规范的实现。 我的职责包括开发和支持工具本身，以及编写测试计划-用于检查服务器，客户端和身份验证器的测试列表。 我认为编写测试计划是最耗时的过程，因为它需要了解协议及其中使用的标准的所有复杂性。
我还建议工作组就可能的规格改进，进行演示和撰写文章。
创建新的身份验证标准的想法是如何诞生的？ 您为什么决定全世界和社区在这一领域需要新的解决方案？ WebAuthn打算关闭的现有格式有哪些缺点？
FIDO Alliance由Agnitio，Infineon Technologies，Lenovo，Nok Nok Labs，PayPal和Validity于2013年成立，后者开发了UAF。 不久之后，谷歌，尤比科和恩智浦加入了他们的行列-他们在U2F的前身工作，并认为联合起来有利可图，因为他们的想法与联盟的想法相吻合。 他们试图保护互联网用户免遭网络钓鱼，解决密码的可用性问题，并开发生物识别技术的可访问性和安全性。
是否进行了任何初步的研究，以增强创建标准的意图或促使其创建？ 如果是这样，您分析了哪种数据？
谷歌，微软，三星，尤比科等联盟成员正在积极致力于创建和推广标准。 他们正在探索市场，试图了解FIDO如何“适应”各种生态系统。 例如，谷歌就第二因素从一次性密码到U2F的迁移
进行了研究 。
CTAP协议是如何诞生的？ 它与WebAuthn如何关联？
FIDO由三部分组成：服务器，客户端（浏览器）和身份验证器。 服务器向客户端发送呼叫，客户端将呼叫传递给身份验证器，身份验证器对其进行签名并将其返回给客户端，并且已经将其发送到服务器。
为了使服务器使用FIDO身份验证，客户端具有WebAuthn JS API。 客户端使用低级协议CTAP2（客户端到身份验证器协议2）与身份验证器进行通信。 CTAP2描述了用于与身份验证器进行通信的CBOR查询结构和传输，例如USB，NFC和BLE。 这两个标准的组合称为FIDO2。
创建格式的目的之一是防止网络钓鱼。 与其他解决方案相比，有哪些优势？
如果我们谈论现有的解决方案，那么FIDO唯一可以与之相比的就是客户端证书或TLS CCA（客户端证书身份验证）。 FIDO和CCA是公用密钥上的网络钓鱼安全呼叫响应协议。 但是它们有很大的差异。
CCA没有受到重放攻击的保护。 他们在多个站点上重复使用单个证书，这可能导致用户取消匿名。 在FIDO，我们为每次注册生成一个新的唯一密钥对，以维护隐私。
CCA在存储密钥方面也存在问题，因为在大多数情况下，私钥要么是在PKCS12中加密的，要么就是明文存储的。 因此，即使是没有特权的应用程序也可以毫无问题地窃取它。 在FIDO中，所有密钥都保持安全，例如在单向SecureEnclave存储中。 从这种类型的存储中恢复密钥非常困难。
CCA很难在服务器端正确实施，因为对CCA的全面支持尚需时日。 而且由于使用TLS的复杂性，开发人员会犯很多错误。 FIDO仅需要支持基本密码本身。 CCA可以通过HTTP实现，而WebAuthn中无法实现。 CCA在便携性和易用性方面也存在问题。
我不相信联盟发明了任何新东西。 我们只是简单地开发了一个包含现有安全机制的良好协议。
/ Flickr / 马库斯·斯派克 / PD使用该标准是否不会透露与必须存储大量生物识别信息这一事实有关的其他攻击媒介？
我们的基本原则之一是隐私。 生物特征信息存储在安全的芯片上，永远不会离开。 我们的公司与FIDO或FIPS认证的阅读器合作。
我们也不会将生物识别信息用于确认用户的存在。 我们有一个生物特征认证计划，用于测试身份验证器。
您曾经说过，通过SMS代码进行身份验证是错误的2FA选项。 您如何对此发表评论？
SMS代码或SMS OTP是通过一次通过SMS传递一次密码的双重身份验证。 因此，事实证明该解决方案容易受到网络钓鱼的影响。 如果您的用户被钓鱼，并提供了用户名和密码，那将阻止他向网络罪犯发送SMS代码吗？
我们不应忘记将SMS用作传输的问题。 三年前，由于SS7协议中的漏洞，有40万个帐户被黑客入侵了一家德国银行，该SS7协议用于在不同电信运营商之间路由电信信息。 攻击者获得了未经授权就无法进行身份验证的SS7网络的访问，便能够注册受害者自己的号码并获取其密码。
另外，今天任何人都可以以500-600美元的价格购买GSM基站，并通过MITM攻击拦截使用它的SMS。 最后，还有与社会工程相关的危险。 我想许多人
都对这个故事很熟悉，因为攻击者通过发行受害者的SIM卡副本从银行帐户中窃取了很多钱。 在俄罗斯和其他国家，这种情况令人羡慕。
如果您需要在多台设备上输入服务，或者几个人同时使用同一服务该怎么办？ 标准是否支持这种操作模式？
与密码不同，可以有许多验证码。 用户可以注册他的电话，笔记本电脑，令牌并使用其中任何一个进行身份验证。 同样，一个令牌可以“绑定”到多个帐户，而不会失去隐私。
但是，如果令牌丢失了怎么办？ 是否可以恢复对服务的访问？
FIDO身份验证应被视为主键。 如果您丢失了钥匙，可以随时从妻子，孩子，母亲，祖母那里拿取备用钥匙，或者在最坏的情况下，从门垫下面拿起备用钥匙。 因此，我们建议您始终具有备用标识符并将其存储在例如保险箱中。
如果我们谈论恢复对服务的访问，那么这确实是一个难题。 恢复不是标准的一部分，因为不同的资源以不同的方式恢复对帐户的访问。 经典方法是一次性代码，无法防止网络钓鱼。 Facebook允许您通过朋友重新获得访问权限。
迄今为止，最有前途的解决方案是
Delegated Recovery （
委托恢复） -一种基于其他服务中加密机密存储的恢复协议。 顺便说一句，它是由U2F布拉特·希尔（Bratt Hill）的一位创作者撰写的。 恢复是一个相当困难且有趣的问题，尚待解决。
身份验证器中的私钥必须受复制保护。 标识符以什么形式存储在哪里？ 他们如何交换？
在每次注册时，认证者会生成一个新的唯一密钥对，并为其分配一个随机的标识符，称为证书ID或credID。 私钥存储在安全存储中，例如SecureEnclave，TPM或TEE。
私钥永远不会离开验证者，因为这不是必需的。 如果用户想要添加另一个身份验证器，则他只需注册它，生成一个新的密钥对和标识符，然后将带有标识符的公共密钥传输到站点。 在身份验证期间，站点将标识符转换为身份验证者，然后身份验证者找到带有它的密钥对并签署呼叫。
新标准将如何与数据保护法（例如GDPR）的要求联系起来？
我们的原则与GDPR非常一致。 即使在两因素模式下，我们也可以确保网络钓鱼身份验证的安全性。 如果我们谈论无密码认证，那么这里根本不会传输任何密码。 此外，与客户证书不同，我们的协议不能用作超级cookie。 因此，许多公司已经在努力实现我们的协议。
谁已经在执行该标准？
Google，Facebook，Dropbox，Salesforce，美国银行，NTT Docomo ...我们有数百家公司，每天有五亿用户。 我们每天都在增长。 但是，切换到完全无密码身份验证仍需要一些时间。
该标准允许从另一种身份验证方法转换的速度有多快？
从现有的两因素身份验证解决方案（例如，从OTP）转换为FIDO非常简单。 您只需要连接库并在客户端进行一些更改。 在FIDO2中，用于无密码身份验证的选项只是注册过程中的一个附加标志。 将整个生态系统转移到完整的无密码身份验证将需要一些时间。 我们预计，这种过渡将在10年内完成所有服务的80％。
FIDO制定标准的计划是什么？ 计划在不久的将来进行哪些改进？ 从长远来看呢？
到目前为止，我们一直致力于推广标准。 世界上有数百万个站点-这意味着我们有100万件事要做。 从长远来看，我们计划致力于实施物联网标准，以提高IoT小工具的安全性。 该计划还包括有关国家认证系统，电子身份证，护照和分散式身份识别系统的工作。
您打算如何继续使用WebAuthn？ IT社区如何为您提供帮助？
和以前一样，我继续在开发人员社区中担任大使：我发表文章，从事开源工作，进行演示并进行培训。 至于社区帮助，我只能说：“我们需要更多的开源金。”
PS Yuri Akkermann还准备了一篇有关Habré 的文章 ，其中他描述了FIDO2的主要安全机制，并回顾了与之配合使用的JS API。