MIT6.1600 on 蛋蛋忧桑

Lec02-人员身份验证

Sun, 02 Mar 2025 17:09:30 +0800

由于时间精力有限，目前只翻译部分内容。本文使用人工智能协助翻译，内容仅供参考，可能有错误或遗漏。如果你对内容或超链接有疑问，可以查看原文。参考资料地址：https://github.com/PKUFlyingPig/MIT6.1600

1 认证

通常情况下，计算机系统在处理请求之前会执行两个步骤请求：

验证：识别发出请求的人或机器（“当事人”）。
授权：决定委托人是否有权提出请求。

2 密码（`Passwords`口令）

我们真正关心的是，对手将无法在少量的猜测中猜出你的密码。

理想情况下，我们希望从对手的角度来看所有密码的可能性都是相同的。但事实并非如此。人们必须记住自己的密码，结果很多人可能会选择相同的密码。

我们如何说服人类选择难以猜测的密码？

需要更长的密码？
禁止在密码中使用常用的英语单词吗？
强制更改密码？
是否要为该用户生成密码？

因此，尽管我们尽了最大努力，用户可能会选择简单的密码。为此，我们能做些什么呢？

2.1 处理糟糕的密码

一个“好”密码可能从一个大约20位熵的分布中采样。用目前的技术，猜测$2^{20}$次是很容易的。因此，当使用密码作为认证机制时，我们必须找到一种限制猜测的方法。

处理密码很容易猜测这一事实的一个标准方法是限制攻击者对密码的猜测次数。限制猜测的数量可以有效地防止单个账户被泄露——前提是密码不会太弱。一个缺点是猜测限制造成了拒绝服务攻击的可能性：攻击者可能会对你的密码进行10次猜测，并将你锁在你的手机或网上银行账户之外。

此外，在许多物理计算机系统中，都有多个授权用户，每个用户都有自己的密码。如果猜测限制只在每个用户的基础上强制执行，那么如果允许对每个用户的密码猜测10次，攻击者通常会破坏机器上的某些帐户。防止这些类型的攻击需要一些额外的措施：网站通过IP限制使用密码验证身份的速率，或使用验证码，等等。

2.2 存储密码

正如我们所看到的，密码很容易猜测，因此完全避免基于密码的身份验证是最安全的选择。

当系统必须使用密码进行身份验证时，存储密码的最安全的方法（例如，在服务器上）是使用加盐的加密密码哈希函数。其目标是根据存储在服务器上的哈希值，使攻击者尽可能难以恢复明文密码。

服务器选择一个随机的128位字符串，称为盐，并且服务器存储盐和哈希值 $h = H(salt∥pw)$ ，$H$ 是一个特殊的密码哈希函数。

然后，服务器存储一个像这样的表：

user	salt	$H(salt∥pw)$
alice	$r_a$	$h_a$
bob	$r_b$	$h_b$

同样，服务器可以使用盐和哈希函数来计算一个值 $h’=H（salt∥pw’）$ 。如果此散列值 $h’$ 与此用户的服务器存储值 $h$ 匹配，则服务器接受密码。

密码哈希函数H被为相对耗时的计算，这使得攻击者更难以强制反转哈希值，因为每次猜测密码都需要一秒钟的计算。（而不是计算标准哈希函数所需的微秒，比如SHA256）。
使用每个用户的随机盐，确保了对一个用户的密码的猜测在转换另一个用户的密码哈希时是无用的。加盐还可以击败预计算攻击，攻击者预先计算许多常见密码的哈希，以加速稍后的哈希反转步骤。

3 网络认证

到目前为止，我们一直在讨论人类对设备（ATM、电话、笔记本电脑等）进行手动身份验证，通过在设备中物理地输入PIN或密码。但是我们经常登录到网络上的一些服务器——Facebook、Gmail、MIT等等。在这个场景中，我们可以获取到更多身份验证机制和要求的安全属性。

3.1 密码管理器

当使用密码对网站进行身份验证时，用户可以在他们的计算机上安装一个密码管理器，从而为他们生成随机密码。由于用户不需要记住这些密码，它们可以从高熵分布中真正随机抽样。一旦用户登录到他们的电脑，他们就可以访问他们随机生成的密码，并使用它们登录到他们的网站。

