題:
僅要求輸入密碼的單個字符是否是錯誤的做法?
Enno Shioji
2014-08-03 22:21:05 UTC
view on stackexchange narkive permalink

我使用的某些金融網站以特殊方式使用密碼。他們沒有要求我輸入整個密碼字符串,而是要求我輸入例如。 “密碼的第3、5和8個字符”,即密碼字符串的字符的隨機組合。

我認為,如果使用共享隨機數表等完成操作,這將是有意義的。但這是密碼。為此,他們必須存儲我的密碼而不進行散列,或者存儲他們要詢問的所有組合的哈希,這聽起來也很糟糕。我是否認為這是一種錯誤的安全做法,對嗎?

有時。如果他們正在檢查硬件安全模塊,那可能會很好。
我同意,表面上或僅看標題,這兩個問題都是虛假的。但是,從完整的問題來看,這個問題更多的是在問銀行為什麼要使用這種做法,而另一個問題是在問這種做法是否安全,如果可以,為什麼。這個問題還詢問它是否安全,但這不是主要目的。
我回想起使用電話銀行服務的方法,該服務採用類似的方法-在身份識別過程中,一個活生生的人只是從我的“秘密單詞”中索要一些字母。有道理的是,不會告訴操作員整個密碼(25年前……很早以前按鍵式電話在世界各地普及了)。對於一個網站沒有意義。
@trysis我認為它仍然是重複的。但是我們已經有兩次確切的問題了(特定於銀行)。 [此處](http://security.stackexchange.com/questions/10938/is-my-bank-storing-my-password-in-plain-text)和[此處](http://security.stackexchange.com / questions / 4830 /如何做一些網站,例如在線銀行,僅從PA詢問特定字符)。哦,還有[這裡](http://security.stackexchange.com/questions/52972/how-does-my-bank-knows-my-second-and-forth-chars-of-my-password)
這是[另一個](http://security.stackexchange.com/questions/38744/taking-password-letters-not-whole-one-is-this-secure)。使用網站搜索或google:`site:security.stackexchange.com銀行密碼可以輕鬆找到所有內容。
二 答案:
Thomas Pornin
2014-08-03 22:40:34 UTC
view on stackexchange narkive permalink

您基本上是對的;這是一種不好的做法,原因有幾個:

  • 您注意到,它需要在服務器端以純文本或某種可逆格式存儲密碼。
  • 鍵入密碼反复在“ 肌肉記憶”上工作,該操作使用戶可以“記住”密碼,以鍵盤上的一系列手勢表示;要求輸入特定的字母會鍛煉大腦的各個部位,並且可能會引起危險的行為,例如寫下密碼。
  • 如果該站點只要求輸入三個字符,則攻擊者只需回答三個隨機字母,就有機會獲得訪問權限。 在線詞典攻擊也可以起作用。 (當然,銀行網站通常將其與觸發滿意的鎖定係統結合使用,但是聰明的攻擊者會在達到自動鎖定限制之前切換到另一個目標帳戶。)

三個主要原因銀行網站為什麼這樣做:

  1. 如果他們只要求三個字母,但並不總是相同,那麼按鍵記錄器或肩膀衝浪者將無法立即 他非法獲得的知識。可以將其視為某種形式的損害控制措施,其中密碼僅部分洩露。

  2. 僅要求提供一些字母是好萊塢認可的安全措施。它使表演很棒。客戶不知道真正的信息安全是什麼,他們會看到並認為“哇,那是安全的!”。 。不少“安全架構師”會看到這樣的系統和的思考“哇,這是安全的!”

  3. OL>
這個答案通常是有效的,還是專門針對以下情況:所描述的對密碼中某些字母的檢查是“僅”保護級別?我之所以這樣問是因為,我知道一個銀行站點需要一個傳統密碼(大概以不可逆的形式存儲),並且每次登錄時都需要另一個密碼的某些字母。
抱歉,但是,如果您有許多不同的密碼(如應有的話)並定期更改(如應有的話),則很難看到肌肉記憶如何在記憶中發揮重要作用...
定期更改密碼不是一個好主意。這是一種普遍的做法,對安全性是有害的,正因為這與用戶記住密碼的能力不一致。
關於poor_practice要點1,如果他們已經對字符組合進行哈希處理並且不必進行純文本匹配怎麼辦?儘管count = 3太小,並且很容易受到實踐點3的影響。
@ThomasPornin已經給出了很好的答案。只是想補充一下這是一個可怕主意的另一個原因:您現在能很快記起密碼的第3、9和11個字符嗎?您需要以純文本格式查看密碼!這項特定政策只會使人們更有可能記下密碼和/或將密碼保存在純文本中(例如gmail,硬盤中的純文本文件,Post It等)。然後,它們可能會丟失,放錯位置或容易被盜。
似乎Thomas Pornin已經給出了這個原因。他說,在回答中,“索要特定的字母會鍛煉大腦的不同部位,並可能引起危險的行為,即寫下密碼”。這個答案提供了一些背景信息,但我認為這本身並不是一個完整的答案。
正確地加鹽和散列,可以安全地存儲所有三個字母的組合,而無需使用純文本形式的密碼。對於8個字符的密碼,這將是336個組合,對於20個字符的6,480個-因此,您可能不認為這是實用的。
Ken Clubb
2014-08-04 08:47:57 UTC
view on stackexchange narkive permalink

這是非常糟糕的做法。今天必須對密碼進行哈希處理,以彌補可能丟失的密碼數據庫。密碼的各個元素都可以用於身份驗證這一事實意味著,正如TP已經指出的那樣,正在使用可逆加密而不是哈希。這很不好,因為如果數據庫和加密密鑰都被盜,那麼所有密碼都會丟失。哈希(使用強密碼)使此操作變得不可能。至少,如果對哈希進行哈希處理,使用強密碼的人是安全的。

我相信某些機構加密而不是哈希的原因是出於某種目的,後端可能需要完整的密碼,例如進一步的驗證。聯繫幫助台時,某些站點將密碼的後4位用作“安全性問題”。但這是一個可怕的原因,可能是因為尚未實施大多數知名站點使用的安全性問題方法。

我什至已經看到,當我使用電子郵件時,我的電子郵件中會顯示實際的密碼。要求重設-通過電子郵件實施密碼重設然後請求新密碼比發送電子郵件更複雜!最重要的是,與僅實施密碼重置機制以提示輸入新密碼相比,僅對密碼進行加密(甚至是明文加密)並將其用於其他目的要容易得多。

之所以不好,是因為當今大多數關心密碼的人都只使用密碼管理器。需要強密碼的各個元素容易出錯,並且比僅使用安全密碼管理器要困難得多。

最後,在通常使用弱密碼的情況下,使用強密鑰加密比散列更為安全,因為今天弱密碼哈希可以很快被破解。但是在這種情況下,哈希和加密是首選,而不僅僅是加密。

正確地加鹽和散列,可以安全地存儲所有三個字母的組合,而無需使用純文本形式的密碼。對於8個字符的密碼,這將是336個組合,對於20個字符的6,480個-因此,您可能不認為這是實用的。
@David:存儲組合的哈希值幾乎沒有好處,因為它允許逐個暴力破解,從而破壞了哈希的目的。例如,對於8位隨機字母令牌,有2 ** 48種猜測的可能性,但對於8分3位,只有2 ** 18種猜測一個組合,然後知道字符1 + 2 + 3可以瑣碎地破壞1 + 2 + 4(和所有其他相鄰組合)的哈希。數字小至2 ** 18時,您無法調整哈希值的強度,以使其足夠有效地防禦離線破解,而又不會嚴重降低正常登錄的性能。
@bobince:難道不是通過蠻力猜測其中一部分仍然需要獲得有關salt和哈希過程的知識(這將使以這種方式編碼的單個完整字符串無效),還是會使其更容易推斷?我假設沒有一種切實可行的方法來猜測鹽分函數+​​參數,因為他們知道結果之一表示“ a@1,b@5,c@8”?無論哪種方式,它至少都會阻止密碼輸入,這更糟。但是,無論哪種方式,都有更安全的方法(這裡的銀行正朝著OTP令牌等方向發展),所以無論如何,這一點還是有爭議的...
無論您如何對密碼進行哈希處理,您都必須了解哈希處理過程。保守秘密將是弱化的“默默無聞的安全”方法。鹽必須與哈希一起可用才能對其進行檢查,因此這不是秘密。哈希中可能會有其他機密材料(“胡椒粉”),但是必須像可逆加密的密鑰一樣,對該材料進行同樣嚴格的保護。知道“ a@1, b@5, c@8”的問題在於,對於“ 2,5,8”(僅需猜測一個字母)然後“ 1,2,3”等等進行強行哈希處理是微不足道的。獲取整個密碼。
作為估計的第一順序,應使用哈希後面的原始數學運算。假設已知哈希算法,鹽和胡椒粉,以及哈希值。
一個很好的解釋是在這裡:http://security.stackexchange.com/questions/17421/how-to-store-salt。現在,以某人使用密碼管理器的極端情況為例,該密碼管理器具有16個字符的62個字母字符集的密碼。可能的組合是62 ^ 16 = 5E28哈希值以檢查蠻力。將密碼分為兩半,即62 ^ 8 + 62 ^ 8 = 4E14組合。以大約7E11哈希/秒的速度,第一種情況需要2E9年,第二種情況需要9分鐘才能破解。


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