題:
“敲密碼”是個好主意嗎?
gronostaj
2015-02-19 13:39:58 UTC
view on stackexchange narkive permalink

使用端口敲門,您必須按定義的順序“敲”特定端口,以暴露正在運行服務的端口。

密碼敲門如何?例如,您有三個密碼: A B C 。它們中的任何一個都不是正確的,但是按此順序一個一個地輸入,它們將授予您訪問權限。

一些方案可以使您的想法更清晰:

方案1。

  • 您:密碼 A
    • 服務器:密碼無效。
  • 您:密碼 B
    • 服務器:密碼無效。
  • 您:密碼 C
    • 服務器:接受密碼

方案2。

  • 您:密碼 A
    • 服務器:密碼無效。
  • 您:密碼 C
    • 服務器:密碼無效。
  • 您:密碼 B
    • 服務器:無效的密碼。

方案3。

  • 您:密碼 A
    • 服務器:無效密碼。
  • 您:密碼 B
    • 服務器:無效的密碼。
  • 您:密碼 B
    • 服務器:無效密碼。
  • 您:密碼: C
    • 服務器:密碼無效。

方案4。

  • 您:密碼 A
    • 服務器:無效密碼。
  • 您:密碼 A
    • 服務器:密碼無效。
  • 您:密碼 B
    • 服務器:密碼無效。
  • 您:密碼 C
    • 服務器:密碼接受

我想不出任何缺點這種方法比常規的單一密碼登錄更為有效。而且,每增加一個密碼,字典攻擊就成倍增加。

我意識到它的安全性是默默無聞的,並沒有消除對強密碼的需求。密碼序列本身與使用的密碼串聯一樣強大。這種方法增加的安全性來自意外複雜的過程。

這是個好主意嗎?比經典密碼更好嗎?

