在什么时候算是“通过默默无闻的安全”？

#1 楼

您所误解的是，由于模糊而导致的安全性很差。实际上并非如此，仅凭晦涩难懂的安全性是可怕的。

以这种方式放置。如果您知道系统的全部功能，而且您控制的关键秘密组件，则希望系统是完全安全的。密码术就是一个很好的例子。如果依靠ROT13密码之类的东西让他们“看不见算法”，那就太糟糕了。另一方面，如果他们可以准确地看到所使用的算法，但实际上仍然无法执行任何操作，我们将看到理想的安全状况。

要意识到的事情是，您永远不想依靠晦涩难懂，但它绝对不会伤害您。我应该为SSH连接设置密码保护/使用密钥吗？绝对。我应该依靠将服务器从22更改为端口2222来保持连接安全吗？绝对不。在同时使用密码的同时将SSH服务器更改为端口2222是否不好？不，这是最好的解决方案。更改（“遮盖”）端口将仅减少搜索常规端口的自动漏洞利用扫描程序的堆。我们通过默默无闻来获得安全优势，但这是好的，但是我们并不指望默默无闻。如果他们找到了，他们仍然需要破解密码。

TL; DR-仅指望模糊是不好的。您希望系统在受到攻击者的保护的同时，知道其可以正常工作，除了可以特别控制的秘密信息（即密码）之外。但是模糊本身并不坏，实际上可以是一件好事。

编辑：要更准确地回答您的概率问题，可以，您可以这样看待问题，但要注意差异。端口范围为1-65535，可以使用nmap等扫描仪在1分钟内快速检查。 “猜测”所有ascii字符的随机说10位数字的密码是1 / 1.8446744e + 19，并且需要580万年才能每秒猜测100,000个密码。

编辑2：解决以下评论。可以以足够的熵来生成密钥，以使其被视为真正的随机密钥（http://tools.ietf.org/html/rfc4086）。如果不是这样，那就是实现上的缺陷，而不是哲学上的缺陷。您的说法是正确的，所有内容都取决于攻击者不知道信息（密码），而模糊性的字典定义是“未知状态”，因此您可以正确地说，一切都取决于模糊性。

考虑到您能够控制未知信息的重要性，一旦有价值的东西归结为实用的安全性。密钥（无论是密码还是证书等），（相对）易于维护。算法和其他易于检查的方法很难保密。 “值得一会儿”归结为确定保持未知状态的可能性，并基于未知信息判断危害的可能性。

#2 楼

秘密很难保密。秘密越大，知道它的人越多，它就可能越早泄漏。 >只有一个人知道。
易于更改。

当我们通过默默无闻指责某人安全时，我们实际上是在说，我们认为他们的秘密可能更小，更少的人知道和/或更容易更改。

算法，端口号和共享密码都无法通过上述第二和第三点。算法也未能通过第一点。

当什么是适当的机密与只是晦涩难懂之间的区别是，我们是否知道一种以更容易更改的较小机密实现相同安全级别的方法。并且被更少的人所了解。


我不同意这样的说法，即额外的模糊性永远不会造成损害。

对于SSH端口号来说，每次使用SSH时键入-p 1234所需的额外时间。这只是一两秒钟，但是随着我使用SSH的次数增加，这最终将变得很重要。要记住这名客户略有不同，并且教导新员工相同的开销。在某些情况下，您会忘记此客户端位于一个陌生的端口上，而浪费大量时间查看防火墙配置和正常运行时间监视器，试图找出无法连接的原因。
因为端口号非常容易使用端口扫描进行发现时，您还必须实施IPS，以检测端口扫描并阻止正确的端口在检查时作出响应，或者实施类似端口敲门的操作。可以克服这两种方法，并且不会增加任何其他隐晦之处，但是它们会占用您的时间与攻击者玩猫捉老鼠。

关闭根登录名和密码以及切换到密钥所花费的时间相同，将对安全性产生更好的影响。在细节上浪费时间可以避免真正的安全措施。

在使用秘密算法的情况下，该算法会错过许多安全研究人员可以提供的额外检查。该算法的模糊性（或保密性）可能导致其安全性降低。

评论

---

我并不是说要防御，但是您是否会说其他端口的开销确实很重要？对于简单的端口更改，请避免使用大多数自动漏洞利用扫描程序寻找错误配置的方法。我要说-p 2222从任何实际意义上来讲都不是很大的开销。

