您的誤解是模糊的安全性是不好的。實際上並非如此，通過隱蔽性實現的僅僅安全性是可怕的。

以這種方式放置。如果您知道系統的全部功能，而且您控制的關鍵秘密組件，則希望系統是完全安全的。密碼術就是一個很好的例子。如果依靠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）。如果不是這樣，那就是實現上的缺陷，而不是哲學上的缺陷。您的說法是正確的，因為一切都取決於攻擊者不知道信息（密碼），而模糊性的字典定義是“未知狀態”，因此您可以正確地說，一切都指望模糊程度。

考慮到您能夠控制未知的信息，值得付出的只是安全性。密鑰（無論是密碼還是證書等）（相對）都很容易維護秘密。算法和其他易於檢查的方法很難保密。 “值得一會兒”歸結為確定保持未知狀態的可能性，並根據未知信息判斷危害的可能性。

秘密很難保密。秘密越大，知道它的人越多，它就可能越早洩露。

好的秘密是：

• 小。
• 只有一個人知道。
• 易於更改。

當我們指責某人因默默無聞而獲得安全時，我們真正的意思是我們認為他們的秘密可能更小，更少的人知道和/或更容易更改。

算法，端口號和共享密碼都未能通過上述第二和第三點。算法也會使第一點失敗。

什麼是適當的秘密，什麼時候只是晦澀，這之間的區別在於我們是否知道一種以較小的安全性達到相同安全級別的方法。

我不同意這樣的說法，即額外的隱晦性永遠不會受到損害。

對於SSH端口號來說，每次使用SSH時，鍵入 -p 1234 所需的時間都很少。這只是一兩秒鐘，但是隨著我使用SSH的次數增加，這最終將變得很重要。要記住這名客戶略有不同，並且教導新員工相同的開銷。在某些情況下，您會忘記此客戶端位於一個奇怪的端口上，而浪費時間查看防火牆配置和正常運行時間的監視器，試圖找出無法連接的原因。

因為端口號是如此容易發現使用端口掃描時，您還必須實現一個IPS，該IPS可檢測端口掃描並在檢查端口時阻止正確的端口響應，或者實施類似端口敲門的操作。這兩種方法都是可以克服的，並且除了增加 more 默默無聞之外，什麼都沒有，但是它們佔用了您與攻擊者玩貓捉老鼠的時間。

關閉根登錄名和密碼以及切換到密鑰所花費的時間相同，將對安全性產生更好的影響。在細節上浪費時間會浪費真實的安全措施。該算法的模糊性（或保密性）可能導致其安全性降低。

默默無聞的安全性是您依賴某些希望攻擊者不知道的事實的地方。一個主要的問題是，一旦事實被披露，安全方案就變得毫無用處。

但是，所有SSH所做的事情都是在掩蓋信息。依靠這樣的希望，即攻擊者不會想到猜測正確的加密密鑰。

在討論短語“ 默默無聞的安全性”時，通常是指涉及的過程，而不是秘密信息。關於SSH的事情是，作為進程，它已經過大量審查，以確保您唯一需要保密的就是加密密鑰。從原則上講，這是不可能讓攻擊者“思考和猜測”的，因為密碼密鑰所在的空間非常。

Bruce Schneier證明了這一點是為了蠻力一個256位AES密鑰，您至少需要 ，以捕獲32年的整個太陽能量輸出（！）。計算機有多快都沒關係。這僅僅是一個信息理論結果，無論您使用什麼計算機都可以使用（儘管有量子計算）。

這對於當前技術是完全不切實際的。並不是說SSH使用AES，但這是良好加密技術的原理之一。

一個示例可能是在某個（受信任的）用戶找到特定軟件的軟件中發現了一個錯誤。輸入允許身份驗證繞過。一個糟糕的經理可能會說：“啊，但是，任何不受信任的用戶都不太可能發現這一點，為什麼還要解決它”。這就是默默無聞的安全性。

它在其他幾個答案中都涉及到，但是這個難題有三部分。

1. 機制
2. 實現/配置
3. 數據
ol>

