題:
通過對失敗的登錄嘗試給出錯誤的肯定答案,是否有可能使暴力破解無效?
Tweakimp
2016-07-13 02:25:39 UTC
view on stackexchange narkive permalink

我沒有任何安全方面的經驗或科學知識,我只是想問一問這是否可行,因為我對此感興趣。

如果我加密數據並且每個密碼都將其解密怎麼辦,但是只有正確的登錄帳戶才不會造成毫無意義的數據混亂?登錄可以做到這一點:錯誤的登錄數據會導致虛假的虛擬帳戶,只有正確的登錄詳細信息才能將您定向到正確的帳戶。

將“這不是一種更好的加密方法,因為您不能只是嘗試使用密碼,而必須查看結果以查看是否正確?

聽起來像[一次性墊](https://en.wikipedia.org/wiki/一次性墊)。
[蜜罐](https://en.wikipedia.org/wiki/Honeypot_(計算))或[垃圾郵件](https://en.wikipedia.org/wiki/Spamtrap)是一個旨在浪費的系統機器人的時間。
它只能在線運行,並且您應該不能在第一位強行使用在線密碼...
好吧,當您嘗試強行加密文本時,這是您必須要做的。當您正確地進行解密時,沒有神奇的鈴鐺會告訴您,您必須查看輸出並進行檢查。如果有人加密了壓縮文件,而您僅檢查嘗試是否生成純文本,即使嘗試所有可能的密鑰,也將永遠無法解密該文本。
@Bakuriu:對於較差的加密系統,您可以僅解密前四個字節(精確稱為魔術數字,[我不是在開玩笑](https://en.wikipedia.org/wiki/File_format#Magic_number);)!)和檢查您是否獲得了正確的ZIP文件頭(不是我認為ZIP實際上提供了一個糟糕的系統,但我只是在重用您的示例)。使用好的加密系統,您必須首先解密*整個*文件,然後,您才能檢查解密密鑰是否確實正確。
@WhiteWinterWolf您的發言很明顯,但您沒有明白我的意思。重新閱讀。
@Bakuriu:最實用的加密系統包括一個哈希,它會告訴您何時正確解密。此外,某些加密方案,例如全磁盤加密的目的是使您可以高效地進行隨機訪問,因此無需解密整個卷即可知道擁有正確的解密密鑰。
@LieRyan我看不到您的評論有何意義。就像我說的那樣:如果僅檢查**,以查看解密是否正確,就是檢查結果(如純文本ASCII **)是否可理解,那麼您將永遠無法解密壓縮的加密消息。期。在這種情況下沒有哈希。我的觀點是,按照定義,通過蠻力進行解密需要您查看“解密的數據”並確定是否正確,有時很容易,有時很難或不可能做到。
不要忘記您的用戶。您的加密方案是否可以處理“愚蠢的軟件,偶爾解密我的文件時會產生垃圾”問題?如果您只有少數幾個足夠了解的技術用戶,那麼它可能會有用。但是,如果您要針對許多未受過教育的用戶,那麼出於您自己的理智,請輸入“錯誤的密碼!”。對話框 :)
值得一提的是,Vim在加密文件上使用錯誤的加密密鑰時會產生垃圾。但是,由於輸出結束時充滿了控製字符,因此很容易看出來。
@LieRyan在正確構建的加密系統中,對數據進行加密,然後應用MAC(使用哈希)。如果採取其他方法,則MAC [Hash]然後進行加密,然後是的,您可以使用MAC來告訴您是否具有有效的解密。這使暴力攻擊更加容易。因此,這就是為什麼現代系統不這樣做的原因(FYI,這是SSL中眾所周知的錯誤)。有關更多詳細信息,請參見https://moxie.org/blog/the-cryptographic-doom-principle/。
這應該隨機發生,而不是始終如一。例如。大約100次錯誤登錄時,會出現誤報。
除了出色的答案外,還請看一下相對較新的Honey加密:https://en.wikipedia.org/wiki/Honey_Encryption
有一種方法可以處理公共論壇上的垃圾郵件,烈火等內容,這使我想起了OP的建議:這個想法不是要告訴發布者論壇軟件認為他的帖子是不可接受的,而是要展示他的帖子。郵寄給他,並且僅郵寄給他,就好像已被接受一樣。他將是唯一看到歷史記錄的人,但認為他成功了。
九 答案:
Cort Ammon
2016-07-13 02:32:53 UTC
view on stackexchange narkive permalink

答案始終取決於您的威脅模型。安全總是編織在安全性和可用性之間的平衡中。您的方法會給試圖闖入該帳戶的黑客帶來不便,但也會給僅輸入密碼錯誤的用戶帶來不便。如果偽造帳戶足以欺騙攻擊者,那麼它也可能足以欺騙有效用戶。這可能非常糟糕。

這在極高風險的環境中可能是理想的。如果您必須在互聯網上公開存儲核秘密,那麼使每個失敗的密碼都將導致您進入一個可以訪問偽造文件的帳戶,而該文件實際上並沒有洩露國家秘密。但是,在大多數情況下,這是不必要的。

您還必須考慮其他選擇。一種非常流行的方法是在N次嘗試之後將帳戶鎖定,這基本上使所有蠻力嘗試都停止了,並具有大多數用戶願意接受的可用性行為。

謝謝您的回答。實際上,我想知道是否有可能,而不是有用,也許是我沒有看到的某些東西使我的想法毫無意義。
當涉及到可能性時,唯一的限制將是您是否願意花時間創建一個虛擬帳戶的現實問題。查找數據的一個有趣地方是可拒絕的加密。在可否認的加密中,您將創建一個虛擬分區,並使攻擊者無法以數學方式證明任何其他分區都存在。該社區對如何使虛擬分區看起來合法表示了極大的興趣。
這樣的帳戶也可以用作蜜罐,當有人登錄那裡時,蜜罐會觸發安全傳感器,以便您可以及早發現攻擊者。
蜜罐登錄嘗試的問題是有效用戶不會意識到這些不是真正的計劃,因此他們會構建無法正常工作的核武器。希望您的虛假計劃不會破壞安全檢查。我見過的最有效的方法是強制用戶在兩次登錄嘗試之間等待的時間越來越長。強迫他們放慢腳步,思考他們正在輸入的內容。這樣,當他們達到N次嘗試限制時,就不足為奇了。
@CandiedOrange-這是一個帶有虛假信息的虛擬帳戶。沒有合法用戶可以登錄。如果有人竊取了計劃並建立了無法正常工作的核武器,則表明系統正在按預期運行。
@Johnny我認為可能會有些混亂。我將OP的問題翻譯為“每次無效登錄都應該成功,但要創建一個虛擬帳戶”,因此,用戶錯誤地輸入密碼錯誤並到達該帳戶非常有可能。如果改為設置蜜罐,以使*大多數*無效登錄名讓您知道該登錄名無效,但是使用各種用戶名放置了幾個蜜罐,那麼您是正確的。沒有用戶會錯誤地登錄到這種蜜罐。
經過幾次失敗的嘗試(3?),而不是將您鎖定在帳戶之外,將您帶入偽造帳戶的組合肯定會很有趣。附帶說明一下,我曾經在用戶表PK是user + password的地方工作。
“並且具有大多數用戶願意接受的可用性行為” ...對於較高的N值。=)
對於低N值,這是DOS攻擊。DOS攻擊損害了可用性,CIA信息安全三合會中的A。
-1
John Wu
2016-07-13 04:06:09 UTC
view on stackexchange narkive permalink

用誤報來欺騙攻擊者並不是一個壞主意,這也不是新鮮事。以下內容可能會讓您感興趣。

密碼偽裝

CA技術已獲得稱為“ 密碼偽裝”的技術的專利。

公鑰加密的一個敏感點是如何保護私鑰。我們概述了一種使用加密偽裝保護私鑰的方法。具體來說,我們不會使用太長的密碼來進行詳盡的攻擊,以加密私鑰。取而代之的是,我們對它進行加密,以便只有一個密碼可以正確地對其進行解密,但是許多密碼可以對它進行解密,以產生看起來足夠有效以欺騙攻擊者的密鑰。對於某些應用程序,此方法可以像智能卡一樣保護私鑰免受字典攻擊,但完全在軟件中。

這與您所說的不完全相同(它們是保護密鑰,而不是訪問密鑰),但概念是相同的。

Mousetrap

在1984年,Michael Crichton(Andromeda Strain和許多人的作者)其他人)寫了一個短篇小說,圍繞一個黑客,他認為他正在竊取最高機密文件。他猜出了正確的密碼,但是對於他來說,計算機實際上並不是通過查看他的密碼,而是通過他使用鍵盤和鼠標的速度和方式對他進行身份驗證,這是一種生物特徵認證機制。他認證失敗。但是計算機沒有告訴他失敗了,而是向他提供了一份偽造的秘密文件副本,然後他下載並試圖在黑市上出售。

再次,這與您要問的不完全相同,但是(無論如何,在小說中)它證明了使用誤報來阻止攻擊。

加密偽裝讓我想起了TrueCrypt如何加載[根據提供的密碼,是誘餌還是隱藏的OS](http://andryou.com/truecrypt/docs/hidden-operating-system.php)。
另一個很好的例子!
Tyler Gallenbeck
2016-07-13 04:00:22 UTC
view on stackexchange narkive permalink

要給您一個直接的答案,,可能會降低蠻力攻擊的有效性,並且可以按照您建議的方式進行,但不應該這樣做。僅通過在每次失敗嘗試和下一次猜測之間實施時間延遲,就可以得到非常相似的結果。同樣,(僅就您所知)非常精確和相似的技術已經針對此具體事物進行了設計和實現。諸如 Canary,Honey Pots和Honey Docs之類的產品都提供類似的東西,例如假環境,設備,服務器,帳戶等。

好的,但是加密文件呢?您不能在失敗的解密嘗試之間設置延遲,可以嗎?
我認為您也無法在可靠的容器中製作足夠多的偽造文件集,從而無法可靠地欺騙自動破解工具。如果攻擊有可能進行離線攻擊,則必須依靠其他強化技術(例如密鑰派生功能)來限制單位時間的嘗試次數。
您可能對@Tweakimp,感興趣“ TrueCrypt隱藏卷”。聽起來就像您在描述什麼。(但是它只有兩個密碼,不是無限的。)
@Wildcard謝謝,我來看看。兩種聲音比無限小;)
直到Quantum計算成為現實,每秒嘗試次數達到新高度的@SimonLindgren。因此,密鑰派生功能也必須增加。
Peteris
2016-07-14 00:43:28 UTC
view on stackexchange narkive permalink

效果很小

讓我們假設您的系統將實際的蠻力從解密前四個字節(實際上是第一個大得多的塊,但隨便什麼)轉變為必須解密整個字節。 4 GB的加密數據,使暴力破解的嘗試速度降低了大約十億倍或2 ^ 30倍。

現在,對您來說,這似乎有很大的不同,但實際上,與其他替代方法相比,該效果是 微小 。在密碼學世界中,僅僅是“慢十億倍”的規模就沒有那麼多了。如果只是增加額外的30位到加密密鑰長度上做同樣的事情,並增加密鑰大小,例如為什麼增加複雜性而又可能無法實現預期的速度降低或引入新的錯誤,那又何必呢?從128位(如果還不夠的話)到256位會提供無與倫比的效果嗎?

gpinkas
2016-07-13 16:23:29 UTC
view on stackexchange narkive permalink

大多數人已經說過,我只想提供另一種觀點。

想像一下,您將嘗試使用這種技術來保護房屋。如果入侵者試圖打開門一段時間,您可以讓入侵者進入地下室。

問題是,即使在那兒也要入侵者嗎?入侵者一定會意識到,一段時間後他沒有得到想要的東西,並試圖從那兒走得更遠。而且您必須為準備好的酒窖保持額外的安全性。

因此,從某種意義上講,您只能增加自己的工作量來愚弄(無經驗的)攻擊者一段時間。

因為如果我做得很好,入侵者將不會(有一段時間)知道他在假房間裡,甚至無法確定他進入房間時是否在正確的房間裡。而且,在房間裡看還需要時間。,因此您不能只測試門是否有鑰匙,而是每次都必須在房間裡看,這將佔用更多時間來強行通過槽。
是的,我明白你的意思。我的觀點是:以良好的方式設置和保護假房間需要您的時間。您可以花更多的時間來首先保護“前門”。:)
無論如何,已經有必要對合法的經過身份驗證的用戶進行適當的訪問控制。我看不到假帳戶會有什麼額外的工作。
是的,但是保護整個訪問控制比保護登錄屏幕困難得多。這是必需的,但要實現完美的安全性幾乎是不可能的。通過這種方案,您可以使可能的攻擊者更接近系統。在大多數攻擊中,獲得對系統中ANY帳戶的訪問權限是獲得root特權的第一步。
這是最近一次特權升級的好例子:http://www.theregister.co.uk/2015/07/22/os_x_root_hole/
@gpinkas:讓某人越過前門是不好的。除了真實的前門之外,還有假的前門(所有這些都完全在真實的安全牆之外),這可能值得,也可能不值得,但不應影響安全性。我看到的主要有用方面是,如果假門的數量比真實門的數量大1,000:1左右,並且在受到破壞時觸發警報,那麼入侵者很可能會在獲得重要權限之前觸發警報。
bernz
2016-07-14 01:17:06 UTC
view on stackexchange narkive permalink