– Peleus
13年3月6日在9:31

---

@Ladadadada有一个完全有效的观点。尽管更改默认的SSH端口是防止自动化工具的常见做法，但它也有缺点。例如，到另一个端口22的向内连接可能会被另一家公司的客户端防火墙等阻止。除此之外，在3次登录尝试后，可以通过简单的IP禁令轻松阻止自动工具。它并没有添加一个很难的新端口，您需要让每个员工（内部和外部）都熟悉它，而所有这些努力似乎都不值得。

–罗汉·杜尔维（Rohan Durve）
13年3月6日在10:45

---

@Adnan我已经提到过，我不会强烈地争论这会带来很大的开销（因为不是），但是您只关注在非标准端口上使用SSH的一个方面，我提到了几个方面。 。您似乎还想争论与安全无关的事情。任何浪费在处理非标准端口上的时间（包括在〜/ .ssh / config中添加行以及编写用于登录的脚本）都是您可以花费在增加真正的安全性上的时间。

– Ladadadada
13年3月6日在13:04

---

@Ladadadada，如果您不想批评您的意见，请不要在SE上发布。作为服务的用户（在本例中为SSH），您可以添加很多“真正的”安全性。将SSH端口从默认的22更改为一个好习惯，我的观点是，它可以防止大量的自动攻击。您说这不是一个好习惯，您的论据是写shell脚本浪费了10秒钟，并且您辩称在10秒钟内您将采取某些措施来影响SSH的安全性。

–阿迪
13年6月6日在13:25

---

我的观点总是受到批评，但我的论点是“附加的模糊永远不会伤害”的说法是错误的。我不会争论-p 1234的原因是，这不是我实际争论的重要部分。它仅是模糊性伤害的示例（尽管伤害可能微乎其微），之所以选择它是因为它在原始问题中，而不是因为它是一个很好的例子。如果我们假设您是对的，并且更改SSH端口值得花任何时间，那么我的论点丝毫不会减弱。

– Ladadadada
13年3月7日在22:54

---

#3 楼

默默无闻的安全性是您依赖某些希望攻击者不知道的事实的地方。一个主要的问题是，一旦事实被揭露，安全方案就变得毫无用处。


但是，SSH所做的一切都是在掩盖信息。它依靠的是希望攻击者不会考虑猜测正确的加密密钥。


在讨论“隐秘的安全性”一词时，它通常指的是所涉及的过程，而不是秘密信息。关于SSH的事情是，作为一个过程，它经过了严格的审查，以确保您唯一需要保密的就是加密密钥。从原理上讲，这不可能使攻击者“思考和猜测”，因为加密密钥所在的空间很大。

Bruce Schneier表明，为了强行使用256位AES密钥您至少需要捕获32年的整个太阳能量输出（！）。计算机有多快都没关系。这只是一个信息理论结果，无论您使用什么计算机都可以使用（尽管有量子计算）。

这对于当前技术是完全不切实际的。这并不是说SSH使用AES，但这是良好加密技术的原理之一。

一个示例可能是在某个（受信任的）用户发现一个软件的软件中发现了一个错误。特定输入允许绕过身份验证。一个糟糕的经理可能会说：“啊，但是，任何不受信任的用户都不太可能会发现这一点，为什么还要解决它”。这是默默无闻的安全。

#4 楼

在其他几个答案中也涉及到该问题，但此难题有三部分。


机制
实现/配置
数据

机制的一个例子是AES或SHA-1，或者例如SSH。
一个实现/配置的示例是SSH正在侦听哪个端口，或者您选择了哪种加密算法来加密应用程序的数据。
数据的一个例子是私钥或密码。

永远不要混淆机制。 “这很安全，因为您不知道它是如何工作的”不是安全。在没有秘密数据的情况下，应该能够对其进行详细的检查，而不会利用其实现。

实现可能会被掩盖，也可能不会被掩盖。通常，这样做不会对安全产生实质性的伤害或帮助。您可能会看到较少的用于识别SSH端口的端口扫描，或者您可以隐藏用于特定密文的加密算法，但是对于没有机密数据的安全机制，这无关紧要。该机制仍应无法解释。有人争论说，这里有边际安全利益，而对可用性有边际损害。您的里程可能会有所不同。