機制的一個示例是AES，或者SHA-1，例如SSH。
實現/配置的示例是SSH正在偵聽哪個端口，或者您選擇了哪種加密算法來加密應用程序的數據。數據的示例是私鑰或密碼。

永遠不要混淆機制。 “這很安全，因為您不知道它是如何工作的”不是安全。在沒有秘密數據的情況下，應該能夠對其進行詳細的檢查，而不會利用其實現。

一個實現可能會或可能不會被隱藏。通常，這樣做不會對安全產生實質性的傷害或幫助。您可能會看到較少的用於識別SSH端口的端口掃描，或者您可以隱藏用於特定密文的加密算法，但是對於沒有機密數據的安全機製而言，這無關緊要。該機制仍應無法解釋。有一種觀點認為，這裡存在邊際安全利益，而對可用性有邊際損害。您的里程可能會有所不同。

秘密數據應該始終模糊。如果有人掌握了您的私鑰或密碼，則您將其撤消，創建新的秘密數據，並誓言下次會更好地保護它。

對模糊性的安全性適用於與不在代碼/源代碼級別解決特定弱點，而是尋找解決方法來掩蓋漏洞有關的一切。刪除該保護層後，該漏洞就會對外開放以供利用。這確實是安全神話的威脅。但是一旦有足夠的知識進行逆向工程的人員，有時甚至只是通過嗅探網絡，就會很快使它失去光澤。

通常，在SDLC階段錯過這些威脅時，這些威脅會逃到野外的主要原因系統/應用設計；從那時起，當它進入生產環境時，要維修的東西成本太高了。

另一個例子人們將密碼寫在紙上並放在鍵盤下。

市場因素，您應該知道，這種做法通常由封閉源供應商/社區遵循；對於開源項目，此概念沒有任何實際用途，因為該代碼已發布給公眾以供審查，並且幾乎任何人都可以通過諸如代碼審查之類的技術來解決問題。 b>

通過晦澀的概念實際示例破壞SSH安全性

1. 在目標網絡上運行nessus掃描將是最好的方式。為您帶來易受攻擊的服務和映射的端口
2. 在目標網絡上運行nmap掃描以獲取開放服務。
ol>

通過默默無聞的安全性並不是安全性，因為“安全性系統的安全性就像它的秘密難以猜測一樣安全”。確實，當您開始使用它時，由於加密密鑰是模糊的，因此加密可以說是通過模糊來保證安全性。區別在於它是如此的晦澀，以至於在數學上都不可行找到並因此而安全。

在任何基於秘密的安全系統中，您都希望該秘密盡可能地受限制並且難以猜測。 。秘密越複雜，其中就越有可能存在缺陷。同樣，限制必須保密的數量可以使保密變得更容易。

“通過模糊性實現安全不是安全”這一說法源於這樣一個想法，即許多“聰明”的想法只是在不斷湧現。用複雜的方法來嘗試做一些事情，使攻擊者更難弄清某些事情，但是這些方法的一個細節通常會影響其他步驟的其他細節，因此無法判斷攻擊者的努力程度秘密算法的部分知識，可以確定算法的其餘部分。

另一方面，密鑰應該是隨機的，例如，知道加密密鑰的一些位並不能幫助您找出其他位在關鍵。同樣，弄清楚密鑰的困難也很容易理解。由於算法的保密性不會對其算法的相對安全性產生重大影響（或無法可靠地量化），因此它不會增加具有統計意義的安全性。

什麼對統計信息的安全性產生了統計上的顯著影響算法是該算法的任何問題。總體而言，已經對發布的算法進行了更徹底的檢查，以檢查是否存在破壞它們的缺陷，從而通常會對它們提供的安全性具有更高的信心。

因此，在結束時，大多數安全性確實涉及某種程度的模糊性，但訣竅是使數量最小化並最大程度地保護這些機密信息，同時還嘗試確保沒有發現未被發現的缺陷，這些缺陷會導致系統行為異常並揭開秘密。

在每種加密算法中，每個登錄提示中的“隱秘安全性”都是主要組成部分。它始終依賴某種秘密知識（兩要素身份驗證除外）。

好的安全性和差的安全性之間的區別與秘密知識的屬性有關：它保密嗎？