但是基于密码的身份验证，即使有一个强大的密码，仍然需要通过网络发送密码。如果一个对手可以监视我们的网络，他们就可以看到我们的密码。我们稍后将讨论传输后安全，它可以防止网络窃听者，但更好的解决方案是在不通过网络发送密码的情况下进行身份验证。

3.2 挑战-响应协议

我们现在假设我们的计算机有一些密钥k（例如，一个随机的128位字符串），并且服务器也拥有相同的密钥k。

服务器选择一个长随机字符串r，我们通常称其为nonce，并将其发送给身份验证客户端。
客户端计算一个身份验证“标签”t←MAC（k，r），其中MAC（·，r）如果不知道k很难计算。（这里的函数MAC是一个消息认证码，我们将在？？中更具体地讨论它）将MAC标记t发送到服务器。
服务器从客户端接收到一个标签t‘，并确保t’=MAC（k，r）。如果是，则服务器认为身份验证已成功。

在实践中，客户端通常希望同时向服务器进行身份验证并发送请求请求，例如req= rm file.txt。为了实现这一点，客户端可以计算MAC标记t作为treq←MAC（k，r∥req），然后客户端将这对（treq，req）发送到服务器。通过这种方式，服务器可以同时对客户端进行身份验证，并确保请求请求来自客户端。

📝 Info

客户端同时向服务器进行身份验证并发送请求的一种不安全的方法是，客户端计算MAC标记t←MAC（k，r），然后向服务器发送（t，req）。网络攻击者可以在发送到服务器的途中将客户端的请求修改为（t，req‘），而服务器无法检测到此攻击。

4 双因素身份验证

正如我们已经看到的，密码是一种弱的身份验证机制：人类不擅长选择强密码，攻击者擅长窃取密码数据库，同时恢复许多用户的密码。

加强基于密码的身份验证系统的一种常见技术是将密码与第二种身份验证方法结合起来——一种具有不同的失败模式。常见的身份验证方案有：

一些你知道的东西：密码，PIN，等等
一些你有的东西： USB钥匙，电话，等等
一些你是的：生物识别技术（指纹，面部识别标识符）。。。

4.1 基于时间的一次性密码（TOTP）

在这种情况下，服务器会请求一个代码和密码。用户有一个设备，比如一个手机，它与服务器共享一个密钥k（例如，一个随机的128位字符串）。类似于MAC（k，gettimeofday()/30）。手机可以生成代码，并显示给用户，然后服务器可以通过重新计算代码来验证代码。

一个常见的攻击。 基于时间的一次性密码也是不完善的身份验证机制。例如，攻击者可以通过假装是技术支持人员、用户的雇主或客户服务代表，简单地要求用户给她提供一次性代码。这本质上是一种网络钓鱼攻击。然后代码可以持续30秒，所以攻击者就可以在网站的末端输入代码。类似的攻击还包括建立一个看起来像真实网站的假网站，等等。TOTP代码的一个好处（不像密码）是，攻击者必须在窃取后的30秒内使用被盗的TOTP代码，这需要更复杂的攻击。

📝 Info

网络钓鱼攻击是指攻击者欺骗用户泄露Gmail密码，例如，通过创建一个看起来像gmail.com登录页面的网站。

4.2 避免网络钓鱼：U2F（简化）

为了完全防止网络钓鱼攻击，我们可以使用一个更复杂的身份验证协议。如果我们在我们发送到该设备的请求中包含了用户试图登录到的服务器的名称，那么该代码将被绑定到一个特定的网站。例如，这些代码可能看起来有点像MAC（k，r∥amazon.com）。U2F密钥组数沿着这些线路使用一个协议来进行身份验证。如果攻击者设置了amason.com并让用户访问它，那么U2F设备将只生成一个适合amason.com的代码，而不是真正的amazon.com。

5 生物识别

