所以，我正在为我们学校设计一个门认证系统（不能详细说明），这样只有经过身份验证的人才能通过某个内门。他们认为它的内部工作应该保密，这样任何人都无法对其进行逆向工程。我坚持认为这将是Security through obscurity，这很糟糕。根据Kerckhoff 的原则，我设计了这个系统，知道它是如何工作的不会帮助你进入，只有拥有钥匙才能帮助你进入。他们仍然坚持认为，与其让更多人知道，不如让更多人知道。
采用封闭式设计是个好主意吗？如果不是，究竟为什么？
PS 他们只是在我设计了大部分内容后才告诉我这是一个秘密，并告诉了一群人，如果这有影响的话（我不知道他们希望它是一个秘密）。
PPS 虽然它不对外开放，但它所保护的房间比学校的其他房间包含更多有价值的东西，所以如果我们采用封闭式设计而不是开放式设计，我希望对手能够对其进行逆向工程一，但我不知道如何沟通。
默默无闻并不是一个糟糕的安全措施。依赖默默无闻，作为你唯一或最重要的安全措施，或多或少是一种大罪。
Kerckhoff 原则可能是最常被引用的反对通过模糊实现安全的论点。但是，如果系统根据该原则已经是适当安全的，那么这是错误的。
该原则解释为“假设敌人对你的安全系统设计了如指掌”。这绝不意味着“告诉敌人关于你系统的一切，因为他们无论如何都知道”。
如果系统已经根据 Kerckhoff 原则精心设计，那么通过隐蔽性应用安全性可以说的最糟糕的情况是它几乎没有增加任何价值。同时，对于这样的系统，保护其设计的机密性也几乎没有危害。
对设计保密并不会使门本身不安全；然而，认为它增加了安全性是一种危险的错觉。
如果透露身份验证系统的详细信息将允许破坏它，那么该系统是纯粹的垃圾，应该被丢弃。因此，如果您正确地完成了工作，那么透露细节应该是无害的。如果你没有正确地完成你的工作，那就解雇你自己，然后去雇一个有能力的人。
总的来说，发布系统细节会促进外部审查，从而导致故障修复周期，最终提高安全性。在学校环境中，不发布系统详细信息会损害安全性，因为学校里挤满了学生，而且众所周知，学生们都是爱管闲事的无政府主义者，他们特别喜欢对他们保密的任何事情进行逆向工程。众所周知，在学生机房中，降低安全事件的最佳方法是将 root/管理员密码提供给几个学生——当学生想要涉足计算机安全时，给予他完全访问权限消除了试图破坏事物的所有动机，并将他变成了一名免费的警察辅助人员来监视其他学生。
此外，详细说明安全系统的内部运作可能是一项高度教学工作。我听说在一些学校，他们至少偶尔会实践教学法。你的学校可能想试一试。
尽管@TomLeek 和@Iszi 的答案（顺便说一句都很出色）似乎直接矛盾，但您已经收到了几个很好的答案。
他们都提出了很好的观点：一方面，保持设计秘密不会使系统安全，而公开审查会使您（可能）发现某些您没有考虑过的漏洞；另一方面，对设计保密并没有什么坏处，只要这不是设计安全性的关键因素。
双方都是绝对正确的——有时。
我认为可以公平地说，一般论点中的双方都同意将设计保密并不会直接增加安全性。
在最坏的情况下，它只是隐藏了安全漏洞（这可能是也可能不是一件好事，这取决于您认为对谁最隐蔽）。
在最好的情况下（没有通过发布设计而暴露的微不足道的漏洞），它仍然不会增加安全性 - 但它确实最大限度地减少了攻击面。
最小化攻击面（即使不存在漏洞）绝对是一件好事；然而，这需要权衡和权衡发布的好处（即被额外的眼睛审查），以及保密的缺点 - 例如依赖它作为安全控制的诱惑（曾经流行的安全默默无闻），作为安全剧院的一种形式。
还值得注意的是，正如@Tikiman 所暗示的那样，仅仅发布设计并不足以确保对其进行审查——尤其是那些能够找到漏洞并且也倾向于向您披露漏洞的人。在许多情况下，发布的设计只会被那些具有不正当意图的恶意个人审查，因此您不会获得预期的收益。此外，通常人们甚至不知道他们的设计是否属于上述最佳情况或最坏情况。
所以，底线 - 就像在安全方面的许多事情一样，直接的答案仍然是：这取决于。
这里有一个明确的权衡需要考虑——如果这是一个复杂的密码系统，答案就会很清楚；如果这是一个实施繁重的典型企业系统，那么不同的答案将是明确的。
我在这种情况下的倾向正如@Tom 所说，但出于提到的次要原因 - 部分是无政府主义的用户群，主要是教学目标。
请注意，这些实际上并不是真正的安全考虑 - 至少不是直接的。
（哦，至于@Tikiman 的观点——这里涉及的教学法意味着您实际上可以确保设计得到审查，至少由整个班级审查；-)）
Daniel Missler 的这篇文章很棒！
它指出
Obscurity 的安全性很糟糕，但是当作为其他控件之上的一个层添加时，默默无闻是绝对合法的。
有了这个概念，一个更好的问题将是
考虑到我已有的控制，添加模糊是对我的资源的最佳利用，还是我最好添加一个不同的（非基于模糊的）控制？
我们也可以使用伪装的类比obscurity as another layer of security
一个强有力的例子就是伪装。考虑一个装甲坦克 ，例如 M-1。这辆坦克配备了一些最先进的装甲，并且在实际的现实世界战斗中多次被证明是有效的。
那么，鉴于这种高效的装甲，如果将其涂成与周围环境相同的颜色，对坦克的危险会以某种方式增加吗？或者将来我们可以让坦克完全隐形怎么办？我们是否降低了装甲的有效性？不，我们没有。如果或当它被发现时，使某些东西更难看到并不会使其更容易攻击。这是一个必须结束的谬误。
当目标是减少成功攻击的数量时，从可靠的、经过测试的安全性开始，并将隐蔽性作为一个层添加，确实会对安全态势产生整体效益。伪装在战场上实现了这一点，而 PK/SPA 在保护强化服务时实现了这一点。
强调我的。
Iszi 的评论也很棒，他说如果我们把这个词改成 会更好adding，enforcing所以总的来说它看起来像这样
概括：
晦涩难懂的安全性很糟糕，但是将模糊性作为其他控件之上的一层强制执行的安全性可能是绝对合法的。假设你在战场上是安全的，因为你认为你的坦克被漆成与环境相同的颜色，这只是一派胡言。但是，让你的坦克的防御能力很强，并加强油漆，让你有伪装能力作为另一层保护，这很棒！