秘密数据应始终晦涩难懂。如果有人掌握了您的私钥或密码，则您将其撤消，创建新的秘密数据，并誓言下次会更好地保护它。

#5 楼

默默无闻的安全性适用于与未在代码/源代码级别解决特定漏洞有关的所有事情，而是可以找到解决方法来掩盖漏洞。删除该保护层后，该漏洞就会对外开放以供利用。

这样的示例就是程序挂钩，它为开发人员提供了一种在生产环境中连接到应用程序的隐蔽方式。这确实是安全神话的威胁。但是它很快就会被那些有足够知识进行逆向工程的人员（有时只是通过嗅探网络）失去光泽。

通常，这些威胁是在系统/应用程序的SDLC阶段中被忽略时逃脱的主要原因。设计;从那时起，当它进入生产环境时，要维修的东西成本太高了。这是解决方法或掩盖的开始。

另一个示例
人们将密码写在纸上并将其放在键盘下。市场因素，您应该知道，这种做法通常由封闭源供应商/社区遵循；对于开源项目，此概念没有任何实际用途，因为该代码已发布给公众以供审查，并且几乎任何人都可以通过诸如代码审查之类的技术来解决问题。最好，最可靠的捕获方法。

通过模糊概念的实际示例破坏SSH安全性


在目标网络上运行nessus扫描会使您容易受到攻击服务和映射的端口
在目标网络上运行nmap扫描以获取开放服务。

#6 楼

默默无闻的安全性并不是安全，因为“一个安全系统的安全性就像它的秘密难以猜测一样安全”。确实，当您开始使用它时，由于加密密钥是模糊的，因此加密可以说是通过模糊来保证安全性。区别在于它是如此的晦涩，以至于在数学上是不可能找到和保护它的。

在任何基于机密的安全系统中，您都希望机密尽可能地受限制并且难以猜测。可能。秘密越复杂，其中就越有可能存在缺陷。同样，限制必须保密的数量也可以使保密变得更容易。

“通过默​​默无闻的安全不是安全”的说法源于许多“聪明”的想法即将到来的想法。想出了一些复杂的方法来尝试做一些事情，使攻击者更难弄清事情，但是这些方法的一个细节通常会影响其他步骤的其他细节，因此无法判断攻击者的辛苦程度另一方面，密钥应该是随机的，例如，知道加密密钥的一些位并不能帮助您弄清楚密钥的种类。密钥中的其他位。类似地，弄清楚密钥的困难也很容易理解。由于算法的保密性不会显着影响（或可靠地量化）算法的相对安全性，因此不会增加统计上显着的安全性。

什么对安全性产生了统计上显着的影响算法的问题是该算法的任何问题。总的来说，已经对发布的算法进行了更彻底的检查，以检查是否存在任何破坏它们的缺陷，从而通常会对它们提供的安全性具有更高的信心。

因此，在结束时，大多数安全性确实涉及某种程度的模糊性，但是诀窍是使数量最小化并最大程度地保护这些秘密，同时还要尝试确保没有发现未被发现的缺陷，这些缺陷会导致系统行为不检并揭示安全隐患。机密。

#7 楼

在每种加密算法中，每个登录提示中的“隐秘安全性”都是主要组成部分。它始终依赖某种秘密知识（两因素身份验证除外）。

好的安全性和不好的安全性之间的区别与秘密知识的属性有关：它是否保密？

一个不好的例子是可以获取信息的系统关于其他渠道的秘密假设您发明了自己的加密算法，例如“先加密然后再与您的密钥进行异或”。攻击者会对您的系统进行探测，并可能从采用加密方案编码不同的纯文本消息起就确定压缩算法。攻击者获得了有关您的系统的知识，了解了zip算​​法的内部知识，并且也许能够使用此数据来确定您的密钥。
从外观上看，这是一个非常好的算法，压缩和异或的数据看起来非常随机，但对老练的攻击者来说仅构成很小的挑战。您的密钥可能很长，但这并不能帮助您区分模糊性和良好性。您不小心在算法中嵌入了一条路径，以获取有关您的秘密密钥的知识：

反例是RSA公钥加密。此处的密钥是一个大质数。公钥是秘密密钥和另一个大质数的乘积。现在，即使有了众所周知的RSA算法，我也可以为您提供我的公钥，您也可以使用它对任何数据进行编码，但是它不会泄漏有关密钥的任何信息。

