by Cossack Labs Dev Stories

哥萨克实验室开发故事

为什么我们需要新颖的身份验证方案？ (Why we need novel authentication schemes?)

Revealing security holes in 5 main methods of authentication

揭示5种主要身份验证方法中的安全漏洞

简介：一个要传递的词 (Introduction: A Word To Pass)

Passwords are ultimate keepers of diversity and security. Since Ancient Roman times until now, they are used for one to prove being worthy to get some privilege others do not possess, however strongly desire to obtain. A “magic word”, which one knows and others don’t, opens the door for an opportunity and diversifies an individual selecting them from an enormous crowd.

密码是多样性和安全性的终极保留者。 自古罗马时代到现在，它们一直被用来证明值得获得别人所不享有的某些特权，无论他们多么渴望获得。 一个“魔术字”(一个人知道而其他人却不知道)打开了机会之门，并使从众多人群中选择一个的人多样化。

We can say that password is the oldest and the most widely used pillar of authentication, which is extensively used in 21st century Internet. Its importance is even greater than before, because nowadays more and more people are communicating remotely without seeing or hearing each other, using remote means to gain access to automated systems. Therefore, they have to rely only on passwords to verify remote party and prove their own identity. Just getting to know other person’s password allows you to become that person in the eyes of others, do whatever you please in their name, obtain their privileges in automated systems. That’s why passwords are so critical to protect properly.

可以说，密码是最古老，使用最广泛的身份验证Struts，它已在21世纪的Internet中得到广泛使用。 它的重要性甚至比以前更加重要，因为如今越来越多的人使用远程方式访问自动化系统，而彼此之间不会互相看到或听到对方的声音。 因此，他们只需要依靠密码来验证远程方并证明自己的身份。 只需了解他人的密码，您就可以成为他人眼中的那个人，以您的名义做任何您想做的事，并在自动化系统中获得他们的特权。 这就是为什么密码对于正确保护至关重要的原因。

However, most of the schemes used for authentication today have their own weaknesses — although some of them are quite theoretical, in rapidly changing world theoretical threats frequently become very practical.

但是，当今用于身份验证的大多数方案都有其自身的弱点-尽管其中一些是相当理论的，但在瞬息万变的世界中，理论上的威胁经常变得非常实用。

沟通是机密的主要威胁 (Communication as main threat to secrets)

The idealistic way to keep a secret safe is not to use it: if you never use it, nobody will intercept it. However, this makes such secrets useless. Since secrets give you privileges, you want to obtain and exercise those privileges now and then.

保守秘密安全的理想方法是不使用它：如果您从不使用它，没有人会拦截它。 但是，这使这些秘密毫无用处。 由于机密为您提供特权，因此您不时希望获得并行使这些特权。

To do that you have to prove you know the secret. This process involves communicating the secret to other party, which eventually exposes whole or part of a secret. Exercising a secret involves at least 2 parties: a prover (you) and a verifier (an entity which eventually decides whether your secret is the real correct one and you deserve the privileges you claim). However, if you cannot communicate with verifier directly, you have to use one or more intermediate entities, in which case those entities know the secret as well.

为此，您必须证明自己知道秘密。 此过程涉及将机密传达给另一方，这最终暴露了整个或部分机密。 行使秘密至少需要两方：证明者(您)和验证者(最终决定您的秘密是否是真正的正确者，并且您应享有您要求的特权的实体)。 但是，如果您不能直接与验证程序通信，则必须使用一个或多个中间实体，在这种情况下，这些实体也知道秘密。

Now let’s get back to real world of 21st century and Internet: while communicating, you may be using thousands of intermediate links to deliver your data, so once you send a secret to verifier — it’s not a secret anymore.

现在，让我们回到21世纪的现实世界和Internet：在进行通信时，您可能会使用数千个中间链接来传递数据，因此，一旦将密码发送给验证者，就不再是秘密了。

现有的身份验证方法 (Existing methods of authentication)

Existing methods provide some level of protection,- better or worse,- yet each of them has significant drawbacks. So far, most current systems and secure protocols have used only three types of cryptographic primitives: encryption, key agreement and digital signatures. More high level tasks, like authentication, are achieved by combining those primitives in some way in a protocol.