聽起來像您在談論加密環境中的“可否認加密”或“合理可否認性”形式;也就是,另一種機密,它解密為可信但非真實的明文。有關詳細信息,請參見 https://en.wikipedia.org/wiki/Deniable_encryption

但是嚴格來說,如果某人有能力對您的密文進行暴力破解,他們將有可能發現所有合理的明文,然後,基於他們對上下文已有的任何了解,他們將能夠確定哪個明文是真實的原始明文。第一部分可以通過偽AI來完成,但是第二部分仍然需要一個人。

使用一次性鍵盤,所有可能的消息都是同樣可能的,如果沒有原始密鑰,您將無法知道原始內容。例如,“週三下午3點見面”與“週二晚上9點見面”或“完成我的任務”同等可能-上下文並不總是有幫助
m.kin
2016-07-13 05:21:31 UTC
view on stackexchange narkive permalink

鍵的問題在於它們以數據而不是運行代碼的形式存在。即使使用CA和Crichton示例,也會發生帶外過程,該過程會為您進行每次解密嘗試提供合理的響應。從數學上講,這在密文和暴力破解的嘗試上是不可能的。

Dewi Morgan
2016-07-14 00:20:27 UTC
view on stackexchange narkive permalink

正如其他人所說,對於遠程訪問,可以進行簡單的鎖定和延遲。

