我与一个使用一些非常糟糕的做法的组织合作,例如使用默认用户帐户、默认密码(或与用户帐户相同的密码)、在用户之间共享密码信息等。
我试图保证我的部分代码库/ect 的安全,我的程序使用正确的数据库登录名和权限、强密码等。但是我的程序很容易受到更大组织缺陷的影响。例如,如果有人可以获取某些帐户信息,那么我的应用程序中的安全性就毫无意义。
我可以在这里和那里帮助改变这家公司的安全做法,还是因为“最薄弱的环节”而我的努力注定要失败?在大多数情况下,我的安全实践和他们的一样安全。
我与一个使用一些非常糟糕的做法的组织合作,例如使用默认用户帐户、默认密码(或与用户帐户相同的密码)、在用户之间共享密码信息等。
我试图保证我的部分代码库/ect 的安全,我的程序使用正确的数据库登录名和权限、强密码等。但是我的程序很容易受到更大组织缺陷的影响。例如,如果有人可以获取某些帐户信息,那么我的应用程序中的安全性就毫无意义。
我可以在这里和那里帮助改变这家公司的安全做法,还是因为“最薄弱的环节”而我的努力注定要失败?在大多数情况下,我的安全实践和他们的一样安全。
我最近看到了罗斯·安德森(Ross Anderson)写的这篇文章。除了向您的同事指出坏密码可以多快被破解之外,值得注意的是,他们的研究表明,仅仅提醒人们一些好的密码规则和对密码选择进行基本归纳有一些好处。
http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-500.pdf
如果可能,找出人们选择默认密码或共享帐户的原因,看看是否有办法解决这个问题。考虑 ssh 到多个服务器并允许一些支持人员执行相同操作的示例。您可以在这里使用密钥,而不是使用每个人都知道的单一密码,这样他们就不需要记住任何东西。他们只需使用密钥登录。如果您需要撤销密钥,请将其从服务器中删除(这显然只是一个示例)。
教育是关键,也是确保人们仍然可以轻松地继续工作的关键。仅仅要求每个人选择一个长度为 16+ 的密码,并包含多个案例和特殊字符,然后他们必须每天输入 25 次以上,这不是一个可接受的解决方案。他们根本不会这样做,而是使用他们在其他地方使用的 6 个字符的密码,因为这样更容易。
询问他们是否有安全政策。如果没有,找出是否有人负责创建一个。如果不是......考虑提出一个政策,类似这样的,但调整它......它有一些问题: http: //www.sans.org/security-resources/policies/Password_Policy.pdf
需要注意的是,当政策与现有政策(如 PCI)发生冲突时,更强的政策会获胜。添加审查条款(例如,每年)、问题导向通知、例外流程和带日期的版本控制。如果有人有问题,建议他们参加你的年会。
介绍它并附上公告和审查期,例如 3 个月。允许反馈。举行你的第一次会议。把它交给管理层,并希望它宣布一项政策。
然后为您的团队制定管理密码的流程。建议该流程作为其他团队创建符合政策的流程的指南。
一旦到位,请考虑使用工具来审核密码强度。
编辑:顺便说一句,我同意@webtoe 关于这一点。恕我直言,这是一个需要调整 SANS 等旧密码策略的区域。例如,8 个字符、大小写混合、字母数字、特殊字符、没有字典单词、一味要求 30 天密码更改策略、禁止 ssh-to-root、要求不写密码等等,都是自找麻烦。OTOH,如果你给予太多的灵活性,人们会变得马虎。密码管理的每个方面都需要一个基本原理,并且应该能够受到挑战。
我遇到的最愚蠢的密码策略之一需要使用可以检查密码强度的工具进行自动扫描。我的 SSH 自动化 ID 被反复击中,因为密码身份验证被禁用,只允许使用公钥/私钥。不幸的是,这意味着我必须每 90 天创建一个 cron 作业来创建一个随机密码。它不会传达它,但该策略有效地降低了解决方案的安全性。
别。使用 SSO:https ://en.wikipedia.org/wiki/Security_token 。
如果人们必须记住与他们的活动不直接相关的事情,他们会将其写下来,甚至对所有事情都使用一个弱而简单的密码。强迫他们选择像'!@#aa$ogh443\'这样的好密码只会让他们发疯。如果你的工作是关心安全,那么关心人民。弱记住的密码总是比写在键盘旁边的便条上的 44 个字符的密码强。
给他们身份验证令牌,他们应该随身携带,所以选择一个小而好看的;)。它可能需要在幕后进行一些额外的工作才能让所有东西都使用它,但这并非不可能,它最终使一切变得更加标准化和易于管理。