现有方法提供了某种程度的保护(更好或更糟)，但是每种方法都有明显的缺点。 到目前为止，大多数当前的系统和安全协议仅使用三种类型的密码原语：加密，密钥协商和数字签名。 通过在协议中以某种方式组合这些原语，可以实现更高级的任务，例如身份验证。

Internet authentication started with pretty basic passwords: a user entered the password in the web-form, password was sent via HTTP to the server, server verified the password and lets the user in. That was in the early days of the small Internet. At that time attackers were limited by having very little experience on how Internet works. Even if some had basic networking knowledge, they did not have equipment, tools or software (which was very expensive at that time) to do the attacks. Also, the attacks themselves were pointless because of the little commercial value of the information which traversed the Internet at that time. Eventually growth of the Internet and availability of the knowledge, software and tools created a first network attacker: HTTP passwords were easily stolen by simplest passive network sniffers and protocol analyzers.

Internet验证从非常基本的密码开始：用户在Web表单中输入密码，密码通过HTTP发送到服务器，服务器验证了密码并允许用户进入。那是在小型Internet成立之初。 那时，攻击者由于对Internet工作原理的经验很少而受到限制。 即使有些人具有基本的网络知识，他们也没有设备，工具或软件(当时非常昂贵)来进行攻击。 而且，由于当时穿越互联网的信息的商业价值很小，因此攻击本身毫无意义。 最终，Internet的发展以及知识，软件和工具的可用性创造了第一个网络攻击者：最简单的被动网络嗅探器和协议分析器很容易窃取HTTP密码。

Next step was to change passwords to some values which were useless for passive eavesdroppers: people started hashing the password. Since both server and user had the same password, they could produce identical hashes of those and compare them, with user sending the hash to server. It seemed that attackers couldn’t get the password, because reversing a hash function is computationally “almost impossible”. This solution saved the day… for just a little while! Attackers used two ways to overcome this:

下一步是将密码更改为一些对于被动窃听者无用的值：人们开始对密码进行哈希处理。 由于服务器和用户都具有相同的密码，因此用户可以将哈希发送给服务器，从而产生相同的哈希值并进行比较。 攻击者似乎无法获得密码，因为反向哈希函数在计算上“几乎是不可能的”。 这个解决方案节省了一天的时间……！ 攻击者使用两种方法来克服此问题：

First: many people make their passwords “easy-to-remember”, so they attackers hashed a big set of popular words and by knowing the hash, could easily “lookup” the original password if it happened to be from the produced “dictionary”: a dictionary attack was invented.

首先：许多人将密码设置为“易于记忆”，因此攻击者对大量常用单词进行了哈希处理，并且通过了解哈希值，可以很容易地“查找”原始密码(如果该密码恰巧来自所产生的“词典”) ：发明了字典攻击。

Second: even if someone used complex password, attackers just used the hash directly to authenticate with the server with a “modified browser”. They did not enter the password in the form, but injected hash directly to HTTP stream: an active attack was invented.

第二：即使有人使用了复杂的密码，攻击者也只是直接使用哈希来通过“修改后的浏览器”对服务器进行身份验证。 他们没有以表单的形式输入密码，而是将哈希直接注入到HTTP流中：发明了一种主动攻击。

It was clear now that HTTP traffic had to be encrypted. However, since communicating parties were located far away from each other a key agreement was used and was eventually broken by attackers: man-in-the-middle was proposed.

现在很明显，必须对HTTP通信进行加密。 但是，由于通信方之间的距离很远，因此使用了一项关键协议，并最终被攻击者破坏了：提出了中间人协议。

The history continues: the more sophisticated schemes for protecting the transmission of passwords are proposed, the better and smarter attacks are designed to defeat them. Wouldn’t it be great to avoid transmitting the passwords at all?

历史还在继续：提出了用于保护密码传输的更复杂的方案，旨在克服它们的更好和更聪明的攻击。 根本不传送密码不是很好吗？

1.自定义哈希交换协议 (1. Custom hash exchange protocols)

Most of engineers who just begin developing cryptographic tools, seem very pleased when they have their first success in turning a piece of data to a random-looking string using some key and recovering the original data. The problem is that most of the engineers stop at this point. As we know from Schneier’s law:

刚开始开发密码工具的大多数工程师对使用某些密钥将数据转换为随机字符串并恢复原始数据的首次成功感到非常满意。 问题在于大多数工程师都在这一点上停止工作。 从施耐尔定律我们知道：

Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can’t break.