生物识别学是一些物理特征，比如指纹、面部等。它们用于身份验证非常方便，因为您不会忘记它们，也不会轻易丢失它们。生物识别技术在亲自对设备进行身份验证时最有用，比如手机解锁，或授予用户访问安全保险库。在这些设置中，执行身份验证的设备有一个“可信的输入路径”，这可以提供一些保证，即拥有该生物特征的真人是在另一端。生物识别技术对于通过网络进行身份验证并不是那么有用，因为网络通常不提供可信的输入路径（也就是说，不提供任何生物识别读数来自真实的人类），而且生物识别数据本身也不是特别秘密。特别是，如果我们使用生物识别技术进行网络身份验证，一个知道你的指纹是什么样子的对手可以登录到你的账户。

Lec01-什么是安全？

Thu, 27 Feb 2025 15:12:55 +0800

本文使用人工智能协助翻译，内容仅供参考，可能有错误或遗漏。如果你对内容或超链接有疑问，可以查看原文。参考资料地址：https://github.com/PKUFlyingPig/MIT6.1600

6.1600课程团队：Henry Corrigan-Gibbs, Yael Kalai, Ben Kettle (TA), Nickolai Zeldovich 2022年秋季

⚠️ 免责声明

本套笔记为正在进行中的工作。其中可能存在错误，且缺少引用来源，内容亦不完整。如您发现任何错误，敬请告知工作人员。

1 概述

本课程的目的是向您介绍有关计算机系统安全的最重要的 “重要理念”。在整个课程中，我们将涉及计算机安全、密码学和（在一定程度上）计算机系统等领域的观点。

2 什么是安全？

安全是一个非常广泛的概念，但通常计算机安全的目标是确保某个计算机系统即使在面对试图破坏系统的“敌手”（或“攻击者”）时也能“正确运行”。

Info

在本课程中，我们将交替使用“敌手”和“攻击者”这两个术语。

为了实现这一目标，我们需要某种系统性的计划。也就是说，我们必须仔细定义系统“正确运行”的含义，并指定我们希望防御的“敌手”类别。

在本课程中，我们通常将计划分为三个部分：目标、威胁模型和实现。

目标：安全目标定义了我们希望系统实现的内容。例如，一个非正式的目标可能是“只有Alice可以读取文件F”，或者“如果有人篡改文件F，Alice将能够检测到”。正如您将在课程中学到的，确定您的安全目标究竟是什么通常是非常微妙且具有挑战性的。
威胁模型：威胁模型（或“敌手模型”）指定了我们希望防御的敌手类别。换句话说，威胁模型指定了敌手的能力：敌手在试图破坏我们的安全目标时可以做什么？通过定义威胁模型，我们可以使实现安全目标变得可行。例如，在分析基于密码的登录系统的安全性时，我们的威胁模型可能会指定敌手可以猜测密码，但不能窃取服务器。
实现：实现是我们如何实现目标。例如，我们可能会设置文件F的权限，使用Linux来强制执行这些权限，并要求双因素认证来访问系统。

Info

当你在新闻中读到安全漏洞时，值得尝试去理解这个漏洞是由于目标、威胁模型还是实现的问题引起的。

目标和威胁模型共同构成了我们对安全的定义。因此，它们不可能是“错误的”——目标可能最终并不完全符合我们的需求，威胁模型可能没有涵盖我们的系统在现实世界中可能面临的所有攻击，系统设计师在发现这一点时可能会感到惊讶，但目标和威胁模型共同定义了我们希望实现的安全属性。另一方面，实现肯定可能是错误的——如果由于错误、疏忽、供应链漏洞或其他任何原因，实现无法在威胁模型下保证目标，那么实现就存在错误。

2.1 安全是困难的

构建安全的系统是具有挑战性的。至少有两个广泛的原因。

首先，安全系统必须防御最坏情况下的行为。 安全系统必须防御威胁模型范围内的所有可能的攻击。相比之下，当我们只关注功能或正确性时，我们通常满足于一个在用户关心的场景下表现良好的系统。换句话说，安全关注的是最坏情况下的行为，而正确性通常关注的是预期情况下的行为。

Info

一些开发者确实会担心他们的系统在所有可能的输入和极端情况下的正确性；这种思维方式通常是确保安全性所必需的。

