程序员以代码的形式征服安全基础架构系列：密码的明文存储

在自己的组织中以代码形式部署安全基础架构时，你的表现如何？这可能有点像学习曲线，但学习技巧将是提升技能、在同龄人中脱颖而出的绝佳机会， 和 确保更多最终用户数据的安全。

在我们开始最新的 Coders Conquer Security 系列的下一章之前，我想邀请你来玩一场敏感数据存储漏洞的游戏化挑战赛；立即玩游戏并从 Kubernetes、Terraform、Ansible、Docker 或 CloudFormation 中进行选择：

那怎么样？如果你的知识需要一些研究，请继续阅读：

如今，大多数计算机安全的关键都涉及密码。即使采用其他安全方法，例如双因素身份验证或生物识别，大多数组织仍将基于密码的安全性作为其保护要素之一。对于许多公司来说，密码是专门使用的。

我们经常使用密码，甚至有关于如何创建密码的规则。这本应使他们不那么容易受到暴力攻击甚至疯狂猜测。当然，有些人仍然使用弱密码，最近的一篇文章就证明了这一点 来自 NordPass 的报告。很难相信在2020年，人们仍在使用12345以及许多其他可以猜到的词语来保护他们最敏感的资产，例如巧克力、密码和上帝。

总会有人不在乎使用强密码，但是大多数专业组织会强制用户以某些方式制作访问单词或短语。我们现在都知道规则，密码必须至少为八个字符，由大写和小写字母组成，至少需要一个数字和一个特殊字符。

不好的是，即使用户遵守制作最强密码的规则，如果它们全部以明文形式存储，也可能没有任何好处。12345 的密码和 Nuts53 一样糟糕！如果黑客能够读取整个密码文件，请使用 Spike&dog12。

为什么以明文形式存储密码很危险？

以明文形式存储密码是不好的，因为它会给系统和用户带来风险。显然，让黑客能够找到并读取用于访问系统的每一个密码将是一场灾难。他们只需找到具有管理员凭据的用户并入侵整个系统或站点即可。而且，由于他们将使用正确的用户名和密码，因此内部安全部门可能无法捕捉到入侵或在损害造成很长时间后发现入侵。

让攻击者很容易窃取以明文形式存储的密码也会伤害用户，因为许多人会重复使用密码。由于我们使得创建密码变得非常困难，因此许多人不得不重复使用他们可以在多个站点上记住的密码。如果攻击者泄露密码文件，他们几乎肯定会尝试使用相同的名称和密码访问其他系统，这使用户面临二次犯罪的巨大风险。

意外将密码存储为纯文本或没有意识到这可能会在未来造成重大问题相对容易。例如，以下代码是使用 Terraform 模板定义 AWS 资源时用来存储密码的常用方法：

资源 “aws_db_instance” “默认” {
引擎 = “mysql”
分配的存储空间 = 10
instance_class = “db.t2.micro”
用户名 = “管理员”
密码 = “s3.cr3t.admin.p2ss”
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}

在该示例中，用于在 AWS 中管理 MySQL 数据库实例的密码以纯文本形式存储。这意味着任何有权访问源代码存储库的人都可以读取甚至复制它。

保护密码因框架而异，但每个平台都有保护方法。例如，MySQL 密码可以存储在 AWS 密钥管理器等安全存储器中：

资源 “aws_db_instance” “默认” {
引擎 = “mysql”
分配的存储空间 = 10
instance_class = “db.t2.micro”
用户名 = “管理员”
密码 = “$ {data.aws_secretsmanager_secret_version.password.secret_string}”
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}

在该示例中，Terraform 模板将从 AWS Secrets Manager 服务获取密码，并且永远不会以纯文本形式存储在模板文件中。

通过避免明文存储来保护密码

密码是通往王国的钥匙，切勿以纯文本形式存储。即使是组织内部的人也不应该访问大型的、不受保护的密码存储库，也不应将其作为公认的商业协议（现在有很多密码管理器允许加密凭据共享——没有任何借口！）。还存在恶意内部人员窥探文件并在不应该访问的地方获得访问权限的危险。

对于外部攻击，想象一下，如果通过 SQL 注入漏洞这样简单的东西找到了数据库的后门，他们还能访问存储密码的目录，那么可能会出现双重打击。认为这太多充满错误的步骤无法实现吗？可悲的是, 这种确切的情况发生在 索尼在2011年的违规行为。超过一百万个客户密码以纯文本形式存储，Lulzsec黑客组织通过常见的SQL注入攻击访问了这些密码以及更多密码。

所有密码都应受到支持框架内可用的任何防御措施的保护。对于 Terraform，不应将密码存储在模板文件中。建议使用安全存储，如 AWS 密钥管理器或 Azure 密钥保管库，具体取决于基础设施提供商。

强迫用户创建安全密码是个好主意，但随后你也需要在后端尽自己的一份力量。将密码保存在明文存储空间之外将大大保护您的用户和系统。明文密码存储的主要危险是访问控制不力；本质上，任何人都可以看到它们。必须对这些信息进行充分的哈希处理，只有那些绝对需要访问权限的人才能获得这些信息（尤其是在突然之间，越来越多的人可以访问敏感信息的 IaC 环境中）。

来看看 安全代码勇士 博客页面，详细了解此漏洞以及如何保护您的组织和客户免受其他安全漏洞和漏洞的破坏。你也可以 试试演示 iaC 挑战赛 在 Secure Code Warrior 培训平台中，让您的所有网络安全技能不断磨练并保持最新状态。