對於密碼,您擁有的是單向哈希。要驗證密碼,請重新哈希它,然後比較兩個哈希。擁有多個簡單的密碼才能針對單個哈希產生有效的匹配被認為是不希望的:這意味著哈希很弱,並且具有“衝突”。

因此,您很可能對加密驅動器感興趣。 / p>

您所描述的-充滿偽造數據的偽造“外部”驅動器可以保護加密的“內部”驅動器-是可能的,並且已經在truecrypt中完成(可悲的是此後就死了)。 >

以下是我自己的天真理解,有些或全部可能是錯誤的。我從未使用過此功能,但認為它很有趣。

Truecrypt允許您指定第二個密碼,該密碼將解鎖加密驅動器的“層”(可能僅限於一個外部容器,我忘記)。這有明顯的問題;外部驅動器不知道內部驅動器,內部驅動器存儲在加密的外部驅動器的“空白空間”中。因此,外部驅動器的更改可能會破壞內部驅動器。此外,訪問加密驅動器時,內部驅動器上的日期戳不會自動更新。因此,具有您的計算機訪問權限的人可以知道您上次修改加密驅動器文件的時間,並且可以將這些日期戳與加密驅動器上的最後修改時間進行比較,並立即得知您最近使用它,因此

但是,主意是,您讓外部驅動器具有易於猜測的密碼(例如password123),在其中放置一些含糊的秘密內容,這會使您的對手認為他們已經進入您的加密驅動器。