例如，假设我们有一个学生信息系统，其安全目标是：“只有助教可以访问成绩。” 测试随机抽取的助教是否可以访问成绩（正确性）很容易，但测试是否存在某种交互序列允许其他人访问成绩（安全性）则要困难得多。

其次，实现永远无法防御所有可能的威胁。 当我们指定威胁模型时，我们限定了实现必须防御的敌手集合。但现实世界中的敌手可能会以超出我们威胁模型的方式行事，从而破坏我们的安全目标。

例如，除了助教之外，其他人可能通过以下方式访问成绩：

发现服务器软件中的漏洞，
闯入助教的办公室，
入侵助教的笔记本电脑，
窃取管理员账户的密码，
诱骗助教泄露成绩，
破解服务器的加密，
在注册处找到工作并让自己成为助教。

这个列表永远不会结束。因为我们的威胁模型无法涵盖所有可能的威胁，安全永远不是完美的。几乎总是会有某些攻击者能够破坏您的系统。

这就是为什么我们需要威胁模型：威胁模型定义了我们需要担心的攻击类型，以及我们决定不在范围内的攻击类型。

2.2 设计安全目标和威胁模型

指定安全目标和威胁模型的核心在于比较防御攻击的成本与攻击发生时的成本。几乎不可能精确计算这些成本，但这个框架在概念上是有用的。能够阻止重大漏洞的廉价防御措施可能值得实施，但防御可能泄露不重要信息的射频（RF）侧信道攻击则可能不值得。

构建威胁模型总是需要迭代——您不会在第一次尝试时就做对。总会有一些您最初没有考虑到的攻击类型最终变得重要。

2.3 设计如何实现

在本课程中，我们将主要关注那些具有巨大回报的技术——开发软件和使用工具的方法，这些方法可以消除整个类别的攻击（或使它们变得更加困难）。

3 例子

我们给出了一些由于安全目标或威胁模型选择不当而导致的安全失败的例子。

3.1 错误的目标

商务舱机票。一家航空公司试图通过允许商务舱机票持有者随时免费更改机票（即出发日期、出发地和目的地）来增加其商务舱机票的价值。一位顾客意识到他们可以在登机后更改机票。然后，该顾客可以以一张机票的价格乘坐无限次商务舱航班。

在这种情况下，航空公司的目标并没有满足他们的实际需求——也许他们需要增加一个额外的目标，即“每次有人乘坐航班时，我们都会收到付款”。

莎拉·佩林的电子邮件。莎拉·佩林有一个雅虎电子邮件账户，雅虎使用安全问题来重置密码——他们的目标可能是“除非知道用户安全问题的所有答案，否则任何人都无法重置用户的密码。”（安全问题通常是诸如“您母亲的娘家姓是什么？”之类的问题。）事实证明，可以在互联网上找到佩林账户恢复安全问题的所有答案。¹雅虎的实现可能是完美的，但他们的目标并没有为某些用户提供任何有意义的安全性。

指令集架构（ISA）规范。在为处理器定义ISA时，设计者认为时间并不重要，处理器可以花费可变数量的周期来执行特定指令。这对性能和兼容性有很大的好处，但正如我们将在学期后面讨论的那样，研究人员最近利用这种时间可变性对广泛的处理器进行了复杂的攻击。²处理器的实现符合规范，但规范本身允许这种攻击。

复杂的访问控制策略。弗吉尼亚州费尔法克斯的一所学校使用了一个具有复杂访问控制结构的在线课程管理软件：每个教师负责一些班级，每个班级有许多学生，每个学生有许多文件。教师无法访问学生的文件，还有一个可以访问所有文件的校长。教师可以更改学生的密码，并可以将学生添加到他们的班级中。结果发现，教师可以将校长添加为学生，更改校长的密码，然后通过校长的账户访问所有文件。虽然每个访问控制策略单独听起来都合理，但它们共同导致了糟糕的结果。