区分好密钥非常重要安全性差的原因是有人需要访问您的数据。在您的特定示例中，从端口22到2222要做的是攻击者需要的另一点信息，因此这是安全性的加分。由于这很容易在短时间内弄清楚，因此只增加了很少量，而不会泄漏任何有关您的钥匙的信息。
由于此端口扫描非常简单，而且一次性花费的时间仅使了解您的秘密密钥所需的信息总量保持不变，因此这就是为什么不考虑提高总体安全性的原因，因此俗称“通过晦涩”无济于事。

#8 楼

“模糊性”与假设有关

我认为“模糊性安全”实际上与错误的假设有关。

例如，如果我天真地使用自己的手动加密技术， “没有人会因为它的独特性而知道如何破解它”：


我知道有钥匙的人可以破解它。
我认为不可能被其他方式破坏。这可能是错误的。

如果我使用经过验证的加密方法：


我知道有钥匙的人可能会破坏它。
我有充分的证据表明它无法通过其他方式破解。

我仍然依靠密钥的“模糊性”。但这是我唯一需要保护的东西。

因此，要检测“默默无闻的安全性”，请挑战假设。如果有人说“没人能猜测或检测到我们在做X”，那么正确的答案就是您有多少证据？安全标准非常高。

#9 楼

我会这样写：

“通过隐秘的安全性”是指故意为攻击者提供了破坏安全机制所需的所有手段/信息的情况，希望或假设攻击者

有时可以观察到某些程序试图通过某种“自动”加密方案来实现安全性，最后，除了加密算法之外，加密密钥包含在程序本身的某个位置。该程序本身将不需要进一步的信息即可解密其“秘密”数据。

'真实'安全性将尝试确保攻击者永远不会拥有破解它所需的所有信息。使用加密时，只要攻击者没有向他透露加密密钥，攻击者是否可以访问密码消息和创建该消息的算法就基本上无关紧要。这样，他就无法获得关键信息，也无法从他仅仅绕过安全机制的信息中获取信息。

#10 楼

您可以将任何所需的内容用作“秘密密钥”，但是端口的选择并不理想；它们只有2 ^ 16个，可以被嗅探，并且在连接期间它们通常是静态的。

但是，它们已被用作秘密密钥（的一部分）过去没有别的好选择。特别是，从几年前开始，随机使用端口来抵抗Kaminsky DNS缓存中毒攻击。结合使用随机化的16位查询ID，可以为我们提供32位的安全性，这足以在典型的DNS查询期间（约0.1秒）保护我们。密钥仍然可以被嗅探，但是由于DNS始终容易受到MITM攻击，因此它被认为“没什么大不了”。 C'est la vie。

因此，您的示例是否是“默默无闻的安全性”，实际上取决于上下文。

#11 楼

如果您拥有一整套保护机制，那么您可能会说这些保护机制中的任何一个都只是“默默无闻的安全性”，但是更重要的是要考虑整个系统的安全性。

如果保护机制依赖于攻击者没有期望的东西，或者该保护机制依赖于不寻常而不是密码学上的强势，那么该保护机制就被视为“通过模糊性实现安全”。换句话说，将SSH放在端口2222上通过隐晦的方式是安全的，因为攻击者不会期望它在那里（这不是他们的第一个猜测），并且因为那不是正常的端口。但是，使用高强度密码保护SSH是真正的安全性，因为它的密码学性强。此外，将您的用户名从“ root”更改为不容易猜到的东西也是真正的安全性，因为在那里存在一定程度的加密强度：如果攻击者无法弄清楚用户名，即使他们无法很好地闯入系统，即使他们得到正确的密码。

#12 楼

默默无闻，我知道您的安全性是基于黑客不了解您的加密算法这一事实。您只需还原单词中的字符，例如PASS-> SAPP，或进行更复杂的模糊处理，只要没有人发现算法，就可以进行通信。如果发布加密算法破坏了您的所有安全性，那么它就是模糊性，而不是安全性。给定加密和解密算法，当黑客无法解密您的消息时，真正的安全性便开始了。

#13 楼

通过验证您是预期的收件人或用户来完成安全性。认证有3个因素


用户知道的东西（例如密码，PIN码，图案）
用户拥有的东西（例如ATM卡，智能卡）
用户的情况（例如生物特征，例如指纹）