从最笨拙的业余爱好者到最好的密码学家，任何人都可以创建自己无法破解的算法。

They think that if the output is indeed random-looking and nobody knows the key, they are safe. So, one can always find low-security encryption schemes, hardcoded keys or initial vectors, improper usage of encryption modes etc. even in production software. And, although your output looks random-like, a sophisticated attacker with proper tools and mathematical background will surely find patterns, side-channel leaks, perform cryptanalysis and eventually will recover the data. Even large companies get into trouble with this, so what makes you special?

他们认为，如果输出确实是随机的，并且没人知道密钥，那么它们是安全的。 因此，即使在生产软件中，总能找到低安全性的加密方案，硬编码的密钥或初始向量，加密模式的不正确使用等。 而且，尽管您的输出看起来像是随机的，但具有适当工具和数学背景的老练攻击者肯定会找到模式，旁路泄漏，执行密码分析并最终将恢复数据。 即使是大公司也遇到了麻烦，那么让您与众不同的是什么？

Different schemes involving bcrypt, pbkdf2 or any ‘encrypt then compare’ frameworks provide only a fragment of security system instead of complete solution. This does not provide sufficient level of security at all.

涉及bcrypt，pbkdf2或任何“先加密后比较”框架的不同方案仅提供安全系统的一部分，而不是完整的解决方案。 这根本不能提供足够的安全级别。

2. HTTP认证 (2. HTTP authentication)

Passwords are still widely used in HTTP to give users access to restricted resources. However, despite the long history of updates of authentication protocols, still there is some room for attacks. A security-aware user will never attempt to enter their password on a website, if that website does not provide a HTTPS connection for entering such credentials. This means that even today HTTP authentication mechanisms by themselves are pretty weak. Let’s check the simplified high-level picture of HTTP authentication:

密码仍在HTTP中广泛使用，以使用户能够访问受限资源。 但是，尽管认证协议的更新历史悠久，但仍有一定的攻击空间。 具有安全意识的用户将永远不会尝试在网站上输入密码，如果该网站未提供用于输入此类凭据的HTTPS连接。 这意味着即使在今天，HTTP身份验证机制本身仍然非常薄弱。 让我们检查一下HTTP身份验证的简化高级视图：

• First of all, the server authenticates the client, but client does not authenticate the server. So the clients has no idea whom they sends their credentials. Moreover, HTTP authentication does not define confidentiality, so anyone can at least know that a certain web resource has certain userbase simply by observing traffic.首先，服务器对客户端进行身份验证，但是客户端不对服务器进行身份验证。 因此，客户不知道他们将证书发送给谁。 而且，HTTP身份验证没有定义机密性，因此任何人至少可以通过观察流量来至少知道某个Web资源具有一定的用户群。

• Although in recent authentication protocols users do not send passwords directly, sending hashes (which is one-way irreversible function) of their passwords instead, passive eavesdroppers can still collect this information and use more complex techniques (like dictionary attacks to recover the password).

  尽管在最近的身份验证协议中，用户并不直接发送密码，而是发送密码的哈希值(这是一种单向不可逆的功能)，但是被动窃听者仍可以收集此信息并使用更复杂的技术(例如通过字典攻击来恢复密码)。

• Previous authentication mechanisms did not use server nonces, so a simple replay attack was possible. Even today many browsers support such older mechanisms for compatibility reasons, so a man-in-the-middle can forge messages between client and server and perform a downgrade attack.

  以前的身份验证机制未使用服务器随机数，因此可能发生简单的重放攻击 。 即使在今天，出于兼容性原因，许多浏览器仍支持这种较旧的机制，因此中间人可以在客户端和服务器之间伪造消息并执行降级攻击 。

3. Kerberos (3. Kerberos)

A lazy approach: instead of authenticating each other, why not make someone else do it? So an entity is created, all clients and services register their keys there and when communication between particular client and server is needed, they just “ask the service”. Seems good at first, but there are some drawbacks and the main of them is that all drawbacks are becoming worse and worse as your infrastructure grows:

懒惰的方法：为什么不让对方进行身份验证，而不是相互进行身份验证？ 因此，创建了一个实体，所有客户端和服务都在此注册其密钥，并且当需要特定客户端和服务器之间的通信时，它们只是“询问服务”。 乍一看似乎不错，但是有一些缺点，主要是随着基础架构的增长，所有缺点都越来越严重：

• poorly developed methods to get initial trust to the kerberos server (initial client and service registration)获得对kerberos服务器的初始信任的方法不完善(初始客户端和服务注册)
• mostly symmetric encryption is used for protocol information and, since protocol is known, there is an open possibility of known-plaintext attacks协议信息大多采用对称加密，并且由于协议已知，因此存在明文攻击的可能性
• development and testing is hard under Kerberos: a separate domain and separate Kerberos setup is needed for development and production environments在Kerberos下很难进行开发和测试：开发和生产环境需要单独的域和单独的Kerberos设置
• possible misconfigurations and use of weak cryptography for unexperienced administrators经验不足的管理员可能会配置错误并使用弱密码
• the most important: it’s all good until you Kerberos server is secure. When it is compromised a whole security ecosystem explodes. And since sooner or later security breaches happen, having Kerberos is similar to having a security time-bomb in your backyard.最重要的是：直到您的Kerberos服务器安全为止，一切都很好。 一旦受到威胁，整个安全生态系统就会爆炸。 而且由于迟早会发生安全漏洞，因此拥有Kerberos类似于在后院中放置一个安全定时炸弹。

4. SSL / TLS (4. SSL/TLS)

SSL/TLS is de facto standard protocol for Internet authentication. Using TLS, a client (for example, a browser) authenticates the server and, optionally, the server may authenticate the client. The protocol is well established, however does have some drawbacks:

SSL / TLS是事实上的Internet验证标准协议。 客户端(例如，浏览器)使用TLS对服务器进行身份验证，并且可选地，服务器可以对客户端进行身份验证。 该协议已经建立，但是确实存在一些缺点：

• requires established Public key infrastructure, which is hard to setup and maintain technically as well as costly

  需要已建立的公钥基础结构 ，这在技术上难以设置和维护，而且成本高昂

• the protocol is complex, so it has poor audit-ability in terms of implementation (numerous implementation attacks prove it)该协议很复杂，因此在实现方面其审核能力很差(许多实现攻击都证明了这一点)
• has long history of updates and improvements, which are driven by compatibility reasons as well as discovered protocol attacks由于兼容性原因以及已发现的协议攻击，因此具有悠久的更新和改进历史
• still has weaknesses (partly because of the above)仍然有弱点(部分是由于上述原因)

Although, current version is considered secure (yet people rarely use the latest TLS version, instead drowning in old ciphers and vulnerable versions like SSLv3), still there are many pieces a passive observer may collect from the protocol outcome:

尽管当前版本被认为是安全的(但人们很少使用最新的TLS版本，而是淹没在旧密码和SSLv3等易受攻击的版本中)，但被动观察者仍可能从协议结果中收集到很多东西：

• whether the protocol succeeded or not协议是否成功
• which parties are communicating (by checking certificate fields)哪些方正在通信(通过检查证书字段)
• how modern is the software on client and server (by examining communicated TLS version and list of supported cipher suites)客户端和服务器上的软件有多现代(通过检查通信的TLS版本和受支持的密码套件列表)
• possibly whether the parties use dedicated hardware for private key storage双方可能是否使用专用硬件存储私钥

5. OAuth (5. OAuth)

One might think that we’ve omitted OAuth, popular Delegated Authorization protocol frequently used for authentication nowadays.

可能有人认为我们已经省略了OAuth，这是当今经常用于身份验证的流行的委托授权协议。

However, it is a protocol that:

但是，该协议可以：

• one of it’s main designers resigns with negative feedback towards security level

  其中一位主要设计师因对安全级别的负面反馈而辞职

• multiple flaws found in it’s core design

  核心设计中存在多个 缺陷

• numerous implementation error patterns

  众多的 实现 错误 模式

• … floating among deployments as huge as Github and Facebook

  …像Github和Facebook一样庞大

In short, you might pick all of the worst points from previous methods (unauthenticated clients, bad transport security), add new ones (active side attacks!) and have that as “authentication” protocol.

简而言之，您可能会从以前的方法中选出所有最糟糕的点(未经身份验证的客户端，不良的传输安全性)，添加新的方法(主动侧攻击！)，并将其作为“身份验证”协议。