少做些什麼-通過檢查解密驅動器上的“魔術字符串”(在任何實際驅動器上都是必需的),只是返回垃圾(等於無格式驅動器的隨機噪聲)的任何東西都可以輕鬆解決,但是

與加密文檔相同:大多數文件類型都有魔術字符串,因此,如果您知道包含哪種文件類型,則可以對所有已完成的加擾進行暴力查找以找到產生魔術字符串的所有方式。

,這並不意味著一個壞主意-如果密碼字符串是“ jfif”,則只有大約1600萬個密碼中的一個會生成該密碼字符串。但是,如果密鑰長度是2 ^ 1024,那麼他們只會將其減少到2 ^ 1000,這當然可以使破解速度提高1600萬倍,但從字面上來看,這將永遠是永恆的。

偶然的密碼輸入錯誤不會使人認為他們已經解密了該文件,但是僅僅尋找魔術字符串是不夠的。

您遺漏了一點:要解鎖“外部”驅動器,您應該鍵入*兩個*鍵。這樣,您可以進行更改而不會破壞內部驅動器。但是,當攻擊者[用扳手威脅您](https://xkcd.com/538/)時,您只需告訴他外鍵即可*成功*打開驅動器,而沒有證據表明存在內部驅動器,因此也無法保護內部驅動器。
@wildcard啊,好的。儘管可悲的是,“外部”驅動器上的時間戳可能仍會很清楚地表明您實際上只在內部活動,除非您不願意安裝和訪問兩者,可能是在內部使用了腳本來操縱外部。
Tom
2016-07-15 11:06:00 UTC
view on stackexchange narkive permalink

類似的事情實際上是在某些版本的RAR壓縮軟件中完成的(在早期,不確定是否仍然是這樣)。輸入的任何密碼都會解密加密的檔案,但是錯誤的密碼會導致輸出亂碼。這樣做是為了防止暴力破解密碼,這在當時對於ZIP存檔來說是可行的,該存檔立即返回“錯誤密碼”錯誤。

實際上,使用zip並非所有密碼都會導致“密碼錯誤”錯誤。大多數用戶都會遇到這種快速拒絕的情況(因此,用戶經常“錯誤地”輸入錯誤),但是如果強行使用密碼,則crc32上會出現很多誤報(基於1字節或2字節)-byte crc check),需要通過完全提取文件然後實現提取的crc32不匹配或-如果幸運的話,通過在要提取的文件開頭查看已知的純文本來進行驗證。
也許這是新的?我在談論20年前。
我說的是傳統的zip加密。那是20年前可用的
我想我確切地知道您的意思:我還記得還試圖找回大型檔案的密碼,然後WinRAR會先“提取”整個檔案,然後告訴我密碼錯誤。我認為,這應該與不恰當的[密鑰擴展](https://en.wikipedia.org/wiki/Key_stretching)方法普遍存在的時代聯繫在一起,WinRAR使用這種方法來減緩暴力攻擊。
這樣的方法使暴力破解效率直接取決於檔案的大小,這不是一件好事:小型檔案將受到較少的保護,向其添加無用的文件將增加安全性,這太hacky了。這裡提供了適當的密鑰擴展方法,這些方法可以使密碼檢查過程的時間保持不變,而與存檔大小無關:與較大的存檔相比,小型存檔的暴力破解保護級別相同,該級別僅取決於所選算法和參數,顯然更清潔,因此更安全。


該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到,我們感謝它分發的cc by-sa 3.0許可。
Loading...