一個不好的例子是您可以從其他渠道獲取有關此機密信息的系統。假設您發明了自己的加密算法，例如“先加密然後再與您的密鑰進行異或”。攻擊者會對您的系統進行探測，並可能從採用加密方案編碼不同的純文本消息起就確定壓縮算法。攻擊者獲得了有關您的系統的知識，了解了zip算​​法的內部知識，並且也許能夠使用此數據來確定您的密鑰。從外部看，這看起來像是一個完美的算法，壓縮後的數據和異或數據看起來非常隨機，但對老練的攻擊者僅構成很小的挑戰。您的密鑰可能很長，但這並不能幫助您區分模糊性和良好性。您不小心在算法中嵌入了一條路徑，以獲取有關您的秘密密鑰的知識：

反例是RSA公鑰加密。在這裡，秘密密鑰是一個很大的素數。公用密鑰是秘密密鑰和另一個大質數的乘積。現在，即使使用眾所周知的RSA算法，我也可以為您提供我的公鑰，您也可以使用它對任何數據進行編碼，但不會洩漏有關秘密密鑰的任何信息。

區分好安全與壞安全非常重要的是某人需要訪問您的數據的時間。在您的特定示例中，從端口22到2222只是攻擊者需要的另一點信息，因此這是安全性的加分。由於這很容易在短時間內解決，因此只增加了很少的數量，而不會洩露任何有關您的密鑰的信息。由於此端口掃描非常簡單，而且一次性花費的時間只是使了解您的秘密密鑰所需的信息總量保持不變，因此不考慮提高總體安全性，因此俗語說“默默無聞的安全性”無濟於事。

“模糊性”與假設有關

我認為“模糊性安全”實際上與錯誤的假設有關。

例如，如果我天真地使用自己的手動加密，想到“沒有人會因為它的獨特性而不會破解”：

• 我知道，有鑰匙的人可以將其破壞。
• 我假設不能通過其他方式破壞。這可能是錯誤的。

如果我使用經過驗證的加密方法：

• 我知道，它可能會被以下人員破壞：有鑰匙。
• 我有充分的證據，它不能用其他方式破壞。

我仍然依靠我鑰匙的“晦澀感”。但這是我唯一需要保護的東西。如果有人說“沒人能猜出或檢測到我們在做X”，那麼正確的回答是您有多少證據？安全標準非常高。

我是這樣寫的：

“通過隱蔽性實現安全”是指故意向攻擊者提供 all 來破壞攻擊者所需的手段/信息的情況。安全機制，希望或假設攻擊者不會花費很多精力來揭示它。

有時可以觀察到某些程序試圖通過某種“自動”加密方案來實現安全性，最後，除了加密算法之外，加密密鑰還包含在程序本身的某個位置。該程序本身將不需要進一步的信息即可解密其“秘密”數據。

'真正'的安全性將嘗試確保攻擊者永遠不會擁有破壞它們所需的全部信息。使用加密時，只要攻擊者沒有公開加密消息 ，攻擊者是否可以訪問加密消息和基本上都沒有關係。這樣，他就無法獲得關鍵信息，也無法從他僅僅繞過安全機制的信息中獲取信息。

您可以將任何所需的內容用作“秘密密鑰”，但是端口的選擇並不理想；其中只有2 ^ 16個，它們可以被嗅探，並且在連接期間它們通常是靜態的。

但是，它們已被用作過去，沒有其他的好選擇。特別是，幾年前，隨機化端口被用來應對 Kaminsky DNS緩存中毒攻擊 。結合使用隨機化的16位查詢ID，可以為我們提供32位的安全性，足以在典型的DNS查詢期間（約0.1秒）保護我們。密鑰仍然可以被嗅探，但是由於DNS始終容易受到MITM攻擊，因此被認為是“沒什麼大不了” 。 C'est la vie。

因此，您的示例是否是“默默無聞的安全”，實際上取決於上下文。

如果您有一整套保護機制，您可能會說這些保護機制中的任何一個都只是“通過隱蔽性實現的安全性”，但是考慮整個系統的安全性更為重要。

