不，您应该始终假设攻击者知道一切。大多数非政府开发人员和架构师认为默默无闻的安全性是不好的做法。它提供的障碍是微乎其微的，如果某些事情是保密的，那么隐藏一个缺陷可能就是如此。 Kerckhoffs 的原理很重要。

编辑：这个答案通常通过默默无闻来讨论安全性；不是特别适合 StackExchange。

披露有两个方面：

• 据推测，全面披露会增加善意的人找到并报告错误的可能性，以便可以快速修复它们。这就是埃里克·S·雷蒙德 ( Eric S. Raymond) 所说的“莱纳斯定律”（表达为“只要有足够的眼球，所有的虫子都是浅的。”）。尽管 ESR 和 Linus Torvalds 相信这一点，但也有其他观点。微软赞助的博客试图反驳一位著名的 Linux 倡导者，这不足为奇。然而，这两篇文章都是有趣的读物（不要相信你读到的；但想想看）。

• 据说，模糊性可以防止攻击者发现错误；或者，至少，它减慢了他们的速度。历史上有许多安全系统被破坏的例子，即使它们被掩盖了。在计算机领域，任何针对闭源软件的零日漏洞利用都足以证明。对编译后的代码进行逆向工程并不难（作为一名程序员，我有时发现处理反汇编的二进制文件比检查源代码更容易，因为源代码编写得很草率）。此外，系统架构可能记录在某处，通常是匿名书架上的纸堆或（经常）被扔进垃圾箱——这些事情很少会长期保密。这可以概括为：晦涩不全面，难以维护。

在实践中，要避免的错误是相信完全披露或模糊的效率。完全披露作为检测安全问题的一种方式并不可靠（它会发现一些，而不是全部）。隐蔽性在隐藏安全问题方面并不可靠（它会减慢一些攻击者的速度，而不是全部）。理想情况下，披露应该无关紧要（但这与“理想情况下”与“理想情况下，软件没有错误”相同）。实际上，只需假设所有情况中最糟糕的情况：考虑所有潜在的攻击者，并且只有他们，检查您的系统，并了解他们的一切。

我会说可能是从响应字符串中隐藏了确切的版本号，但是：

1. 仅当您确定协议实现稳定且正确时（您不希望某些使用版本的软件知道为您的不良协议实现采用解决方法）。
2. 这是一个非常容易实现的成果，足以阻止一些脚本小子试图找到他们知道是受感染版本的服务器。即使只是尝试他/她的漏洞列表的脚本小子也不会被阻止。

最终，任何真正的攻击者都有无数种获取此类信息的方法。从它以特定方式运行到软件 x 版本 y，再到内部可以传递细节的人。