If, by any whim of misfortune, you have to end up using OAuth for authentication, please invest some time into hardening it as much as possible.

如果由于一时的不幸而不得不使用OAuth进行身份验证，请花一些时间尽可能地加强它 。

随着复杂性的提高，出现了新的问题。 (With rising complexity, new problems arise.)

Apart from problems with protocols themselves, new network topologies and relationship schemes arise, with ad-hoc network layouts, mixed roles and little ability to carry weighty trust infrastructure from the past. New vulnerability types and new vulnerability detection techniques render new attack vectors efficient.

除了协议本身的问题外，还出现了新的网络拓扑和关系方案，具有临时的网络布局，角色混合以及过去承载重要的信任基础结构的能力很小。 新的漏洞类型和新的漏洞检测技术使新的攻击媒介更加有效。

What do we do to address these challenges?

我们如何应对这些挑战？

Not much. We raise complexity even more by introducing multi-factor authentication. We add authentication tokens with really bad properties (like fingerprints, photographed by special camera in your iPhone). We introduce physical devices.

不多。 通过引入多因素身份验证，我们进一步提高了复杂性。 我们添加了具有非常差的属性的身份验证令牌(例如指纹，由iPhone中的特殊相机拍摄)。 我们介绍物理设备。

However, with each of these authentication channels having their own flaws, while general strength of the whole scheme is better when every part is strong enough, when any of the authentication channels is compromised, security degrades drastically. And, as infrastructure for these new authentication channels is yet to be stabilized, you might even not understand that your token is compromised, along with the whole authentication scheme.

然而，由于这些认证通道中的每一个都有其自身的缺陷，而当每个部分都足够坚固时，虽然整个方案的总体强度会更好，但是当任何一个认证通道遭到破坏时，安全性将急剧下降。 并且，由于这些新的身份验证通道的基础结构尚未稳定，您甚至可能不了解令牌和整个身份验证方案都受到了损害。

有解决方案吗？ (Is there a solution?)

All of aforementioned methods are strong to some extent, and have certain different weaknesses. If you are willing to stick to these methods, at least put some effort into protecting them from their weaknesses by applying the best practices available. As cryptographers, we strive for methods, which are theoretically secure, not only ‘never proven to be insecure’, which is known as practically secure.

所有上述方法都在一定程度上具有优势，并且具有某些不同的缺点。 如果您愿意坚持使用这些方法，请至少通过应用可用的最佳实践来尽力保护它们免受其弱点的影响。 作为密码学家，我们力求在理论上是安全的，不仅是“从未被证明是不安全的”(实际上被称为安全) 。

However, we’ve got something more interesting for people willing to try new things. Something that’s not only practically strong, but mathematically strong as well.

但是，对于愿意尝试新事物的人们来说，我们有一些更有趣的东西。 这不仅在实践上很强，而且在数学上也很强。

At Cossack Labs, we were working on novel request authentication scheme, efficient when there is object identifier (A) and unique object’s property (B). Among such objects are, not surprisingly, login/password pairs. This method is not reliant on traditional cryptographic properties, which still include sending passwords in one or another form over the network (and having some theoretical probability of being compromised), but quite a practical implementation of novel cryptographic math, which does not leak credentials at all, either in direct or hashed form.

在Cossack Labs，我们正在研究新颖的请求身份验证方案，该方案在存在对象标识符(A)和唯一对象的属性(B)时有效。 毫不奇怪，这些对象中包括登录名/密码对。 这种方法不依赖于传统的密码属性，传统的密码属性仍然包括通过网络以一种或另一种形式发送密码(并且有一定的理论上的被泄露的可能性)，而是一种新颖的密码数学的实用实现，它不会泄漏凭证。全部，无论是直接形式还是哈希形式。

Stay tuned for next educational articles and scientific paper on Secure Authenticator, novel way to check user password with 0 chance of its interception.

请继续关注有关Secure Authenticator的下一篇教育文章和科学论文，这是一种新颖的方式来检查用户密码，其被拦截的机会为0。

P.S. This article was originally published on our blog.

PS本文最初发表在我们的博客上 。

翻译自: https://www.freecodecamp.org/news/why-we-need-novel-authentication-schemes-6d5139e0cd9/