我最近遇到了一个系统,其中所有的数据库连接都是由各种方式模糊的例程管理的,包括base 64编码,md5sums和各种其他技术.
这只是我,还是这种矫枉过正？有哪些替代方案？
通过默默无闻的安全措施将把你的钱埋在一棵树下.唯一让它安全的事情是没有人知道它在那里.真正的安全性是把它放在锁或组合之后,比如在保险箱里.你可以将保险箱放在街角,因为保证它的安全性是除了你之外没有人可以进入它.
正如@ ThomasPadron-McCarty在下面的评论中提到的那样:
如果有人发现了密码,您只需更改密码即可.如果有人找到了这个位置,你需要挖掘钱并将其移到其他地方,这是更多的工作.如果您在程序中使用默默无闻的安全性,则必须重写该程序.
通过默默无闻的安全可以说是不好的,因为它通常意味着默默无闻被用作主要的安全手段.在被发现之前,Obscurity是可以的,但是一旦有人找到你特别的默默无闻,那么你的系统再次受到攻击.鉴于攻击者持续存在,这相当于没有任何安全措施.
绝不应将晦涩作为适当安全技术的替代方案.
隐藏作为隐藏源代码以防止复制的手段是另一个主题.我对这个话题很偏袒; 我可以理解为什么你可能希望这样做,我个人从来没有遇到过需要它的情况.
通过默默无闻的安全是一个有趣的话题.它(正确地)被诽谤为有效安全的替代品.密码学中的典型原则是消息未知但内容不是.加密算法通常被广泛发表,由数学家进行分析,经过一段时间后,它们的有效性就会产生一些信心,但从来没有保证它们是有效的.
有些人隐藏了他们的加密算法,但这被认为是一种危险的做法,因为这样的算法没有经过同样的审查.只有拥有大量预算和数学人员的国家安全局等组织才能摆脱这种方法.
近年来最有趣的发展之一就是隐写术的风险,这种做法是隐藏图像,声音文件或其他媒介中的信息.隐写分析中最大的问题是确定是否存在消息,通过默默无闻来实现这种安全性.
去年我发现了一个关于研究人员计算隐写频道容量的故事,但真正有趣的是:
以这种方式研究隐秘频道会导致一些反直觉的结果:例如,在某些情况下,将寻找隐藏数据的算法数量加倍可以增加隐写频道的容量.
换句话说,用于识别消息的算法越多,它的有效性就越低,这与通过默默无闻的正常安全批评相违背.
有趣的东西.
它是一个坏主意的主要原因是它不会修复潜在的问题,只是试图隐藏它们.迟早会发现问题.
此外,额外的加密将产生额外的开销.
最后,过度默默无闻(如使用校验和)使维护成为一场噩梦.
更好的安全替代方案是消除代码中的潜在弱点,例如强制输入以防止注入攻击.
能够从安全漏洞中恢复的一个因素.如果有人发现您的密码,请重置密码.但如果有人发现你的模糊计划,你就会受到冲击.
所有这些人都认为使用默默无闻不是安全,它会花费你自己的时间.也就是说,如果实施了一个不错的安全系统,那么添加一层额外的默默无闻仍然是有用的.让我们说明天有人在ssh服务中找到了一个无法修复的破解/漏洞,无法立即打补丁.
作为一项规则,我已在内部实施......所有面向公众的服务器仅公开所需的端口(http/https),仅此而已.然后,一个面向公众的服务器将ssh暴露在互联网上的某个不起眼的高编号端口和一个端口扫描触发器设置,以阻止任何试图找到它的IP.
Obscurity在安全领域占有一席之地,但不是第一道防线和最后一道防线.在上面的例子中,我没有对ssh进行任何脚本/机器人攻击,因为他们不想花时间搜索非标准的ssh服务端口,如果他们这样做,他们不可能在另一层之前找到它安全措施并切断它们.
京公网安备 11010802040832号 | 京ICP备19059560号-6 