Mat Honan的Gmail账户。一位名为Mat Honan的《连线》杂志记者的Gmail账户通过一次巧妙的攻击被攻破。³Honan有一个Gmail账户。Gmail的重置密码功能避免了使用安全问题，而是使用了一个备份电子邮件账户。攻击者触发了重置密码功能，该功能向Honan的Apple电子邮件账户发送了一个重置链接。

攻击者随后试图访问Honan的Apple电子邮件账户。攻击者触发了Apple账户的重置密码功能。Apple的重置密码功能需要Honan的地址和信用卡号码的最后四位数字。攻击者能够公开找到Honan的地址，但无法轻易找到他的信用卡号码。

攻击者通过Honan的Amazon账户找到了信用卡信息。Amazon知道他的信用卡号码，要求提供完整的信用卡号码才能重置账户。然而，Amazon允许在不登录的情况下为某个账户购买东西，只要提供一个新的信用卡号码。它还允许将这个新的信用卡号码保存到用户的Amazon账户中。因此，攻击者使用自己的信用卡在Amazon上进行了购买。然后，攻击者将自己的信用卡号码保存到Honan的Amazon账户中。接下来，攻击者触发了Amazon的重置密码功能，并使用保存到账户中的信用卡号码重置了Honan的Amazon密码并访问了他的Amazon账户。攻击者随后能够在Honan的Amazon账户中看到他真实信用卡的最后四位数字，使用这些数字重置了他的Apple邮件账户，然后使用该账户重置了Honan的Gmail账户。

像这样的复杂系统链可能非常难以推理，但这些交互最终对安全至关重要。

3.2 错误的威胁模型

假设特定策略：CAPTCHA。CAPTCHA被设计为通过自动化解决成本高昂，但人类易于阅读。确实，为CAPTCHA构建一个通用的光学字符识别系统可能成本高昂，但想要绕过CAPTCHA的攻击者并不这样做。相反，他们在劳动力成本低廉的国家建立了计算机中心。攻击者然后支付在这些中心工作的人员来解决CAPTCHA。⁴结果是，解决一个CAPTCHA的成本只有几分之一美分。解决CAPTCHA的成本仍然不为零，但成本远低于系统设计者可能预期的。

计算能力：DES。曾经有一个名为DES的加密标准，它有$2^{56}$个可能的密钥。在设计时，美国政府标准机构断言它甚至可以抵御强大的攻击者，但今天，现代计算机可以以适中的成本尝试所有$2^{56}$个密钥。（甚至在DES设计时，学术研究人员就明白56位密钥不足以防止穷举密码分析。⁵）

Info

例如，https://crack.sh/ 使用一组FPGA（现场可编程门阵列）来提供一种服务，该服务会穷举检查所有可能的密钥。

由于DES在现代计算机面前的弱点，所有使用该标准的人都必须升级他们的分组密码。例如，麻省理工学院不得不从使用DES进行身份验证转向使用具有更长密钥的更新分组密码，如AES。

依赖关系：通过短信的双因素认证（2FA）。许多2FA系统使用短信进行身份验证，但攻击者只需要说服AT&T商店的店员为您的电话号码提供一个新的SIM卡即可。

Info

这些攻击通常被称为“SIM交换”或“SIM劫持”。

软件版本：Xcode。iPhone应用程序通常在开发者的机器上创建和编译，发送到Apple的App Store，然后从那里发送到iPhone。iPhone应用程序是使用一个名为Xcode的工具创建的，该工具通常从Apple服务器下载。然而，Xcode是一个大型软件，对于中国防火墙后面的开发者来说，下载速度非常慢。中国境内的某人建立了一个更快的Xcode镜像，许多中国开发者使用了这个镜像中的Xcode版本。然而，这个镜像并没有提供Apple的Xcode版本——相反，它提供了一个稍微修改过的Xcode版本，该版本会在每个使用它编译的应用程序中注入一些恶意代码。这花了很长时间才被发现。

Info

维基百科上关于XcodeGhost的文章，https://en.wikipedia.org/wiki/XcodeGhost 提供了有关此攻击的更多详细信息。

3.3 有问题的实现

