因此，我不断发现“通过默默无闻的安全根本不是安全”的传统智慧，但我遇到了（也许是愚蠢的）问题，即无法准确判断什么时候是“良好的安全性”，什么时候只是“朦胧'。
我检查了与此相关的其他问题，但无法找出确切的区别。
例如：有人说在非标准端口上使用 SSH 算作安全。你只是指望对方不检查。然而，SSH 所做的只是隐藏信息。它依赖于攻击者不会想到猜测正确的加密密钥的希望。
现在，我知道第一种情况（有人会认为检查特定服务的非标准端口）比第二种情况（有人会随机猜测加密密钥）更有可能，但可能性真的是全部区别吗？
而且，如果是这样，我（一个 infosec n00b，如果还不是很清楚的话）应该如何区分好的（即值得实施的）和坏的（什么不是）？
显然，不应使用已被证明易受攻击的加密方案，因此有时它比其他方案更清楚，但我正在努力解决的是我如何知道传统智慧在哪里适用和不适用。
因为，乍一看，这很清楚，但当我真正尝试推断出一个快速、一致适用的算法来审查想法时，我遇到了问题。
您所拥有的误解是通过默默无闻的安全性是不好的。实际上并非如此，仅通过默默无闻的安全性是可怕的。
这么说吧。如果有人知道它的全部工作原理，除了您控制的关键秘密组件之外，您希望您的系统完全安全。密码学就是一个很好的例子。如果您通过使用诸如 ROT13 密码之类的东西来依赖他们“看不到您的算法”，那就太糟糕了。另一方面，如果他们可以准确地看到所使用的算法，但实际上仍然无法做任何我们认为理想的安全情况的事情。
要意识到的是，你永远不想指望默默无闻，但它肯定永远不会受到伤害。我应该为我的 SSH 连接设置密码保护/使用密钥吗？绝对地。我应该依靠将服务器从 22 更改为端口 2222 来保证我的连接安全吗？绝对不。在使用密码的同时将我的 SSH 服务器更改为端口 2222 是否不好？不，如果有的话，这是最好的解决方案。更改（“模糊”）端口将简单地减少搜索正常端口的自动漏洞扫描程序堆。我们通过默默无闻获得安全优势，这很好，但我们并不指望默默无闻。如果他们找到它，他们仍然需要破解密码。
TL;DR - 只指望默默无闻是不好的。您希望您的系统是安全的，因为攻击者知道它除了特别可控的秘密信息（即密码）之外的完整工作方式。然而，默默无闻本身并不坏，实际上可能是一件好事。
编辑：为了更准确地回答您的概率问题，是的，您可以这样看待它，但要欣赏差异。端口范围为 1-65535，可以在 1 分钟内使用 nmap 之类的扫描仪快速检查。“猜测”所有 ascii 字符的随机 10 位密码是 1 / 1.8446744e+19，每秒猜测 100,000 个密码需要 580 万年。
编辑2：解决下面的评论。可以生成具有足够熵的密钥以被认为是真正随机的（https://www.rfc-editor.org/rfc/rfc4086）。如果不是，那是实施而不是哲学的缺陷。您说得对，一切都依赖于不知道信息（密码）的攻击者，而字典对晦涩的定义是“未知的状态”，因此您可以正确地说一切都依赖于某种程度的晦涩。
尽管考虑到您能够控制的信息仍然未知，但价值归结为实际安全性。密钥，无论是密码还是证书等，都（相对）易于维护。算法和其他易于检查的方法很难保密。“是否值得”归结为确定哪些可能保持未知，并根据未知信息判断妥协的可能性。
秘密很难保密。秘密越大，知道的人越多，越容易泄露。
好的秘诀是：
当我们通过默默无闻来指责某人的安全时，我们真正想说的是，我们认为他们的秘密可能更小，被更少的人知道和/或更容易改变。
算法、端口号和共享密码都未通过上述第二点和第三点。算法也失败了第一点。
什么是适当的秘密和什么时候是模糊的之间的区别在于，我们是否知道一种方法可以通过更小的秘密实现相同级别的安全性，该秘密更容易更改并且被更少的人知道。
我不同意额外的默默无闻永远不会受到伤害的断言。
-p 1234对于 SSH 端口号，每次使用 SSH时都需要额外的少量时间来输入。这只是一两秒，但随着我使用 SSH 的次数，这最终会很重要。记住这个客户略有不同并且教新员工相同，这是有开销的。在某些情况下，您忘记了该客户端位于一个奇怪的端口上，并浪费了几分钟时间查看防火墙配置和正常运行时间监视器，试图找出您无法连接的原因。
由于端口号很容易通过端口扫描发现，因此您还必须实施检测端口扫描并阻止正确端口在检查时响应或实施诸如端口敲门之类的事情的 IPS。这两种方法都可以克服，而且只会增加晦涩难懂的东西，但它们会占用您与攻击者玩猫捉老鼠的时间。
关闭 root 登录名和密码以及切换到密钥所花费的相同时间将对安全性产生更好的影响。将时间浪费在模糊细节上会影响真正的安全措施。
在秘密算法的情况下，该算法错过了许多安全研究人员可以提供的额外审查。该算法的模糊性（或保密性）可能会导致其安全性降低。
默默无闻的安全性是指您依赖某些您希望攻击者不知道的事实。这样做的一个主要问题是，一旦事实被披露，安全方案就变得毫无用处。
然而，SSH 所做的只是隐藏信息。它依赖于攻击者不会想到猜测正确的加密密钥的希望。
当讨论“隐秘的安全性”这个短语时，它通常指的是所涉及的过程，而不是秘密信息。SSH 的问题在于，作为一个过程，它已经过严格审查，以确保您唯一需要保密的是加密密钥。这对于攻击者来说原则上是不可能“思考和猜测”的，因为密码密钥所在的空间是巨大的。
Bruce Schneier 表明，为了暴力破解 256 位 AES 密钥，您至少需要捕获整个太阳的能量输出 32 年（！）。不管你的电脑有多快。这只是一个信息论结果，无论您使用哪种计算机（尽管有量子计算），它都成立。
这在目前的技术下是完全不切实际的。这并不是说 SSH 使用 AES，但它是良好密码学的原则之一。
一个示例可能是在软件中发现错误，其中（受信任的）用户发现特定输入允许绕过身份验证。一个糟糕的经理可能会说“啊，但任何不受信任的用户都不太可能发现它，为什么还要修复它”。这是默默无闻的安全。
在其他几个答案中都提到了它，但是这个难题有三个部分。
机制的一个示例是 AES 或 SHA-1，或者对于您的示例，SSH。
实现/配置的一个示例是 SSH 正在侦听哪个端口，或者您选择了哪种加密算法来加密应用程序的数据。数据的一个示例是私钥或密码。
机制永远不应该是晦涩难懂的。“它是安全的，因为你不知道它是如何工作的”不是安全。它应该能够在没有秘密数据的情况下进行详细检查，而不会被利用。
实现可能会或可能不会被掩盖。一般来说，当你这样做时，它既不会伤害也不会有助于安全。您可能会看到更少的端口扫描识别您的 SSH 端口，或者您可能能够隐藏用于特定密文的加密算法，但对于没有秘密数据的安全机制，这应该无关紧要。该机制应该仍然无法利用。有一种说法是，这里有边际的安全优势，而对可用性的损害是边际的。您的里程可能会有所不同。
秘密数据应该始终是模糊的。如果有人掌握了您的私钥或密码，您可以撤销它们，创建新的秘密数据，并发誓下次会更好地保护它。