大多数安全措施都使用单因素身份验证。例如，SSH要求知道密码或拥有私钥（我想您可以说，要求密钥使用密码短语是两因素身份验证）。

两要素身份验证是最近由许多服务提供商和软件实现的一种东西。这需要上面列出的任何两个因素，通常是密码和电话号码。通过两因素身份验证，攻击者可以访问其中一个安全凭据，但仍然无法访问受保护的系统。

通过模糊性进行的安全性是零因素身份验证。您不需要知道任何秘密，拥有任何东西或成为任何特定的人。没有身份验证就没有身份验证，因此也就没有真正的安全性。

#14 楼

如果您认为模糊不清会为您提供真正的安全并采取虚假做法，那么只会伤害您。但是，如果您确实尝试维护最佳做法（强密码短语，应用安全更新，使用经过安全审查的算法和协议等），那么模糊会为您从未知的未来漏洞中抽出时间，可能会有所帮助。如果您的系统易受攻击，则模糊不清不会阻止以您为目标的人发动的攻击，但也不会宣传您容易受到整个世界的伤害。

如果您使用的是Ruby On Rails应用程序并做广告，并且恰好在去年1月休假，人们可以在您的Web服务器上运行任意命令。实际上，该广告使攻击者比必须随机猜测您正在运行的技术堆栈并尝试每个随机网站的速度快得多。

或者说在SSH中发现了零日漏洞；有点像几年前的Debian SSH密钥生成问题。人们将开始随机扫描以找到在随机IP地址的端口22上运行的ssh，然后运行漏洞利用程序。当然，他们可以先进行端口扫描以搜索ssh，但攻击者将首先寻找低谷的果实。全面搜索将使他们的扫描速度降低10000倍以上。希望届时您已经修补了该问题。大多数随机IP地址将不会运行ssh或其他任何内容，因此对于攻击者来说，在端口22（可能还有其他222、2222和22222）之后停止扫描也很有意义。如果您的家庭服务器不响应ping并将所有数据包丢弃到端口，但不是39325，则它们很可能会在找到您的ssh服务器之前继续运行。默默无闻对您有帮助。是的，网络窃听者可以轻易地发现您的端口在一个ssh连接上进行监听。但是对于绝大多数随机地将您作为目标的攻击者，他们不会通过侦听您的网络流量来观察到ssh连接。此外，即使对于那些攻击者，您仍然希望您有99.9％的时间认为ssh配置是安全的并且没有漏洞。

并且由于输入ssh -p 39325 -Y foologin@foo.subdomain.example.com的额外麻烦，使用ssh的任何人都经常设置一个~/.ssh/config文件（以及authorized_keys和id_rsa.pub / id_rsa），因此他们可以在键入私钥密码后键入ssh foo进行连接。现在，您的配置文件将记住完整的域名，您的用户名，端口（如果不是22）以及任何其他标志。对于ssh，如果它面向互联网，我将更改端口，只有我用它（我的家用计算机，我的VPS）作为麻烦，才能使所有人都使用与您相同的端口。对于内部多个用户的工作，我将其保留到外部Internet的防火墙中，并要求外部访问才能通过VPN。

作为记录，我的VPS曾经在端口22上运行ssh，并在日志文件中记录了大约10000 /天/天的错误身份验证尝试（所有这些用户使用不存在的用户名）。在最近三个月的日志文件中，我在另一个端口上运行的数据完全为零。

#15 楼

我猜想，可以通过将其安全性值与受保护介质的使用复杂程度进行比较来衡量模糊性。已经有人提到过，更改SSH端口会稍微增加您的安全性，但是同时会使外壳的使用复杂化很多，因为您必须记住该端口位于哪个端口上，并向所有新员工介绍这种安全性测量，最终它会以粘滞便笺的形式贴在用户的显示器或自动脚本上，并带有硬编码的端口，从而使其安全性值无效。

类似地，您可以混淆源代码以对其进行保护。 。但是，如果有人访问它，那么恢复功能和变量的原始含义（例如通过仔细调试）只是时间问题，这会使混淆变得毫无意义。另一方面，您必须记住在编译代码之前运行特殊程序，或者（更糟糕的是，我看到了）只是使用奇怪的命名约定来处理代码。

我认为，您通过使用模糊不清所带来的损失大于获得的收益，这就是为什么通过模糊不清进行安全保护被认为是不好的做法。