错误、配置错误和其他错误是安全问题的常见原因。一个经验法则是，每1000行代码大约会有1个错误。这是一个非常粗略的估计，但基本思想是代码越多，错误就越多。减少安全漏洞的有效策略是减少系统中的代码量。

缺少检查：iCloud。Apple的iCloud执行许多功能——电子邮件、日历、存储和“查找我的iPhone”。每个功能都有自己的登录方式，但在所有功能中，一个共同的目标是限制攻击者猜测用户密码的能力。为此，他们在所有登录界面中添加了速率限制，允许每小时只有10次登录尝试——但他们忘记了“查找我的iPhone”的登录界面。⁶由于这些认证代码在多个地方重复，有许多地方需要记住添加速率限制，但攻击者只需要一个薄弱的登录界面就可以暴力破解密码。一般来说，避免这种重复将使构建安全系统变得更加容易。

不安全的默认设置。当您设置新服务时，它们几乎总是带有一些默认设置以简化设置。Wi-Fi路由器带有默认密码，AWS S3存储桶带有默认权限，等等。这些默认设置可能很方便，但它们对安全非常重要，因为许多人会忘记或忽略更改默认设置。因此，默认设置成为系统的操作方式。为了构建一个安全的系统，重要的是默认设置是安全的。

4. 安全系统设计的一般原则是什么？

4.1 目标和威胁模型

创建简单、通用的目标。
通过更好的设计避免假设（例如“没有人能够获得用户的SIM卡”）。
学习并迭代。
实践深度防御：不要依赖单一的防御措施来保护所有安全——使用备用防御措施来防范不可避免的错误是很有用的。

4.2 实现

更简单的系统会带来更少的问题。
将安全关键部分分解为一个小的独立系统或代码片段（例如，硬件安全密钥）。
重用设计良好的代码，例如经过良好测试的加密库。
理解并测试极端情况。

参考文献

Diffie, Whitfield and Martin E. Hellman. “Exhaustive Cryptanalysis of the NBS Data Encryption Standard”. In: Computer 6.10 (1977), pp. 74–84.
Hill, Mark D. et al. “On the Spectre and Meltdown Processor Security Vulnerabilities”. In: IEEE Micro 39.2 (2019), pp. 9–19.
Honan, Mat. How Apple and Amazon Security Flaws Led to My Epic Hacking. https://www.wired.com/2012/08/apple-amazon-mat-honan-hacking/. Aug. 2012.
Motoyama, Marti et al. “Re: CAPTCHAs—Understanding CAPTCHASolving Services in an Economic Context”. In: Proceedings of the 19th USENIX Security Symposium. Washington, DC, Aug. 2010.
Trew, J. ‘Find My iPhone’ exploit may be to blame for celebrity photo hacks (update). https://www.engadget.com/2014-09-01-find-my-iphone-exploit.html. Sept. 2014.
Zetter, Kim. Palin e-mail hacker says it was easy. https://www.wired.com/2008/09/palin-e-mail-ha/. Sept. 2008.

Kim Zetter. Palin e-mail hacker says it was easy. https://www.wired.com/2008/09/palin-e-mail-ha/. Sept. 2008. ↩︎
Mark D. Hill et al. “On the Spectre and Meltdown Processor Security Vulnerabilities”. In: IEEE Micro 39.2 (2019), pp. 9–19. ↩︎
Mat Honan. How Apple and Amazon Security Flaws Led to My Epic Hacking. https://www.wired.com/2012/08/apple-amazon-mat-honan-hacking/ . Aug. 2012. ↩︎
Marti Motoyama et al. “Re:CAPTCHAs—Understanding CAPTCHA-Solving Services in an Economic Context”. In: Proceedings of the 19th USENIX Security Symposium. Washington, DC, Aug. 2010. ↩︎
Whitfield Diffie and Martin E. Hellman. “Exhaustive Cryptanalysis of the NBS Data Encryption Standard”. In: Computer 6.10 (1977), pp. 74–84. ↩︎
J. Trew. ‘Find My iPhone’ exploit may be to blame for celebrity photo hacks (update). https://www.engadget.com/2014-09-01-find-my-iphone-exploit.html . Sept. 2014. ↩︎