從用戶的角度來看,這非常令人沮喪。如果說您拼錯了其中一個密碼。很難知道哪個地方出了錯A,​​B或C。
這種方法會使傳統密碼無法掩蓋什麼?為什麼您認為它更安全?在我看來,這比沒有一個密碼(由A,B和C串聯而成)更安全。同時,我不明白為什麼它的安全性會降低。
-1
評論不用於擴展交流。
@RoryAlsop我是StackOverflow的常規用戶,但對該網站不熟悉。您的回答讓我感到困惑,不知道它適用於所有SE網站還是僅適用於此網站。據我所見,您的評論恰好跟在我看來是熱門話題並有助於討論的3條評論。這似乎與SO預期的不同。我想念什麼嗎? (注意:根本不是一個諷刺的問題。)
@mbm29414我也很困惑,並且是SA的普通用戶。我能想到的最好的辦法是刪除了一些評論,Rory Alsop留下了評論,說明原因。至於相對於傳統密碼而言這是否是一個好主意,則可能取決於您的“敲門”系統。是累積直到通過,還是每次都重置?基本上,它不會讓您進入,直到您依次擁有A,B和C,而A,B,B,C才起作用。我不確定如何實現,但是如果要執行此操作,那似乎是最安全的方法。
@gronostaj不應依賴[通過模糊性提供安全性](https://en.wikipedia.org/wiki/Security_through_obscurity)
如果您的目的是防止字典攻擊,那麼密碼策略有什麼問題-http://security.stackexchange.com/questions/3248/recommended-policy-on-password-complexity此外,如果您已經*具有*適當的密碼策略,抵製字典攻擊(這是策略的重點),然後為什麼需要添加這種額外的模糊“敲門”程序。
隨著@tar的發展,您不應依靠默默無聞來依靠安全性。順便說一下,它不會被很多人所迷惑。您的用戶將如何知道繼續插入密碼?因為你告訴他們。畢竟,這似乎並不是一個非常困難的信息! :)
普通密碼只是“敲字符”。您必須按正確的順序放置一些字符...
mbm-許多評論被刪除。
如果您要尋求增強的安全性,最好使用兩步身份驗證方法,例如將授權碼發送到用戶的移動設備或電子郵件地址。
可能是[Port Knocking這是一個好主意嗎?](https://security.stackexchange.com/questions/1194/port-knocking-is-it-a-good-idea)
十七 答案:
Mark
2015-02-20 06:41:23 UTC
view on stackexchange narkive permalink

問題中概述的系統實際上是更弱,而不是僅僅要求一個長度為A + B + C的密碼,因為它允許一類攻擊,不能針對單個密碼進行攻擊:

說您的三個密碼組合為 EFG 。攻擊者可以發送密碼 ABCDEFG ,進行五次攻擊( ABC BCD CDE DEF EFG ),價格為兩個。通用術語是 de Bruijn序列,它使您能夠以比可能的組合少得多的嘗試來攻擊任何基於狀態的系統(例如數字鎖)。

+1,沒有其他答案強調此方案比相同(總)長度的普通密碼要弱。
OP的方案沒有定義上的安全漏洞,因為他們沒有提到實現,儘管我敢打賭大多數人會忽略這一點。 +1表示注意。但是,如果實現該方法以每三個密碼(所以password1,password2,password3,evaluate,clear,repeate)重置最後三個密碼的變量,則它可能會更安全(從晦澀的角度來看)。
該帖子提到`A A B C`起作用,這意味著它具有“最後三個密碼”的滾動窗口,而不是在三個一組之後重置。這足以使其容易遭受基於序列的猜測。
我不同意該計劃較弱。 De Bruijn序列的速度提高了3倍,但是在密碼中添加兩個拆分將使我們的速度下降(|| A + B + C |超過2)。 (其中6個字符的密碼為28)
tylerl
2015-02-19 14:31:24 UTC
view on stackexchange narkive permalink

從原始安全性的角度來看,您的密碼只是“ A B C”,並且相應地計算了密碼的相對強度。

從用戶的角度來看,這可能很難使用。服務器沒有提供有關當前狀態的任何指示(是否正在尋找第二個密碼?),因此用戶無法告知要提供哪個密碼。

從防禦的角度來看,存在這裡價值不大。密碼攻擊的執行變得更加複雜,並且必須重新編寫現有的攻擊工具才能適應這種怪異的方案。這也許足以說服攻擊者繼續前進,但是如果您是重要目標,那麼它將完全無濟於事。

我同意。安全性必須與可用性保持平衡。您的想法可能會使合法用戶(您想要保護的人)感到沮喪,因為這會使他們更難以訪問密碼背後的服務。
還請注意,如果服務器確實給出了“到目前為止”​​的中間狀態,則密碼實際上比僅“ A B C”要弱。這不是WPS發生的事情,還是其他協議?
“從原始的安全角度來看,您的密碼只是“ A B C””->我非常不同意。由於您不知道哪個失敗,如果失敗了,則可能需要10十億字節才能存儲第一個密碼。而且您將無法找到它。如果將其限制為30個字符,則密碼長度可能為31個字符。而且您浪費了時間。或者一個可能是10,下一個是50,下一個是1。但是您不會知道。
@kutschkem完全正確。
@IsmaelMiguel與嘗試猜測單個密碼“ ABC”並且不知道密碼中的每個字符有誤,或者所有密碼是否有誤,都完全相同。沒錯
@IsmaelMiguel否,攻擊者將嘗試[[A],“ A”,“ A”],[“ A”,“ A”,“ B”]等,直到到達[“ A”,“ B” “,“C”]。在繼續進行第二個領域之前,他不必在第一個領域上嘗試所有組合。如果我告訴您我的密碼中有三個空格,那麼您將不會感到困惑,因為它很難弄清楚第一個空格之前的內容。您只需先嘗試最短的可能性。
是的,但是你不知道。密碼“ A”很有可能是“釘玉米炸土豆”,這會使您花很長時間才能猜到。
-1
實際上,它相當於A +“ [ENTER] + B +” [ENTER]“ + C之類的東西,因為僅在第一個提示中鍵入ABC大概是行不通的。可能的猜測數目將與ABC *相同(LengthOfABC-1)*(LengthOfABC-2),如果該方案在任何步驟均禁止零長度密碼。
不過,您在A前面還有幾個字符(如果我沒記錯的話,是65個字符)。任何這些都可能是密碼的一部分。
@IsmaelMiguel您可能會繼續不同意您所喜歡的一切,但是由於社區成員試圖通過*幾種*不同的方法向您解釋,因此所提議的方案的強度實際上與串聯各個密碼沒有區別。
我接受@StephenTouset。在我看來,從另一個角度來看,這比連接密碼並嘗試僅找到一個密碼要強。實際上,我要說的是,幾乎不可能找到這三個密碼,具體取決於它們的安全性。
但這在數學上恰好等同於將這三個密碼串聯在一起。如果您的“第一”密碼是“ 123”,第二個密碼是“ 456”,而“第三”密碼是“ 789”,則攻擊者必須花費與嘗試猜測“ *”相同的努力。密碼“ 123456789”。關於他們可能不知道這是您的方案的論點,密碼本身就是對的。攻擊者不知道這是一個九個字符的密碼(或者等效地,三個三個字符的密碼)。他們必須嘗試所有組合,直到找到正確的組合。
更清楚地說,如果您考慮輸入此密碼,則您的有效密碼是* literally *`123 456 789`。您可能會爭辯說,攻擊者不知道在這些精確位置處按Enter鍵,但可以為可以在此處鍵入的*任何*字符進行論證。這與您的密碼改為“ 123 | 456 | 789”沒什麼不同。問問自己,當考慮坐在鍵盤上並輸入此密碼的字面行為時,在某種程度上授予Enter鍵比`|`鍵更高的安全性。
@StephenTouset我部分同意您的觀點,理論上,“ 123 456 789”等同於“ 123 | 456 | 789”,但實際上第一個模式需要3個對服務器的請求,而第二個模式僅需要3個請求,即使一切都非常快,第一個選項也會花費更多時間,因此它增加了一些額外的安全性(當然我也不會使用它)
諸如“ bcrypt”之類的方法是使攻擊者減速的好方法,因為即使攻擊者擁有您的哈希密碼,該方法也有幫助。無論如何,可以通過調用“ sleep”來簡單地模擬兩個額外請求到服務器的等待時間。
@StephenTouset我也說過,這不是一個好方法,只是說您不能將請求/驗證步驟與密碼上的字符進行比較,而且“睡眠”會嗎?
Justin
2015-02-19 14:55:49 UTC
view on stackexchange narkive permalink

我要在這裡解決幾點。

首先,假設攻擊者不知道密碼方案是 bad 假設,而您通過掩蓋錯誤糾正它的安全性。如果每個用戶都可以學習此登錄方案,那麼攻擊者也可以。因此,敲擊不會比僅使用一個密碼 ABC 更好。

您可能會認為,“沒有更多密碼會增加暴力破解次數呈指數猜測?”答案是不。考慮一個長度為 z 的字母,以及三個長度為 a b c 的密碼。每個密碼的可能數量分別為 z a sup> z b sup> z c sup> 。如果要按每種可能的順序嘗試每個密碼的所有可能值,則需要 z a sup> * z b sup> * z c sup> 猜測,這等於 z (a + b + c) sup> 。碰巧單個密碼 ABC 的長度為 a + b + c ,因此數字的猜測也是 z (a + b + c) sup>

還有一些設計上的擔憂,即用戶會感到困惑和/或沮喪該系統,特別是如果他們在記住密碼時遇到麻煩時。人們在記住每個訪問的站點的一個密碼時遇到了很多麻煩(這就是為什麼許多人重複使用密碼的原因)。 三個密碼更加難以記住,如果您的某些用戶對三個三個都使用相同的字符串,我也不會感到驚訝。

需要三個表單提交才能登錄當然可以減慢暴力攻擊的速度,但是您可以通過在服務器端密碼驗證中添加延遲來輕鬆實現這一目標。

同意您的其他觀點,不同之處在於,如果攻擊者不知道該方案,則更有可能使用蠻力錯過序列。
普通的字典攻擊很可能永遠不會進入A BC。原因是,如果一次嘗試A或B或C都沒有成功,就永遠不會再次嘗試!
沒關係,對於攻擊者不知道該方案的情況,我是錯的。我刪除了那句話。
我同意您的更新,但是我非常確定,由於復雜性,您需要從“!”開始到“〜”(ASCII字符)到至少找到一種可能的組合。密碼失敗將恢復為密碼“ A”。而且您將失敗的頻率太高,並且您將無法確切知道哪個失敗。對於每個字符,您都必須輸入“!”到十億次每個密碼加倍。您有3個入口點,每個入口點可能不同,如果其中一個失敗,它將恢復。您或者知道密碼,否則將永遠被鎖定。直到過去了4萬億年(或更多)。
我不想做數學來確切地算出要嘗試多少次或需要多少時間,我不能,因為我實際上沒有數字可玩,而且也沒有關係。我希望通過本練習來說服您,它並不像您想的那麼難:在_ABC_的所有可能值中,有多少個以_A_作為前綴正確的值?
你不必說服我。我一直在努力尋找捷徑,但我能發現的只是一個嚴重的頭痛。我認為您在打正確的樹。我不會不同意您的意見,因為沒有什麼不同意之處,只是很難猜測密碼。
您可以將其視為密碼子字符串來自長度為`z`的字母,而“級聯”密碼來自該字母的超集,特別是整個字母加一個定界符(表示發送子字符串)。
@corsiKa:加上附加的約束條件,即“級聯”密碼必須恰好具有兩個定界符實例,再加上“每個子密碼必須包含至少一個特殊字符”的約束。 。 。最終結果可能是,實際上您得到的密碼可能比更少的長密碼少*少*。
Mike Scott
2015-02-19 14:02:30 UTC
view on stackexchange narkive permalink

通過隱秘獲得安全性-如果被廣泛採用,攻擊者將嘗試3次。此時,您最好只有一個密碼,但設置一個更長的最小密碼長度,以確保它與三個單獨的密碼串聯在一起一樣長。

即使OP聲明+1,但我還是默默無聞地意識到了安全性。值得補充的是,這是通過隱蔽性實現的“僅_安全性”,與其他方法相比沒有任何好處。您可以交換用戶名和密碼字段並保持標籤不變,或者將密碼字段重命名為“生日”,有上百萬個選項會使用戶以“安全性”的名稱感到困惑。顯然,OP在理解這種模糊的安全性的同時,也不理解為什麼這樣做很糟糕。
至於_為什麼_這是不好的。如果我被迫使用這樣的系統,那麼我要做的第一件事就是編寫一個密碼輸入腳本來自動消除煩人的界面。然後,我可能會將腳本檢入到我的公共github存儲庫中。
Stephen Touset
2015-02-19 14:09:41 UTC
view on stackexchange narkive permalink

這與您的密碼只是 A ||沒什麼區別。 B || C

如果攻擊者不知道我使用的是“三重密碼”,他將只嘗試一次每個密碼,並且很可能永遠找不到正確的順序。 `A ||並非如此。 B || C`。
如果攻擊者不知道您的密碼是`A || B || C`,他/她將不得不嘗試一次每個可能的密碼,並且極有可能永遠找不到正確的順序。是的,確實如此。如果攻擊者擁有“ A”,“ B”和“ C”,則無論如何您都會迷路。
@Stephen您的答案對那些尚不知道的人不是很清楚,請您詳細說明一下以使其成為一個正確的答案?
即使攻擊者知道該方案,他也必須嘗試每種可能的密碼3次。如果密碼“ A”是“ 123”,密碼“ B”是“ 123”,密碼“ C”是“ 1234”,則要嘗試輸入密碼“ 0 | 0 | 0”,“ 0”即可。 0 | 1`,`0 | 0 | 2`。由於服務器不會告訴哪一個是錯誤的,這使情況變得更糟!密碼可能是“ 0 | 1 | 0”,您將花費大量的時間來查找它。
@IsmaelMiguel您聲稱要惡化的部分與使用更長的字符串相同。示例:假設A,B,C可以分別是一個0-9的數字。那麼A,B,C就有1000種可能性。與3位數密碼相同。
@Jean-BernardPellerin還添加了分隔符。它是A B C 。因此嚴格來說,在序列中註入2個分隔符。串聯不模擬A的* end *和B的* start *等。
@AviD我覺得這個結果肯定很明顯。您的密碼現在是*字面意義上的* A <提交> B <提交> C現在,只需使用Return鍵將它們串聯起來。
@StephenTouset我不同意,但是事實並非如此……事實證明,FWIW我已經為您+1了……:-)
如果我有密碼3個密碼“ AB”,“ BC”,“ CD”,則串聯的密碼為ABBCCD。證明這是不相等的,因此此答案不正確。例如,在此方案中,“ A”然後“ BBCC”然後“ D”是不同的錯誤密碼,但是連接是相同的。分隔符是使等效性錯誤的關鍵區別。
不是,因為那個A \ n || B \ n || C \ n實際上可與A ||區分開B || C
Arc
2015-02-20 04:34:50 UTC
view on stackexchange narkive permalink

雙重身份驗證更加用戶友好,但更加安全。

不包含,一個密碼仍然比敲門安全性低。

能夠找到密碼的攻擊者也可能會發現敲門方案。

選擇敲門就像選擇算法。考慮它為公開

儘管密碼是出於安全性,但是可以很容易地用完全不同的密碼替換它們。

也就是說,有些 方案與您的“敲門”有些相似,但更有用:

  • 隨機從多個秘密(密碼,詞組, iTAN...)中請求一個
    這比輸入要快得多所有秘密,並且更加安全,因為攻擊者一次只能知道一個秘密(使用後可以失效)。
    攻擊者能夠進行身份驗證與他們知道的相對數量相關。仍然,這要求用戶知道所有秘密及其 order
  • 輸入時間,即分析所有密碼之間的時間以及所有密碼的時間用戶輸入 字符。
    與敲門相比,這更難發現和偽造,並且IIRC已進行了多次研究。缺點:

    • 變化進行計時每次略有不同,儘管用戶可能仍然可以區分出用戶
    • 當用戶選擇以其他方式輸入時,甚至可能完全改變時間。在選擇密碼後的初始階段(用戶仍在學習輸入密碼)期間,或者當他們無法以通常的方式輸入密碼時(受傷,一隻手三明治...)

如果您可以快速修改 obscurity方案(即“ ,而不是迷宮。

杜德(Dude),對粗體的過度使用幾乎使這難以理解。
我不會說密碼是默默無聞的安全性。每個安全系統都需要獲得進入所需的“東西”,無論是您知道,擁有或擁有的東西。為了通過模糊性將某些東西歸類為安全性,您需要查看算法,而不是“密鑰”。
我沒有定義這些詞。摘自[Wiktionary](https://en.wiktionary.org/wiki/obscurity):2. _未知狀態; _ 3. _難以理解的質量; _後者是人們在談到“默默無聞的安全性”時通常貶義地指的,但是任何難以“把握”的事物都可以被認為是晦澀的。
fooot
2015-02-19 21:39:39 UTC
view on stackexchange narkive permalink

敲門的概念實際上並不直接適用於登錄網站。至少不是您所建議的那樣。使用端口斷開功能,您可以按特定順序連接到其他端口,以打開所需的端口。在您的示例中,您將所有密碼都放在一個站點中。正如其他人指出的那樣,這與將所有密碼放在一起並沒有什麼不同。除非您使用的所有密碼都非常長,否則最好將它們連接起來並使用一個密碼。這種方法的晦澀之處也不是那麼有用,因為有人必須構建它,而別人必須知道如何使用它,這足以使攻擊者了解它的工作方式。另外,您只是向世界解釋了它。

相反,也許您可以使用不同的網站來表示不同的端口。假設您正在嘗試登錄網站D。當您連接到網站D時,它甚至不會顯示頁面,除非它可以看到您正確且以該順序登錄了網站A,B和C。這樣,攻擊者不僅必須破解不同的密碼,而且還必須在3個不同的站點上完成這些密碼,並以正確的順序使用它甚至訪問需要另一個密碼的站點D。

這仍然取決於一定程度的模糊性,但是與僅在一個站點上拆分密碼相比,它更具區別性。

+1解決了問題的核心:擬議的密碼敲除方案*不會*複製用於端口敲除的方案,因此推定的利益不會轉移。
PiTheNumber
2015-02-19 18:12:47 UTC
view on stackexchange narkive permalink

正面

  • 它將欺騙標準的蠻力攻擊。殭屍網絡或簡單工具發出的自動攻擊無法立即使用。
  • 以這種方式欺騙鍵盤記錄程序是可能的。在日誌中,用戶好像記得第三次嘗試的密碼。如果攻擊者使用此密碼,它將無法使用。但前提是他不知道或不知道發生了什麼。但是在這種情況下,他還是會擁有您。
  • 用戶被迫使用多個單詞=>更長的密碼。

否定

  • 對於普通用戶而言太複雜了。
  • 像端口敲門一樣,部分原因是由於晦澀難懂。如果攻擊者知道他可以調整攻擊。主要好處是可以使用更長的密碼,而密碼規則可以更輕鬆地實施。

    無論如何,如果您的用戶不介意,則可以這樣做。最後,每個安全功能都很重要。但是我不建議這樣做。

好吧,無論如何,愚蠢的暴力攻擊毫無意義。給定合理的登錄速率限制(例如每秒1個),蠻力是徒勞的。另一方面,將不會阻止對被盜數據庫的脫機攻擊,因為很明顯,必須使用三個密碼以及它們的哈希值,因此區別可以忽略不計。
Ogre Psalm33
2015-02-19 22:26:42 UTC
view on stackexchange narkive permalink

僅需注意:該方法已在某些行業的密碼恢復方案中使用。如果忘記密碼,則可以使用您的電子郵件地址發起一系列個人問題以恢復密碼(儘管很多時候這只是一個問題)。通常,將上下文限制為一系列精心選擇的問題,使用戶有機會使用(希望)機密但眾所周知的答案,從而使其對用戶更可口。

如果更好的銀行無法識別您正在從中登錄的計算機(與上述密碼恢復方案相同),還會提供另外一組安全問題。

例如:

 輸入密碼:*****您的計算機未被識別,請回答以下其他問題:您的母親長大在哪個城市? *********你最喜歡的電影是什麼? *************  

這可以使精明的用戶對他們選擇的一系列問題提供相當模糊的答案,同時仍然可以輕鬆地記住“密碼”的順序。當然,典型的用戶可能仍然會對“無法識別的計算機”問題使用易於猜測的答案,但是無論如何,用戶總是有責任提供良好的密碼。

enter image description here >

當然,添加安全性問題(實質上是密碼,而密碼的目的是讓用戶容易猜到),這只會使您的整個系統比僅使用一個密碼的情況弱。 (假設一個典型的用戶遵循用戶界面中的指示,並且不會選擇隨機答案。)負擔由用戶和設計人員共同承擔–如果您的系統僅使用良好的備用密碼來保證安全,至少應指示用戶選擇一個!
任何仍將安全性問題用作唯一備份的銀行可能比其他銀行“更好”,但是從安全角度而言,這是可怕的。我的經歷給我留下了深刻的印象,它逐漸使每個人過渡到需要身份驗證器和語音指紋以支持電話的功能。
多因素身份驗證絕對是一個更好的選擇,但是可悲的是,大多數銀行還不存在,至少就我所採樣的而言。但是,即使我的妻子(絕對不是技術人員)也足夠(甚至沒有告訴我)告訴她,當她選擇安全問題“最喜歡的寵物?”時,她應該*不要*將我們的狗菲多作為答案(她使用了另一個很難猜出的,與寵物無關的答案,她很容易記住)。許多人比我們認為的要聰明,但不幸的是,我必須承認,許多人沒有。
我還必須指出,可以這麼說,“備份密碼”之間有細微的差別。它們的目的是使答案易於由*特定*的用戶猜出,但很難被其他人猜到(可悲的是,並非所有人都以這種方式實現答案:“最喜歡的顏色?” *真的嗎?*)
我個人討厭這種系統,首先,我永遠不記得我選擇了什麼問題。除非我寫下來,否則選擇它們總是一樣。最後,我放置了隨機數據,這只會增加攻擊向量。
@OgrePsalm33好吧,一旦您對設計進行了調整以使其更加安全,那麼您實際上並不是在談論正確的安全問題。 (即一種主動提示可能通過查看其Facebook頁面找到的信息的方式。)我的觀點是,安全功能的設計不應使用戶不得不執行與所告知的相反的操作。 (例如,您的妻子。)到目前為止,我個人最喜歡的是OS X密碼提示,在該密碼提示中,我在密碼短語中使用了這些單詞的同義詞,足以引起我的記憶;但是,這可能不適用於銀行
Dewi Morgan
2015-02-21 10:33:20 UTC
view on stackexchange narkive permalink

PROS :此系統具有的雙重身份驗證功能。

1)大多數瀏覽器和密碼保存系統均不支持該功能。 ,因此最多只能記住一個密碼。因此,至少它不會以純文本格式存儲在某個地方。

2)在任何地方使用相同密碼的人都必須至少使用兩個與其他站點不共享的密碼。

CONS :但是,該系統總體存在缺陷,我認為它比單口令身份驗證更糟糕。

1)因為首選,並且受密碼保護他們用於更重要的密碼的密碼存儲系統無法使用,很可能他們將對此密碼使用的東西少一些。便利貼,文本文件等等。

2)其他人聲稱它的強度與密碼“ ABC”一樣強。它不是。我會說,在最壞的情況下,它的強度僅與密碼“ A”一樣。

這是因為我(和典型的用戶)會使用密碼“ password1”,“ password2”, “ password3”此密碼生成系統為我帶來的好處是,我可以ctrl-c,ctrl-v密碼,然後鍵入數字。

如果我不能使用類似的密碼,則可以減小範圍我可以擁有的可能的密碼:現在,您的安全性不再像ABC一樣安全,而僅具有與ABD相同的安全性,其中A!= B!= C:通過減少其搜索域,您使破解者的工作更加輕鬆。

並且我仍然會選擇密碼輸入腳本允許的任何可預測序列:“ Jan”,“ Feb”,“ Mar”。

並且由於我將使用自然序列,這很可能是密碼破​​解者在字典中的順序,因此密碼破解機自然會以正確的順序嘗試這些密碼並直接進入。任何破解者了解您的系統絕對會以這種方式訂購字典。

3)降低安全性的另一個因素是要更改密碼,現在需要更改三個不同的字段。這樣會阻止許多人更改密碼。

4)就像其他人指出的那樣,這是糟糕的,糟糕的用戶體驗。除非您有一定的受眾群體(員工,學生等),否則您將通過這種對用戶不利的方式失去風俗。

fluffy
2015-02-20 03:29:05 UTC
view on stackexchange narkive permalink

正如其他人所說,這等同於僅擁有一個等於 A \ nB \ nC 之類的密碼。但是,我可以想到此方案的一個優點:它有助於減少網絡釣魚類型的內容;如果系統接受第一個密碼而不是其他密碼,那麼您就知道該系統已受到威脅,只需記錄您的用戶名和密碼即可。

但是,在這種情況下,最好嘗試使用一個嘗試使用您的實際密碼登錄之前輸入隨機密碼;否則,由於現在第一個(大約)三分之一已被受感染的系統記錄下來,因此您剛剛破壞了很大一部分密碼。

Peter
2015-02-19 16:34:13 UTC
view on stackexchange narkive permalink

我不認為有人說過這甚至是默默無聞的事-三個密碼登錄名是公開顯示的,不是嗎?當然,需要一些工作來調整一些工具,但沒有什麼困難。

對於暴力複雜性。可能性的數量與擁有一個長度為 A + B + C 的單個密碼相同。因此,由於這個原因,您使用此方案的唯一防禦措施首先會使攻擊者感到沮喪。此外,如果該方案變得普遍,那麼標準工具將很快適應。

3密碼登錄不會公開顯示。它看起來像一個標準的用戶名,密碼登錄。除了憑證{userid,password}以外,您還有憑證{userid1,password1,userid2,password2,...}。您輸入userid1,password1,系統“拒絕”您,但秘密記錄您已通過障礙1。您輸入userid2,password2,系統“拒絕”您,但秘密記錄您已通過障礙2。當您通過最後一個障礙時,系統讓您進入。話雖如此,但我並不熱心。
@emory,可以肯定,但是我的意思是系統的用戶清楚地知道該方案,因此攻擊者也是如此。
如果用戶群很小(例如,只有我一個人),那麼密碼敲入會很模糊,但仍然不建議這樣做。如果用戶群很大,那麼密碼敲門是可怕的。我隱式地認為用戶群很小。
Cort Ammon
2015-02-20 01:06:05 UTC
view on stackexchange narkive permalink

正如許多人提到的那樣,出於專門的攻擊目的,它沒有比串聯多個密碼更強,更容易/更難記住的了。但是,有一些操作安全性(OPSEC)值與密碼強度無關。請注意,價值不高,但是作為一個在 Worldbuilding StackExchange網站上花費大量時間的人,我的想像力撲朔迷離。

考慮一下您是否想要一項服務僅限於授權用戶,但您要防止某人意外絆倒其存在。這不再是一個簡單的熵問題,而是一個間諜對間諜信息理論問題。現在,您的工作就是最小化瀏覽密碼輸入的任何人的信噪比(SNR)。現在,這與密碼強度無關。

一種方法是設置虛擬行為。使其看起來像是用於其他系統的登錄。只有具有正確特權的帳戶才被重定向到有意義的內容。您甚至可以讓其他人註冊您的虛擬項目,以使人們四處尋覓並滿足他們的好奇心。

但是,我們現在正在談論spy-vs-spy。有人會意識到,詹姆斯·邦德(James Bond)確實不是對討論橡膠鴨子最新趨勢的論壇感興趣,並開始撬開。詹姆斯·邦德擅長不透露信息,但在某個時候,他的女友頭部被槍支握住,如果他不向NoGood醫生透露自己的橡膠搖號論壇密碼,那將是可疑的。 NoGood博士不是傻瓜。他會解決的。

因此,我們為James設置了兩個密碼。一個讓他進入普通的橡皮鴨論壇,另一個讓他進入最高機密的核導彈模擬器。在這裡,我們不能忽略現實中的密碼安全性。他的核導彈模擬器密碼將必須很長:只要將三個密碼串聯即可。他的密碼太短了。也是一件好事,因為之前有人看過他登錄了他的帳戶。他們知道有多少個字符開始暴力破解。我們不希望他們在找到小鴨之前就意外找到了安全密碼。蠻力不斷。另外,當詹姆斯“兩次錯誤輸入密碼”之前,他旁邊的牆突然小溪露出來,可以揭示一個巨大的變化。

僅供參考,較晚的Truecrypt系統允許您創建隱藏分區,其中一個密碼解密驅動器以生成您實際上並不在乎的重要外觀文件,而第二個密碼解密真正需要保留的數據的隱藏分區秘密。這樣做是為了使您具有合理的可否認性。
Vynce
2015-02-20 03:58:12 UTC
view on stackexchange narkive permalink

“活動部件越少,出問題的機會就越少。”

除了沒有提供任何顯著的好處之外,這種想法的實現比單個密碼更複雜。因此,存在更多潛在故障點。例如...

根據實施方式的不同,它可能允許拒絕攻擊,其中Malcolm會定期發送密碼X。如果他設定正確的時間以致打斷合法嘗試,則係統會收到A X B C並拒絕您輸入。同樣,如果他在您發送A B之後立即發送密碼C,則係統允許他進入,而不是您進入。

響應定時攻擊可能能夠找出A是A B C中正確的第一個密碼,而不會注意到D是單密碼DEF的前綴。

PressingOnAlways
2015-02-21 04:08:42 UTC
view on stackexchange narkive permalink

要添加所有其他出色的答案,這種類型的密碼保護方案將不會對鍵盤記錄程序或中間人攻擊提供任何保護。由於您仍然需要按順序輸入密碼,因此鍵盤記錄程序可以重播您的操作並仍然獲得授權。 @Archimedix建議的兩要素身份驗證將是減輕這種情況的最有效方法。

鍵盤記錄器會因為提交密碼而感到困惑。鍵盤記錄程序將必須了解該方案,以免被其欺騙。因此,只要保持“遮蓋力”,它就會起作用。
請注意,一個鍵盤記錄器會一遍又一遍地報告相同的三組提交的密碼,這將有助於消除晦澀之處。
Kinjal Dixit
2015-02-25 16:12:53 UTC
view on stackexchange narkive permalink

正如其他人所述,從功能上講,這與一個長密碼相同。為了減少實現的混亂度,可以通過在同一屏幕中詢問所有三個密碼來實現。

這些事情是由我的在線經紀完成的,該經紀人在登錄時要求輸入會員密碼和交易密碼。我們必須正確輸入兩個密碼才能登錄。此外,我必須每10天左右更改一次會員密碼,並且有關於不重複使用前三個密碼的規則,等等。

我以前使用的銀行( ICICI銀行)有兩個密碼,一個用於查看登錄和訪問信息的密碼,另一個用於在執行任何會導致金融交易的操作時進行交易的密碼。我的Visa Visa借記卡也由稱為 3-D Secure的系統保護,在該系統中,無論付款網關如何,他們都會帶我到自己的站點輸入密碼以完成交易。我知道這是真正的Visa網站,因為他們讓我自定義了要顯示的消息。

所以這個想法並不是前所未有的,儘管它的實現方式與您所說的完全不同。至少銀行家和股票經紀人似乎相信添加多個密碼。

“多個密碼”與“多個密碼只有在正確輸入所有密碼後才能確認正確性”是不同的。它甚至更弱,因為攻擊者可以一次追隨它們-強度與最長的單個密碼的強度大致相同(請參閱:WPS)。
F. Hauri
2015-02-28 02:00:34 UTC
view on stackexchange narkive permalink

停止無用的技術複雜性

根據先前的正確答案,

  A \ nB \ nC  

大約等於與

  ABC  

相同(或更輕,關於 @Mark的答案,關於布呂恩序列)。

如果真的需要保守秘密,就從那裡開始:

  1. 使用經過一段時間測試的標準工具。 (如果不確定,最好分享和詢問,而不是使用任何晦澀的方式。)

  2. 讓他們保持最新狀態。

  3. 教您的用戶有關密碼短語的信息(請參閱 xkcd:密碼強度有關IS的討論

  4. 請記住,社會工程學(在Wikipedia上)第一個安全漏洞的方法。 (另一個著名的 xkcd:安全性)。

  5. 監視系統並檢查日誌。

  6. ol>


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