编码员征服了安全基础设施即代码系列。密码的纯文本存储
当谈到在你自己的组织中部署安全的基础设施即代码时，你做得怎么样？这可能是一个学习曲线，但学习绳索将是一个很好的机会来提高你的技能，在你的同行中脱颖而出，并保持更多的最终用户数据安全。
在我们开始讨论我们最新的Coders Conquer Security系列的下一章之前，我想邀请你玩一个敏感数据存储漏洞的游戏化挑战；现在就玩，从Kubernetes、Terraform、Ansible、Docker或CloudFormation中选择。
那是怎样的？如果你的知识需要一些努力，请继续阅读。
如今，大多数计算机安全的关键涉及密码。即使采用了其他安全方法，如双因素认证或生物识别技术，大多数组织仍然采用基于密码的安全作为其保护的一个要素。对许多公司来说，密码是唯一使用的。
我们如此频繁地使用密码，以至于我们甚至有关于如何创建密码的规则。这应该是为了使他们不那么容易受到暴力攻击，甚至是胡乱猜测。当然，有些人仍然使用薄弱的密码，NordPass最近的一份报告就证明了这一点。很难相信，在2020年，人们仍然在使用12345以及其他一堆可猜测的单词，如巧克力、密码和上帝来保护他们最敏感的资产。
总有一些人不屑于使用强大的密码，但大多数专业机构会强迫用户以特定的方式制作他们的访问词或短语。我们现在都知道这些规则，密码需要至少八个字符，由大写和小写字母组成，至少需要一个数字和一个特殊字符。
糟糕的是，即使用户遵守了制作最强种类的密码的规则，但如果这些密码都以明文形式存储，也可能没有任何好处。如果黑客能够读取整个密码文件，12345这个密码就和Nuts53！SpiKe&Dog12一样糟糕。
为什么以明文方式存储密码是危险的？
以明文方式存储密码是不好的，因为它使系统和用户都处于危险之中。很明显，如果黑客能够找到并读取每一个用于访问系统的密码，那将是一场灾难。他们可以简单地找到一个拥有管理员证书的用户，并破坏整个系统或网站。而且，由于他们会使用适当的用户名和密码，内部安全可能不会发现入侵行为，或在损害发生后很久才发现。
让攻击者很容易窃取以明文存储的密码也会伤害到用户，因为很多人都会重复使用密码。因为我们让密码变得如此难以创建，所以很多人都会在多个网站上重复使用他们能够记住的密码。如果攻击者破坏了一个密码文件，他们几乎肯定会尝试使用相同的名字和密码访问其他系统，这使用户面临着二次犯罪的巨大风险。
不小心将密码存储在纯文本中是比较容易的，或者没有意识到这可能会在以后造成重大问题。例如，下面的代码是使用Terraform模板定义AWS资源时，用来存储密码的常见方法。
资源 "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "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 Secrets Manager这样的安全存储中。
资源 "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "${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 Secrets Manager或Azure Key Vault等安全存储，这取决于基础设施提供商。
迫使用户创建安全的密码是一个好主意，但你也需要在后端做你的工作。将密码从明文存储中分离出来，对保护你的用户和你的系统会有很大的帮助。明文密码存储的主要危险是访问控制不佳；基本上，任何人都可以看到它们。当务之急是（尤其是在IaC环境中，突然有更多的人可以接触到敏感信息），对它们进行充分的散列，只有那些绝对需要访问的人才能被授予访问权。
请查看 Secure Code Warrior博客页面，了解有关这一漏洞的更多见解，以及如何保护你的组织和你的客户免受其他安全缺陷和漏洞的蹂躏。你也可以在Secure Code Warrior 培训平台上尝试演示IaC挑战，以保持你的所有网络安全技能得到磨练和更新。
马蒂亚斯-马杜博士
马蒂亚斯是一名研究员和开发人员，拥有超过15年的软件安全实践经验。他曾为Fortify Software和他自己的公司Sensei Security等公司开发解决方案。在他的职业生涯中，马蒂亚斯领导了多个应用安全研究项目，并将其转化为商业产品，他拥有超过10项专利。当他离开办公桌时，Matias曾担任高级应用安全培训courses ，并定期在全球会议上发言，包括RSA会议、黑帽、DefCon、BSIMM、OWASP AppSec和BruCon。
马蒂亚斯拥有根特大学的计算机工程博士学位，在那里他研究了通过程序混淆来隐藏应用程序的内部工作的应用安全。
在博客上深入了解我们最新的安全编码见解。
我们广泛的资源库旨在增强人类对安全编码技术提升的方法。
获取关于开发者驱动的安全的最新研究
我们广泛的资源库充满了有用的资源，从白皮书到网络研讨会，让你开始使用开发者驱动的安全编码。现在就去探索它。
编码员征服了安全基础设施即代码系列。密码的纯文本存储
当谈到在你自己的组织中部署安全的基础设施即代码时，你做得怎么样？这可能是一个学习曲线，但学习绳索将是一个很好的机会来提高你的技能，在你的同行中脱颖而出，并保持更多的最终用户数据安全。
在我们开始讨论我们最新的Coders Conquer Security系列的下一章之前，我想邀请你玩一个敏感数据存储漏洞的游戏化挑战；现在就玩，从Kubernetes、Terraform、Ansible、Docker或CloudFormation中选择。
那是怎样的？如果你的知识需要一些努力，请继续阅读。
如今，大多数计算机安全的关键涉及密码。即使采用了其他安全方法，如双因素认证或生物识别技术，大多数组织仍然采用基于密码的安全作为其保护的一个要素。对许多公司来说，密码是唯一使用的。
我们如此频繁地使用密码，以至于我们甚至有关于如何创建密码的规则。这应该是为了使他们不那么容易受到暴力攻击，甚至是胡乱猜测。当然，有些人仍然使用薄弱的密码，NordPass最近的一份报告就证明了这一点。很难相信，在2020年，人们仍然在使用12345以及其他一堆可猜测的单词，如巧克力、密码和上帝来保护他们最敏感的资产。
总有一些人不屑于使用强大的密码，但大多数专业机构会强迫用户以特定的方式制作他们的访问词或短语。我们现在都知道这些规则，密码需要至少八个字符，由大写和小写字母组成，至少需要一个数字和一个特殊字符。
糟糕的是，即使用户遵守了制作最强种类的密码的规则，但如果这些密码都以明文形式存储，也可能没有任何好处。如果黑客能够读取整个密码文件，12345这个密码就和Nuts53！SpiKe&Dog12一样糟糕。
为什么以明文方式存储密码是危险的？
以明文方式存储密码是不好的，因为它使系统和用户都处于危险之中。很明显，如果黑客能够找到并读取每一个用于访问系统的密码，那将是一场灾难。他们可以简单地找到一个拥有管理员证书的用户，并破坏整个系统或网站。而且，由于他们会使用适当的用户名和密码，内部安全可能不会发现入侵行为，或在损害发生后很久才发现。
让攻击者很容易窃取以明文存储的密码也会伤害到用户，因为很多人都会重复使用密码。因为我们让密码变得如此难以创建，所以很多人都会在多个网站上重复使用他们能够记住的密码。如果攻击者破坏了一个密码文件，他们几乎肯定会尝试使用相同的名字和密码访问其他系统，这使用户面临着二次犯罪的巨大风险。
不小心将密码存储在纯文本中是比较容易的，或者没有意识到这可能会在以后造成重大问题。例如，下面的代码是使用Terraform模板定义AWS资源时，用来存储密码的常见方法。
资源 "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "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 Secrets Manager这样的安全存储中。
资源 "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "${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 Secrets Manager或Azure Key Vault等安全存储，这取决于基础设施提供商。
迫使用户创建安全的密码是一个好主意，但你也需要在后端做你的工作。将密码从明文存储中分离出来，对保护你的用户和你的系统会有很大的帮助。明文密码存储的主要危险是访问控制不佳；基本上，任何人都可以看到它们。当务之急是（尤其是在IaC环境中，突然有更多的人可以接触到敏感信息），对它们进行充分的散列，只有那些绝对需要访问的人才能被授予访问权。
请查看 Secure Code Warrior博客页面，了解有关这一漏洞的更多见解，以及如何保护你的组织和你的客户免受其他安全缺陷和漏洞的蹂躏。你也可以在Secure Code Warrior 培训平台上尝试演示IaC挑战，以保持你的所有网络安全技能得到磨练和更新。