如果保護機制依賴於攻擊者沒有期望，或者該保護機制依賴於異常而不是密碼，那麼該保護機制就被視為“通過隱蔽性提供安全性”強大。換句話說，將SSH放在端口2222上可以確保安全，因為攻擊者不會期望它在那裡（這不是他們的第一個猜測），因為那不是正常的端口。但是，使用高強度密碼保護SSH是真正的安全性，因為它的密碼學性強。此外，將您的用戶名從“ root”更改為不容易猜到的東西也是真正的安全性，因為在那裡存在一定程度的加密強度：如果攻擊者無法弄清楚用戶名，即使他們無法很好地闖入系統，即使他們得到正確的密碼。

我不知道您的安全性是基於黑客不了解您的加密算法這一事實。您只需還原單詞中的字符，例如PASS-> SAPP，或進行更複雜的混淆，只要沒有人發現算法，就可以進行通信。如果發布加密算法破壞了您的所有安全性，那麼它就是模糊性，而不是安全性。給定加密和解密算法，當黑客無法解密您的消息時，真正的安全性便開始了。

通過驗證您是預期的收件人或用戶來完成安全性。有3個驗證因素

• 用戶知道的東西（例如密碼，PIN，模式）
• 用戶擁有的東西（例如ATM卡，智能卡）
• 用戶的身份（例如生物特徵，例如指紋）

大多數安全措施都使用單因素身份驗證。例如，SSH要求知道密碼或擁有私鑰（我想您可能會說，要求密鑰使用密碼短語是兩因素身份驗證）。

雙向身份驗證是最近由許多服務提供商和軟件實施的一種功能。這需要上面列出的任何兩個因素，通常是密碼和電話號碼。通過兩因素身份驗證，攻擊者可以訪問其中一個安全憑據，但仍然無法訪問受保護的系統。

通過模糊性進行的安全性是零因素身份驗證。您不需要知道任何秘密，擁有任何東西或成為任何特定的人。沒有身份驗證就沒有身份驗證，因此也就沒有真正的安全性。

如果您認為盲目的提供真正的安全性並採取虛假做法，只會傷害您。但是，如果您確實嘗試維護最佳做法（強密碼短語，應用安全更新，使用經過安全審查的算法和協議等），那麼模糊會為您從未知的未來漏洞中抽出時間，可能會有所幫助。如果您的系統易受攻擊，晦澀並不能阻止以您為目標的人發動的攻擊，但也不會宣傳您容易受到整個世界的傷害。

如果您使用的是Ruby On Rails應用程式並刊登廣告，並恰巧在去年1月休假，人們可以在您的網絡服務器上運行任意命令。實際上，廣告內容使攻擊者比必須隨機猜測您正在運行的技術堆棧並嘗試每個隨機網站的速度快得多。

或者說在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）作為麻煩，才能使所有人都使用與您相同的端口。對於內部多個用戶的工作，我將其保留到外部互聯網的防火牆中，並要求外部訪問以通過VPN。

記錄下來，我的VPS曾經在端口22上運行了ssh，日誌文件中記錄了每天約10000次/天的錯誤身份驗證嘗試（均使用不存在的用戶名）。在最近三個月的日誌文件中，我在另一個端口上運行的數據恰好為零。

我猜想，可以通過將其安全性值與受保護介質的使用複雜程度進行比較來衡量不透明性。已經有人提到過，更改SSH端口會稍微增加您的安全性，但是同時會使外殼的使用複雜化很多，因為您必須記住該端口位於哪個端口上，並向所有新員工介紹這種安全性測量，最終它會以粘滯便箋的形式貼在用戶的顯示器或自動腳本上，並在端口上進行硬編碼，從而使其安全性值無效。但是，如果有人訪問它，那麼恢復功能和變量的原始含義（例如通過仔細調試）只是時間問題，這會使混淆變得毫無意義。另一方面，您必須記住在編譯代碼之前運行特殊程序，或者（更糟糕的是，我看到了）只是使用奇怪的命名約定來處理代碼。

在我看來，您輸了通過使用隱蔽性獲得的收益比您獲得的收益還多，這就是為什麼通過隱蔽性進行安全性被認為是不好的做法。