译文/Translated：
用简单易懂的方法让私钥取代密码。
随着随着EOSIO LabsTM项目的启动，我们开始探索建立在EOSIO之上的区块链技术的未来，对其进行广泛的创新。该项目的第一个版本探索的是私人密钥管理的未来和它对安全和密钥管理的影响——通用认证库（通用认证库（UAL)。这个版本的指导思想是探索一个更大的问题，该问题的核心是密码和认证怎样在网络、区块链和其它地方广泛地应用。尽管本帖发布的时候软件还没有发布，但本文要探讨的是现行认证系统存在的问题，以及为解决该问题当代用了哪些方法来摆脱密码。抽象来看，我们想用“通行证”，如机票或借阅证，这个想法来通过安全、可行的方法解决这些问题。
传闻难题
现行的验证方法用户会遇到所谓的“传闻难题”。传闻指的是一方关于另一方的说法或者行为所获得的信息无法获得充分证实。我们的立场是，所有的信息来自依靠目前最先进的用户验证方法的系统，但如果有参与的任何一方质疑信息的有效性，该信息就可以被判定为传闻。
打个比方，假如一个不出名的社交媒体上据说有条帖子是一个著名政治家发的，但帖子内容足以毁掉这个政治家的前途。我们怎么保证这个愚蠢的帖子真的是该政治家发的？尽管帖子的作者可能真的是该政治家，但也可能是他的账户被盗用了。继续推理下去，真正的“作者”可能是该政治家身边的人或者刻意攻击他的黑客。但没有人，包括政治家本人和社交媒体服务商，能够提供结论性、非间接证据表明，该政治家（不）是帖子的作者。
用法律和技术术语来说的话，这个特性被称为可否认性，它不是一个人们想要的特点。在上面社交媒体的例子中，导致可否任性的主要有两个原因。第一个原因是验证方法要求先暴露秘密才能证明拥有该秘密。安全方案（如密码）都会遇到该问题，除了当事人和对方之外的任何人都不能建立用户活动日记。第二个原因是人们没办法证明系统内的数据真的代表用户的意图，这就导致了我们说的另一个问题，“空头支票”问题。
空头支票问题
任何一个系统如果可以在没有用户明确同意某个动作的情况下还能代表用户发出该动作，那么就会产生空头支票问题。此外，如果没有切实的证据记录表明用户知悉每一个动作的意思并且明确同意每个动作的话，这样用户同意的方法也会导致空头支票问题。
在上述例子中，该问题导致社交媒体服务本身及其很多员工都有可能是发表愚蠢的帖子的嫌疑人。我们怎么证明社交媒体服务或者它的员工没有“代表”该政治家发帖？而这个问题更严重的例子，恰如其名的，是在银行账户的问题上。技术上来说，什么都不能阻止银行锁定或者清算您的资金，而且根本没有办法证明银行有任何过错，因为银行可以伪造看似合法的转账记录。无疑，这会产生严重的后果，还会极大地影响很多利益相关群体。
“二合一”问题
敏锐的读者可能已经注意到了，这两个问题其实是同一个问题的两个结果：可证明的审计日记的缺失。尽管有技术能够解决现行系统的根本性缺陷问题，比如基于证书的系统基于非对称性加密，但是它们还不够用户友好，所以公众还不能应用这些技术。通过我们后面马上谈到的—用好懂的理念贯彻理论解决方案—解决问题，对于各类用户，我们都有机会提高我们整合系统的安全性和可用性，我们也能在这个过程中提高用户体验。
密码
讨论网络安全的时候，两个基本的术语必须要定义出来：“验证”，用户通过拥有某个特定的验证凭证，一般情况下是用户名和密码，证明他们是自己所说的那个人的过程；另一个是“授权”，根据用户身份，准许或禁止用户在某个软件平台上活动的过程。
自上世纪60年代开始，业界就使用密码验证使用某设备或服务的用户身份。到目前为止，工程师们对密码验证了如指掌。对用户来说，密码这个概念很好理解。哪怕对于不懂技术的用户来说，密码也是很方便和熟悉的方式。但简单和熟悉既是密码的优势，这也是它的缺点。
这个缺点既可以是技术上，也可以说是人性上的。有些人们已经进行过深入的讨论了，包括NIST数字身份指南就做了详尽的讨论，所以这里我就不再赘述。但是，值得注意的是，密码不能启动用户已经授权操作的可信的审计日记。要用密码进行认证，该密码必须被显示出来，要检验用户密码的真实性，服务提供者必须把它们储存在某些中心化的基础架构中。这意味着，除了服务商没有人有自信说他们记录的审计日记准确地提现了用户行为。因此，依赖密码验证的系统就可能遇到上述传闻难题和空头支票问题。
当代改善或取
代密码的新尝试
多年来，已经有几个尝试逐步改进或者取代密码的方法。接下来我们要讨论最成功的几个做法及其优缺点。
密码管理器
密码管理器的存在说明人们意识到密码几个最基本的问题。它们希望能够让用户不用再创建和记忆足够复杂的密码来改善该问题，这样单一目的的密码就能获得更高级别的安全性。
使用得当的话，密码管理器确实提高了安全性，也在一定程度上提高了使用密码验证的系统的可用性。但是，试试教父母、小孩、或者不懂技术的朋友怎么用现在迭代的密码管理器，你就会发现这太痛苦了，它们不能被广泛应用，也没有好用到可以实现广泛应用。
从技术的角度看，密码管理器没有标准。它们会猜测用户什么时候创建账户、登录、或更新更方便的密码，但经常都猜错了。他们给验证改善提供了基础，但最终，它们也不过是密码，同样会遇到传闻难题和空头支票问题。
双因素验证
意识到密码的问题之后，人们尝试进行额外的安全分层，保证密码本身不是单点故障。这个方法通常被称为第二因素，或双因素认证（2FA)。2FA有各种应用，尽管它们为用密码验证的系统提供了不同程度的安全性提升，它们在设置和终端用户操作上的复杂度也相应增加了。常见的2FA方法依靠短信提供有时效性的一次性密码（OTP)。和密码本身很像，双因素法也不能被审计，而且也受制于向你手机发送短信的电话运营商的安全措施。
因为无法提供审计，所以2FA依然没有解决传闻难题和空头支票问题。
WebAuthn标准
WebAuthn是万维网联盟（WebAuthn是万维网联盟（W3C)提出的一种新的认证标准，该联盟是成员组织的国际社区社区、是全职组织、也是协作开发网络标准的公共组织。WebAuthn通过非对称加密，而不是密码，几乎解决了网络交易的这些问题，它给我们提供了攻克上述问题的一味必要药材。但是，如果用户设备遗失，他们可能就不能接入任何服务，为了避免这种情况，WebAuthn的设计是和密码相结合，而不是取代密码。
WebAuthn另一个严重的缺陷是它的设计是证明存在，而不是证明同意。它未能被设定要求每笔交易授权请求都能被审计。所以，依靠WebAuthn的系统也没有可证明的审计日记，也一样会遇到传闻难题和空头支票问题。
区块链可能是一个解决方法
区块链传播的想法是，通过公链加密交易签名，用户每发出授权指令就验证一次用户。这是密码的一大改进，也比WebAuthn走的更远。它也满足了解决传闻难题的第一个必要因素：可证明的可审计性。
不幸的是，当今的区块链用户界面没有定义用怎样的标准描述授权请求才是用户友好的，因为这样才能再可信的语境下获得用户批准。如果没有用户友好的请求描述标准，用户就不知道他们同意的究竟是什么。这就意味着尽管区块链提供了可证明的可审计日记，它门也不足以证明系统中的数据真的代表用户意愿。因此，它们依然会遇到传闻难题和空头支票问题。
回到我们刚举过的社交媒体的例子，如果一个社交媒体平台建在区块链上，他们就能证明该政治家真的发出了发帖这个动作，但他能不能证明他们（或其他人）没有通过曲解来诱哄政治家发出动作。
理论解决方案：“通行证”而不是密钥或密码
为了提高系统的安全性，我们需要证明用户同意、简洁性和超过密码的可用性。这就意味着我们用任何用户，不单单是技术人才，都能马上理解的说法来推行复杂的技术，如非对称加密。符合该标准的其中一个概念是“通行证”。描述通行证的概念的时候，我们会说明为什么这个应用于通行证管理器的通行证理论上能够解决上述传闻难题和空头支票问题。
对于用户来说，通行证是一种常见的实质性凭证。我们日常生活中都会遇到各种通行证。去图书馆的时候，你只要掏出借阅证。去机场的时候，你拿出你的机票。这些都是单一目的通行证的例子，对于一些没有提供单一目的通行证的服务，你可能要拿出驾照证实自己的身份。
为了支持验证和授权，我们引入了电子“通行证管理器”的概念。通行证管理器是用来注册、验证和授权使用的、无需密码的范式。
通行证管理器能用来做什么？
发行和撤销
- 服务商可以要求通行证管理器向用户发放新的通行证
- 用户可以对通行证分组（如工作通行证、私人通行证等）
- 用户在多个设备上进行授权和取消授权。
验证
- 服务商可以要求用户提供证据表明其持有某个通行证
- 用户可以提供证据表明他们持有某个通行证
授权
- 服务商可以要求获得证据表明用户依据他们持有的通行证权限授权某个动作。
- 用户可以用户友好且清晰的授权请求，然后选择依据他们持有的通行证权限是否授权该活动。
通行证管理器的工作方式
通行证管理器利用一个（还未被定义的）标准化协议来发行和撤销通行证、通行证验证及授权。通行证是一种抽象概念，其中装载着凭证信息（密钥）。
使用电子通行证管理器的方法和使用实体通行证非常相似。用户到达服务点（网络应用、本机应用、销售点、货便利店），拿出通行证登录或授权某活动。这个就好像大学生使用学生卡参加体育活动，进到体育馆之后，再用饭卡余额在小卖部买东西，当然，交易前要确认订单。
再其环境下，多种技术可以协同工作，为用户提供卓越的安全性和可用性，包括加密签名、硬件密钥、为保证凭证安全性而实施的生物识别、实现可移植性的传输无关协议。
不管什么时候，通行证管理器总是追求用户同意，用户必须能够获得人性化的动作描述，同时，通行证管理器的签名反馈必须包含该描述（或其可加密验证的衍生信息）。密钥的使用保证日记不可否认且能够被第三方验证，而签名反馈中人性化的描述可以证明用户意图。这些特征解决了传闻难题和空头支票问题。
该模型支持现有的该模型支持现有的Web技术和未来的区块链技术用例，它还能为登录和授权提供清晰的用户体验。
通行证管理器成功的必要条件
互通性
首先，通行证管理器协议必须让用户能够自由选择最能满足他们需求的通行证管理器。这很重要，因为它能防止供应商锁定，从而保证自由市场，而这是在安全性和用户体验上促成创新的必要条件。
要带来自由选择，就应该有足够的注册、登录、授权的标准协议。尤其是授权这块是个极大的挑战，因为它要求能够定义标准来描述向用户发出的授权请求，且其方式必须能够被理解、被审计、被证明、被移植。
可移植性
其次，通行证管理器协议应该要有可移植性，也就是说1）支持在各类平台上的各类应用和服务 2） 支持有限网络或离线连接3） 支持多设备4）支持跨设备通信。
用户有台式电脑、笔记本电脑、手机、平板、智能手表、USB密钥，所以说，让用户在多个设备中简单、无缝地发行和撤回授权是很重要的。用户还会使用销售点、不安全的公共电脑、自动贩卖机、便利店，所以不管有没有网络，设备间不需要信任对方就能进行互动这个能力是非常重要的。
上述要求在通行证管理器协议被定义成传输无关的时候可惜被实现。这意味着协议应该关注定义实施系统必须能够流利表达的名词和动词即可，而传输中的表达方式可以是多种多样的。传输的例子可以是超链接、Apple Universal Links, Android Intents, 服务器请求、二维码、蓝牙、服务器请求、二维码、蓝牙、NFC和JavaScript API。因为这种灵活性，通行证管理可以实现真正的可移植性。
可用性
用户不用考虑他们使用带有数据后端或区块链系统的网页服务带来的影响。在区块链中，他们不需要知道他们在使用的应用是建立在哪个区块链平台或网络上的。他们只要考虑他们在什么情况下会使用该应用。比如……
“我要在ATM机上取钱。”
“我要登录我的邮箱。”
“我给社交平台上的帖子点赞。”
“我在自动贩卖机上买薯片。”
“我从Dan那里转了100代币给Brain。”
而不是…
“我在用R1密钥签署交易，授权方是我在在example.com这个dapp上的区块链11账户，这个dapp建立在Telos区块链上，该区块链又建在EOSIO平台上。
安全性
由于种种原因，现行的不管是密码还是公共密钥系统都是不安全的，通行证管理器肯定能做得更好。
为了保护用户不受到中心化凭证的糖衣炮弹攻击，机密的凭证数据就不应该被存放在中性化的基础架构中，不管怎样的形式都不行（散列和盐析也不够）。为了防止用户遇到钓鱼、恶意软件、中间人的攻击导致凭证丢失，用户不应该知道他们的凭证是什么，更不应该手动或自动进入某项服务。为了防止用户被欺诈添加恶意通行证，用户不应该能自己添加或删除通行证，相反，当用户访问新的服务或获得新的设备时，可信任的通行证管理器应该能自动处理这些问题。
未来向通行证管理器敞开了大门
本文我们探讨了现在保证用户账户安全的几大先进方式存在的安全性和可用性问题。我们认为，用通行证取代密码并利用通行证管理器可以解决这些问题。我们讨论了通行证管理器要成功的必备属性，但我们还没有明确定义协议。我们鼓励积极的开发者考虑通行证来解决围绕着密码和基于密钥的安全系统问题。
所有标有商标™和®的产品和公司名皆为其所有者持有。使用这些名字并不代表我司与其存在任何从属关系，也不代表我司对其认可。
免责声明：Block.one作为EOSIO社区的一员，自愿做出自身贡献，并不对软件的总体性能及任何相关应用程序负责。对于此处所述版本以及相关GitHub版本、EOSIO软件、或任何存档，我们不作任何明示或暗示的陈述、保证、担保或承诺，包括且不限于提供担保，保证适销性或对某一特定目的和非侵权的适用性。在任何情况下，无论是合约操作、侵权行为或其他，亦无论是否与软件或文档相关，或由于软件使用导致，或在软件和文档上的其他交易导致的任何索赔、损害赔偿或其他债务，我们均不承担责任。任何测试结果或表现数据具有指示性，无法反映所有情况下的表现。任何对第三方或第三方产品、资源或服务的引用都不受Block.one的认可或推荐。对于您使用或信任这些资源的行为，我们概不负责，并且不承担任何责任和义务。第三方资源可能随时更新、变更或终止，因此此处的信息可能已过期或不准确。任何人使用或提供此软件向第三方提供软件、商品或服务应当就授权条款、免责声明和免责事项向该第三方提出建议。
原文/Original：
Replacing passwords with private keys in an easy to understand metaphor
With the introduction of the EOSIO Labs™ initiative, we have begun innovating in the open with regards to the future of blockchain technologies built on EOSIO. Our first release under this initiative explores the future of private key management and its implications on security and key management — the Universal Authenticator Library (UAL). What underlies the philosophy of this release is an exploration into a larger problem, one that is centered on how passwords and authentication have been implemented across the internet, blockchain or otherwise. While there is no software release accompanying this post, this article aims to discuss problems that plague existing authentication systems, and the modern attempts to move beyond passwords attendant to such problems. We will then propose, in abstract, a new model using the metaphor of a “pass”, such as an airline ticket or a library card, to address these problems in a secure and usable way.
The Hearsay Problem
Current methods of authenticating users suffer from what we will call “The Hearsay Problem”. Hearsay is any information received from one party about the statements or actions of a second party that cannot be adequately substantiated. Our stance is that all information sourced from systems which rely on current state-of-the-art methods of authenticating users would qualify as mere hearsay if any of the involved parties were to call the validity of the information into question.
To illustrate, imagine a poorly received social media post allegedly authored by a well-known politician that threatens to destroy said politician’s career. How do we know for sure that the politician did, in fact, author the damning post? While the author could indeed have been the politician in question, it could equally be anyone with access to the politician’s social media account. To extend this reasoning, the pool of possible ‘authors’ could include any number of people close to the politician, or adversarial hackers in a targeted attack. Yet no one, including the politician and the social media service provider, would be able to present conclusive, non-circumstantial evidence that the politician was or was not definitively the author of the post in question.
To use legal and technical terminology, this characteristic is referred to as repudiability, and it is not a desired trait. Two primary factors lead to this characteristic of repudiability in our social media example above; the first factor is an authentication scheme that requires disclosure of a secret in order to validate the possession of that secret. In security schemes (like passwords) that are subject to this factor, it is impossible to create logs of user activity that are verifiable by anyone other than the party and the counterparty. The second factor is the lack of means to prove that the data within a system that actually represents the intent of the user, which leads us to another problem we are calling, “The Blank Check”.
The Blank Check Problem
The Blank Check problem is present in any system that can take action on behalf of the user without needing the user’s explicit consent on that specific action. It is also present if the means of capturing the user’s consent is anything short of a log of proof that the user was informed of the implications of every individual action and explicitly consented to each action.
In the example above, this problem adds the social media service itself as well as many of its employees to the list of parties that could have posted the damning post. How can we prove that the social media service or one of its employees did not have compromising access to “post” on behalf of the politician? A higher-stakes example of this problem that showcases the appropriateness for the name “The Blank Check Problem” is that of a bank account. Technologically speaking, there is nothing to prevent your bank from liquidating or locking your funds, and there would be no means of proving any wrong-doing, as the Bank could fabricate records of seemingly legitimate transactions. This would no doubt pose grave consequences that affect many stakeholders in a material way.
The ‘Two Become One’
An astute observer might have noticed that these problems are really two outcomes of the same underlying problem: the lack of provable audit logs. While there are technologies that do address this fundamental shortcoming in our current systems, like certificate-based systems based on asymmetric cryptography, they have yet to achieve a level of user-friendliness that makes them accessible to the general public. By addressing this challenge with easy-to-understand metaphors for a theoretical solution we will present below, we have the opportunity to improve the security and usability of all of our systems, for every kind of user, and improve users’ experience in the process.
Passwords
When discussing cybersecurity, two basic terms should be defined: ‘authentication’, which is the process by which a user proves that they are who they say they are by possession of particular identifying credentials, typically with a username and password; and ‘authorization’, which is the process by which a user’s actions within a software platform are allowed or restricted according to their identity.
Since the 1960s, passwords have been the de facto method that allows a user to authenticate themselves to a device or service. Password authentication is, by now, a well-understood technology for engineers. For users, passwords have become a simple concept to grasp; they are comfortable and familiar even for non-technical users. But while their simplicity and familiarity are a strength, passwords suffer from many weaknesses as well.
Such weaknesses are both technological and human in nature. Some of them have been widely discussed, including in exhaustive detail in the NIST Digital Identity Guidelines, so we will be not be repeating them here. What is important to remember, however, is that passwords do not enable trustworthy auditable logs of the actions that a user has authorized. To authenticate with a password, it must be revealed, and in order to check the validity of a user’s password, service providers must have stored them in some form of centralized infrastructure. This means that no one but the service provider can have confidence that any audit logs they keep are accurate representations of a user’s actions. For this reason, systems that rely on passwords for authentication are subject to both The Hearsay Problem and The Blank Check Problem as described above.
Modern attempts to improve or replace passwords
There have been several attempts over the years to incrementally improve or replace passwords. Below we will review a few of the most successful cases along with their strengths and weaknesses.
Password Managers
The existence of Password Managers represents an admission of several of the fundamental flaws of passwords. They attempt to improve the situation by freeing the user from having to generate and remember sufficiently complex passwords, thus allowing for single purpose passwords that meet a much higher level of security rigor.
Used correctly, Password Managers do improve security, and to a limited extent, the usability of systems with password-based authentication. Yet anyone who has tried to teach their parents, children, or non-technical friends to use today’s iterations of password manager software is painfully aware that they are neither widely adopted nor usable enough to become so.
From a technical perspective, there are no standards for password managers. They attempt to guess when a user is creating an account, logging in, or updating their password to be more convenient, but they often fail. They provide the basis for an improved solution, but ultimately, they are still just passwords and are still subject to both The Hearsay Problem and The Blank Check Problem.
Two Factor Authentication
In recognition of the weakness of passwords, attempts have been made to layer on additional security to ensure that the password itself is not the single point of failure. This approach is usually called a second factor, or two-factor authentication (2FA). There are a variety of implementations of 2FA, and while all of them do add differing degrees of incremental security to password-based authentication systems, they make up for it with added complexity in terms of setup and end-user operation. A common 2FA solution relies on SMS messages to provide time-based one-time passwords (OTP). Much like passwords themselves, two-factor solutions suffer from the problem that they are not auditable and are vulnerable to the security practices of phone carriers which deliver SMS messages to your device.
This lack of provable auditability means that 2FA still does not solve The Hearsay Problem or The Blank Check Problem.
The WebAuthn Standard
WebAuthn is a new authentication standard proposed by The World Wide Web Consortium (W3C), an international community of member organizations, a full-time staff, and the public work together to develop Web standards. WebAuthn comes very close to solving all of these problems for Web-based transactions by using asymmetric cryptography, instead of passwords, providing one of the necessary ingredients for overcoming the problems we have outlined. However, in order to prevent users who lose their devices from being locked out of every service, WebAuthn is designed to be used in conjunction with passwords, rather than as a replacement.
Another significant important limitation of WebAuthn is that it was designed as a proof of presence, not as a proof of consent. It is not defined to allow per-transaction authorization requests that are auditable by peers. So once again, systems that rely on WebAuthn don’t have provable audit logs and are subject to both The Hearsay Problem and The Blank Check problem.
Blockchain as a Potential Solution
Blockchains have popularized the idea of authenticating the user for every action they authorize, using public key cryptographic signing of transactions to accomplish this goal. This is a big improvement on passwords and a step beyond what WebAuthn can provide. It also satisfies the first factor necessary to address The Hearsay Problem: provable auditability.
Unfortunately, today’s blockchain user interfaces also do not define a standard for describing authorization requests in a human-friendly way to users so that they can be displayed in a trustworthy context for user approval. Without this human-friendly request rendering standard, users cannot know what they are agreeing to. This means that even though blockchains create a provable auditable log, they lack the means to prove that the data within a system actually represents the intent of the user. Thus, they are still subject to the Hearsay and Blank Check problems.
Back to our social media example, if a social media platform was built on a blockchain, they would be able to prove that the politician in question did, in fact, sign the action that resulted in the post, but they would be unable to prove that they (or another party) didn’t trick the politician into signing the action by misrepresenting it.
A Theoretical Solution: “Passes” instead of Keys or Passwords
To advance the security of our systems, we need proof of user consent, combined with a level of simplicity and usability that exceeds even passwords. This means we must communicate complex technologies like asymmetric cryptography through a metaphor that is immediately understandable for every kind of user, not just technologists. One concept that meets these criteria is that of a “pass”. In describing the concept of a pass, we will show how this theoretical solution of a pass used in a Pass Manager Application can satisfy both The Hearsay Problem and The Blank Check Problem we have outlined.
For users, a pass represents a familiar and tangible means of proving possession of a credential. Every day we interact with physical passes as part of our daily routines. As a library user, you simply show up and present your library card. As an airline passenger, you simply show up and present your ticket. These are examples of single-purpose passes, for services that do not provide a single-purpose pass, you might present your Driver’s License to prove your identity.
To support authentication and authorization use cases, we introduce the concept of the digital “Pass Manager”. A Pass Manager is a passwordless paradigm for registration, authentication, and authorization use cases.
What could you do with a Pass Manager?
Issuance and Revocation
- Service Providers could request the Pass Manager to issue a new pass for a user.
- Users could organize their passes into groups. (e.g. my work passes, and my personal passes)
- Users could authorize and deauthorize passes across multiple devices.
Authentication
- Service Providers could request proof of a user’s possession of a pass.
- Users could provide proof of their possession of a pass.
Authorization
- Service Providers could request proof of a user’s authorization to perform a particular action, on the authority of a pass the user possesses.
- Users could see authorization requests rendered clearly in a human-friendly way, and choose whether to authorize the action, on the authority of a pass they possess.
How would a Pass Manager work?
A Pass Manager implements a (yet-to-be-defined) standardized protocol for issuance and revocation of passes, authentication, and authorization with passes. A Pass is a conceptual abstraction that encapsulates credential info (keys).
The experience of using a digital Pass Manager should be very similar to the physical analog of pass cards. The user simply arrives at a service (whether it is a web app, a native app, a point of sale system, or a kiosk), and presents a pass to sign in or authorize an action. This is like a college student using their College ID to gain admission to a collegiate sports event, then once inside, using it to buy food at a stand with their campus dining balance, being presented with order confirmations before committing to the transactions.
Under the hood, a blend of technologies can work in tandem to produce superior security and usability for users, including cryptographic signing, hardware keys, and biometrics for credential security, as well as a transport-agnostic protocol for portability.
Anytime a user’s consent is sought by a Pass Manager, human-friendly descriptions of the action should be shown to the user, and that description (or a cryptographically verifiable derivative of it) should be included in the signed response from the Pass Manager. The use of keys means that logs are non-repudiable and can be verified by third parties, and the inclusion of the human-friendly description in the signed response can serve as proof of the user’s intent. These characteristics solve both the Hearsay and Blank Check problems.
This model can support both current web technology and future blockchain technology use cases. It is also capable of providing a clear user experience for both login and authorization use cases.
What is necessary to make Pass Managers successful?
Interoperability
First and foremost, a Pass Manager protocol should be built to allow users the freedom to choose a Pass Manager that best suits their needs. This is important because it prevents vendor lock-in, creating the free market that is necessary to foster innovation in both security and user experience. This way, the best user experience with acceptable security will win.
To provide this freedom of choice, there will need to be standard protocols for signup, login, and authorization. Authorization, in particular, is an interesting challenge, because it requires the definition of a standard for describing requests for authorization to users in a way that is understandable, auditable, provable, and portable.
Portability
Secondly, the Pass Manager protocol should be built for portability; meaning: 1) support for every kind of application or service running on any platform, 2) support for limited or no network connectivity, 3) support for multiple devices, and 4) support for cross-device communication.
Users have desktop computers, laptop computers, phones, tablets, smart watches, and USB keys. So a simple and seamless experience for issuing and revoking pass access across multiple devices is critical. Users also interact with point of sale systems, untrusted public computers, vending machines, and kiosks. So the ability to interact from one device to another, with or without network connectivity, without needing the devices to trust each other is necessary.
These requirements can be met by defining the Pass Manager protocol to be transport agnostic. This means that the protocol should focus on defining the nouns and verbs that implementing systems must be able to fluently speak, and allow the transports through which they are spoken to vary. Examples of transports might include custom protocol URLs, Apple Universal Links, Android Intents, server requests, QR codes, Bluetooth, NFC, and JavaScript APIs. With this flexibility, Pass Managers can be truly portable.
Usability
Users should not have to consider the implications of whether they are using a web service with a database backend or a blockchain system. In the case of blockchain, they should not have to know what blockchain platform or network the application they are using is built on. They should only need to consider their use case. Things like…
“I’m withdrawing funds from an ATM.”
“I’m logging into my email.”
“I’m liking a post on social media.”
“I’m buying chips from a vending machine.”
“I’m transferring 100 tokens from Dan to Brian.”
Never things like…
“I’m signing a transaction, with an R1 key, authorized for my blockchain11 account, on the example.com dapp, which is built on the Telos blockchain, which is built on the EOSIO platform.”
Safety
Current implementations of both passwords and public key systems are unsafe for a variety of reasons. Pass Managers must do better.
In order to protect users from attacks on centralized honeypots of credentials, secret credential data should never be stored on centralized infrastructure in any form (hashing and salting is not good enough). In order to protect users from having their credentials stolen through phishing, malware, and man-in-the-middle attacks, users should never actually know what their credentials are, and they should never be entered manually or automatically into any service. In order to protect users from being tricked into adding malicious passes, users should not be able to add or remove passes themselves. Instead, a trusted Pass Manager should handle this automatically on behalf of the user in response to the user visiting new services or getting new devices.
The Future is Wide Open for Pass Managers
In this article, we have laid out problems to be solved to address security and usability concerns with current state-of-the-art methods for securing user accounts. We have presented the concept of Passes replacing passwords and the digital Pass Manager as a means of solving these problems. We have discussed the necessary attributes for a Pass Manager protocol to succeed, but we have not explicitly defined the protocol. We encourage enterprising developers to solve the problems that plague both password and key-based security systems and to consider the Pass metaphor as one way to accomplish that goal.
All product and company names are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
Disclaimer: Block.one makes its contribution on a voluntary basis as a member of the EOSIO community and is not responsible for ensuring the overall performance of the software or any related applications. We make no representation, warranty, guarantee or undertaking in respect of the releases described here, the related GitHub release, the EOSIO software or any related documentation, whether expressed or implied, including but not limited to the warranties or merchantability, fitness for a particular purpose and noninfringement. In no event shall we be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or documentation or the use or other dealings in the software or documentation. Any test results or performance figures are indicative and will not reflect performance under all conditions. Any reference to any third party or third-party product, resource or service is not an endorsement or recommendation by Block.one. We are not responsible, and disclaim any and all responsibility and liability, for your use of or reliance on any of these resources. Third-party resources may be updated, changed or terminated at any time, so the information here may be out of date or inaccurate. Any person using or offering this software in connection with providing software, goods or services to third parties shall advise such third parties of these license terms, disclaimers and exclusions of liability.
原文链接/Original URL:
