題:
記錄拒絕的密碼是常見的做法嗎?
Drew Lex
2012-07-05 03:59:39 UTC
view on stackexchange narkive permalink

儘管為每種目的選擇唯一的密碼是一個好主意,但實際上,這種情況很少發生。因此,許多人從容易記住的個人密碼池中選擇密碼。在不經常使用的系統中進行身份驗證時,很有可能會依次嘗試使用該池中的許多密碼。另外,輸入錯誤時,失敗的密碼非常接近於實際密碼。出售給出價最高的數據庫?

是否有實施指南?候選密碼被拒絕時通常會發生什麼?是將它們記錄下來,立即丟棄還是閒逛直到垃圾被收集?失敗的密碼處理過程是否屬於任何經過審核的控件的一部分?關於如何處理有效密碼,似乎有很多實施要求和建議,但對於拒絕的密碼值卻含糊不清。

EDIT

我將在此處嘗試列出記錄失敗的登錄安全性憑證的各種實現,以了解此過程的普及程度:

內容管理系統:

Joomla 通過登錄失敗日誌插件

此小插件收集有關您的Joomla網站管理員每次登錄失敗嘗試的日誌,並向用戶的超級管理員發送一封電子郵件,其中包含用戶名,密碼, ip地址和錯誤。

KPlaylist v1.3和v1.4 -一個免費的PHP系統,可通過互聯網。

正在將登錄失敗的用戶名和密碼記錄在apache錯誤日誌中

Drupal 版本5.19之前的5.x和版本6.13之前的Drupal 6.x

當匿名用戶無法登錄時由於錯誤地輸入了他的用戶名或密碼,並且他所在的頁面上包含一個可排序的表格,(錯誤的)用戶名和密碼包含在表格的鏈接中。如果用戶訪問這些鏈接,則密碼可能會通過HTTP引薦來源網址洩露給外部站點。

獨立軟件 p Symantec Client Security 3.1和SAV CE 10.1隨附的>

Reporting Server

可以公開Symantec Reporting Server的管理員密碼登錄嘗試失敗後。

Linux:

OpenSSH 通過修改後的 auth-passwd .c;通過重載pam_sm_authenticate函數使用PAM

EDIT#2

似乎存在共識,並且記錄失敗的密碼或PINS被視為嚴重/主要的安全風險,儘管如此據我所知,以下標準未提供專門解決此風險的指南,經過審核的程序或控制措施:

  • PCI-DSS: 8.4。和8.5。 (失敗的密碼僅在傳輸過程中受到保護;驗證後不視為密碼,因此不需要受到保護)

  • FIPS140-2:在4.3(失敗的身份驗證數據的生命週期僅得到部分解決)

相關(關於一個特定情況,而這個問題更籠統):[是否應該在錯誤消息中顯示密碼?](http://security.stackexchange.com/q/15452)
用戶應被延遲和登錄,但不能使用純文本密碼。您需要讓用戶使用單獨的線程或上下文來執行此操作,否則在某些情況下它可能會凍結其他用戶。
相關:http://security.stackexchange.com/questions/8323/is-it-legal-to-log-passwords-from-failed-logins
@AndrewSmith“ _您需要讓用戶使用單獨的線程或上下文才能執行此操作_”您能否解釋“上下文”的含義?
我已經看到在多個實例中,root用戶服務器上的trojan'ssh和`sshd`二進製文件已被修改為(以及安裝“後門”密碼)將成功密碼記錄到隱藏在某個位置的文件中。我想它是工具包的一部分,因為到處都可以看到相同的代碼。只是強調了“使用SSH密鑰”的重要性。
@tylerl“ _只是強調使用SSH密鑰的重要性_”“木馬程序ssh”不會洩漏您的SSH私鑰嗎?
@curiousguy您的密鑰應安全地存儲在自己的計算機上,而不是服務器上。
@tylerl我看到了:服務器受到攻擊,而不是您的ssh所在的計算機(並且您未在服務器上使用ssh客戶端)。無論如何,`sshd`不需要密碼即可訪問服務器上的所有文件。
-1
五 答案:
Mark
2012-07-05 05:19:51 UTC
view on stackexchange narkive permalink

記錄失敗的密碼嘗試(明文或其他方式)的值似乎是一種安全反模式。我從未見過執行此操作的Web應用程序,而且我不知道有任何默認系統服務(例如SSH)可以執行此操作。正如下面的@tylerl所指出的那樣,大多數係統僅記錄有關訪問嘗試的元信息(例如,用戶名,時間或IP地址等)。

為什麼這應該是安全的反模式

我可以想到以下三個原因來記錄失敗的密碼嘗試值是不好的想法:

1。用戶Typos

用戶輸入一個或兩個字符的密碼錯誤非常普遍。檢查失敗嘗試的日誌文件將使其中的許多問題很容易找出,特別是如果您可以將失敗嘗試的序列與成功的身份驗證進行對比。

2。猜猜並檢查

許多人都有兩個或三個密碼,可以循環使用所有密碼。因此,他們忘記了在給定站點上使用的密碼時,他們會循環瀏覽所有密碼,直到找到匹配的內容。這將使在其他站點上入侵其帳戶變得微不足道。

3。 Log Bloat

存儲失敗的密碼對於當今生產中的絕大多數身份驗證服務沒有任何用處。儘管可能存在一些極端情況,但對於大多數人而言,存儲此數據只是在浪費磁盤空間。

有關法律/標準

我不知道有任何標準(PCI,HIPAA等)專門解決存儲失敗的登錄嘗試的過程,但是我認為,鑑於上述事實,可以為為什麼相同的標準提出良好的法律論據。通常適用於存儲密碼,也應適用於密碼輸入失敗的嘗試。換句話說,您可以提出一個法律論據,認為失敗的密碼仍然絕對是密碼,因此,它必須遵循相同的標準。

雖然我當然不是律師,但我不想讓法官決定我是否疏忽大意或違反行業標準,因為失敗的密碼以明文形式存儲並且消費者遭受了後果。我認為這不會以有利的決定而告終。

我同意OP的觀點,即對於各個標準機構專門解決此問題可能很有用(如果他們確實還沒有的話)。 為此,我的建議是創建一個完全不存儲密碼嘗試失敗值的合規性標準。

在HIPAA下,我認為您需要生成一個失敗的登錄嘗試審核記錄(沒有密碼信息),但是他們對日誌記錄沒有任何評論。如果不在HIPAA中,則像IHE這樣的實現框架都需要它。
@Oleksi好點。我已經更新了答案,以指定要存儲訪問嘗試的值。醫療保健行業中的任何軟件都應維護成功和失敗訪問嘗試的日誌,作為HIPAA /有意義使用審核控制的一部分。當然,該日誌不應包含密碼值。
根據以下[@dr jimbob]建議的[article:](http://www.dailymail.co.uk/news/article-1255888/Facebook-founder-Mark-Zuckerberg-hacked-emails-rivals-journalists.html) ](http://security.stackexchange.com/a/16839/10923),Facebook早在2004年就開始收集失敗的密碼嘗試的價值。據我所知,立法方面沒有任何內容可能要求他們這樣做。刪除這種做法。
@DrewLex-Facebook是當涉及安全性和隱私時不該做的完美示例。
-1
PCI將“密碼”定義如下:>用作用戶身份驗證器的字符串。
凱文·米特尼克(Kevin Mitnick)正在入侵,並且在遠程服務器上有一個記錄器。沒有經驗的sysadmin不能完全記住服務器的密碼,因此sysadmin一直循環瀏覽他的密碼(所有密碼都是網絡密碼),從而使Kevin的工作更加輕鬆,因為他不再需要破解/破解密碼。允許程序記錄失敗的密碼幾乎是在做同樣的事情
我的老闆最初希望我將失敗密碼的SHA256鎖定在表中,然後我設法說服了他。但是我認為存儲最後一個失敗密碼的bcrypt hash + salt並使用它來確定是否重試了相同的錯誤密碼可能是有用的(我們有一個IoT用例,設備可能會不斷嘗試自動登錄。密碼錯誤)
dr jimbob
2012-07-05 10:03:03 UTC
view on stackexchange narkive permalink

為任何應用程序記錄純文本密碼沒有合法目的;特別是對於不正確的登錄。它可能是偶然記錄的-我出於其他目的隨意查看了 auth.log ,並看到用戶不小心將密碼輸入了登錄字段(並且我確實記錄了登錄字段以查看嘗試登錄的帳戶)。但是我通知了用戶,他們更改了密碼。

在另一方面,作為用戶,保守的假設是說每個隨機應用程序您使用的是記錄每個錯誤嘗試密碼。這就是為什麼在循環使用少量(三個)隨機密碼而不是在加密密碼列表中(可能使用keepass之類的工具)管理的每個站點使用唯一密碼時是一個壞主意的原因。

在此說明中,businessinsider.com指控Mark Zuckerberg(facebook創始人)使用來自 thefacebook.com (facebook的早期版本)的登錄名/密碼組合日誌(甚至來自不正確的條目)入侵正在調查他的哈佛緋紅色記者的電子郵件帳戶。 摘自每日郵報:

但是,在進一步提出索賠要求之後,扎克伯格顯然擔心報紙最終將在他身上留下一個故事。

Business Insider聲稱他隨後告訴朋友他是如何侵入Crimson員工的帳戶的。

據稱他告訴朋友,他使用TheFacebook.com來搜索稱自己為Crimson員工的成員。

然後,據稱他檢查了登錄失敗的報告,以查看是否有任何Crimson成員曾經在TheFacebook.com中輸入錯誤的密碼。

也有些相關 xkcd(假設惡意帳戶也記錄了嘗試輸入的密碼,以提高其成功率)。

+1提及XKCD就足以說明一切
@dr jimbob-Re“沒有合法目的記錄任何應用程序的明文密碼”-如何確定用戶帳戶是否受到暴力攻擊呢?
@Drew Lex-您可以(並且應該)記錄某人在某個時間從IP地址輸入了某個用戶帳戶的錯誤密碼,並可能啟用了額外的安全性(要求輸入驗證碼,重試之間的延遲,阻止IP地址,鎖定帳戶,等),如果失敗的登錄太頻繁(例如,從大約5次連續嘗試開始)。但是沒有合法的理由來記錄他們實際輸入的密碼。
XKCD +1,其中包含所有必需的信息;)
@drjimbob,我有一個想法,我問過一個問題,這是否代表您的觀點?謝謝http://security.stackexchange.com/questions/66484/temporarily-save-failed-logins-password-hashes-for-using-against-brute-force-att
tylerl
2012-07-05 08:22:21 UTC
view on stackexchange narkive permalink

記錄身份驗證嘗試失敗以及針對該用戶的事實並不罕見。事實證明,這在法醫故障排除中非常有用。從安全的角度來看,記錄被拒絕的密碼是非常罕見且不負責任的。此信息無濟於事,可以對您不利。

編輯
希望能夠期望您享有良好聲譽-組織好的公司不會出售您的密碼信息,因為如果發現這對他們來說確實是不好的。但是為了您自己的安全,您應該始終準備好將自己提供給您的信息用於對自己的使用,因為這總是有可能的。對於您無法可靠建立聲譽的任何組織來說,這都是兩倍。

+1我調整了答案以明確說明我的意思是記錄密碼嘗試的明文值。我還更新了對您的答复的引用,說明哪些元信息對於審核/記錄目的很有價值。
OnTheShelf
2012-07-11 00:17:13 UTC
view on stackexchange narkive permalink

上面有一些很棒的答案,所以這只是美國政府警察對處理機密信息的計算機系統進行管理的一種快速而簡化的觀點。

(1)必須保護整個計算機系統達到該計算機上任何數據所需的最高標準。這包括存儲在計算機上或計算機外的日誌。

例如,如果您有意或無意將“秘密”數據放在計算機上,則該計算機的每個部分現在都必須受到保護。作為“秘密”信息。即使您有一台未分類的計算機(例如在家裡)收到了包含分類信息的電子郵件,情況也是如此。整個計算機及其上的所有內容現在都歸為“秘密”。

(2)該計算機的密碼也歸為所有數據所需的最高保護級別。

例如,如果該計算機上有任何“秘密”數據,則無論密碼存儲在哪裡,它也需要相同級別的保護。

適用於您的問題,無論您使用的是哪種標準(例如PCI-DSS,NISPOM等),如果要求對密碼進行保護(例如散列和加鹽),則日誌中不能使用明文形式的密碼。

因此,總而言之,如果將任何監管方案應用於您所討論的計算機系統,並且該監管規定您不能使用明文密碼,則不能在其中使用明文密碼。您的日誌。

我同意應該將通過密碼字段輸入的任何字符串視為“用戶數據”或“密碼數據”,無論結果是否有效。不幸的是,“密碼”被定義為可驗證的字符串,這意味著不滿足此條件的值將不被視為密碼。沒有標准定義“密碼”的更廣泛定義。 [SP800-53](http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf)對失敗的密碼值保持沉默。
用戶斷言為安全令牌的任何信息(即使拼寫錯誤)也將被任何主管監管機構視為密碼。一個安全管理器使用一個論點,即用戶斷言未能驗證用戶身份的密碼不需要在系統級別進行保護,因此應以瀆職為由將其從自己的位置上刪除。在大多數受監管的環境中,我還希望它們在受監管的安全程序中不再受將來的工作。更重要的是,這會使他們看起來異常業餘。
John Haugeland
2012-07-06 05:38:32 UTC
view on stackexchange narkive permalink

不。用戶通常擁有一組密碼,並在密碼中循環瀏覽以找出給定站點所使用的密碼。記錄只是意味著當您受到攻擊時,他們的候補者就會被添加到任何打您的人的破解池中。



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