題:
學校會定期進行密碼審核。我的密碼被盜了嗎?
GB1553
2019-03-06 00:11:15 UTC
view on stackexchange narkive permalink

我的大學給我發送了一封電子郵件,通知我,在“定期檢查”期間,我的密碼“很容易被發現並且有受到威脅的危險”。據我了解,除非我的密碼以明文形式存儲,否則他們應該沒有辦法定期檢查我的密碼。我的問題:

  • 我的理解是否錯誤,或者我的大學是否一直以明文形式存儲我的密碼?

更新:學校的IT部門將我鏈接到一個頁,說明他們檢查密碼的各種方式。頁面的一部分允許我在大學帳戶上運行測試,並在確實從他們的測試中發現密碼的情況下顯示密碼。它顯示的密碼是我的一個較舊(較弱)的密碼,只是用空格分隔的英文單詞,這說明了他們如何找到它。謝謝所有回答的人。

也許他們正在破解哈希?也許他們正在使用hadibeenpwned或類似的東西。您的密碼是否很弱?
字典攻擊的方式可能很容易,具體取決於它的構造方式...但是對於您學校的IT部門來說,這樣做似乎有點野心勃勃:
我已經更改了密碼,所以我不妨告訴一下格式。隨後是XKCD格式,英語單詞之間用特殊字符分隔。
請與IT部門聯繫以確保。特別是如果您通過電子郵件獲得。可能是網絡釣魚的嘗試。
請不要在擴展對話中使用評論
我提出另一種可能的解釋-沒有人入侵任何東西,他們只是基於相應的證據來警告他們。您是不是很久以前就創建了密碼?也許他們在創建密碼時發現了密碼強度驗證方面的弱點?
聽說您有XKCD格式的密碼,並且他們在檢查站點上向您顯示了該密碼,這使我更加懷疑他們使用純文本格式的密碼。
@user3067860,這就是為什麼我使用特別侮辱個人的短語作為密碼的原因。不錯,很結實,所以通常的翻錄者等都不會獲得成功,如果他們將其存儲為純文本,我還沒有被HR要求:)
@GaryBlake撰寫了“解釋他們檢查的方式...”和“允許我運行測試” ...這些方式是什麼,您運行了哪些測試?它是一種僅檢索您的純文本存儲的密碼並將其顯示給您的測試,還是只是一種嘗試蠻力猜測密碼的工具?如果他們擁有可以輕鬆暴力破解XKCD樣式密碼的工具,那我們應該知道。
-1
您在更新中寫的@GaryBlake,中看到了舊密碼。這意味著是的,他們以明文形式存儲學生的密碼。也許不是他們當前的密碼,但是由於人們通常會重用他們的密碼,因此他們那裡可能有一些學生的明文銀行登錄信息。請去抱怨。
@Aaron如果您的密碼根本沒有任何“語法和句子結構”,那麼那實際上不是“ XKCD風格”的密碼,因為該漫畫的重點是建議*隨機*選擇幾個單詞,然後輕鬆地從它們創建助記符。如果您先創建助記符,然後將其轉換為密碼,那麼您會像白痴們仍然在強制使用特殊字符之類的那樣,嚴重地錯過這一點。
@GaryBlake您是否正確遵循XKCD格式?例如,通過實際的隨機選擇(或至少通過一種良好的強偽隨機方法選擇單詞),因為幾乎不可能生成真正的完美隨機性)?如果您這樣做了,那麼,是的,任何聲稱已破解的東西要么完全是在這樣做,要么是在攻擊其係統中的弱點,而不是密碼中的弱點。如果您只是選擇了四個喜歡的單詞來做到這一點,那麼您需要返回並重新閱讀漫畫,這次還要更加註意細節。
“這解釋了他們如何找到它。”我不確定這是否正確-如果您有2個字,是的,這將是微不足道的(可能是400萬個猜測,對於一台像樣的計算機來說並不算多),但如果是4個字,則應該更難他們無法合理地破解。
@MatthewNajmon,它也可能是一個輕率的管理者,認為“正確的馬電池釘”是一個可怕的密碼,因為它不包含大寫字母,數字或特殊字符。我有一個正確的馬力電池裝訂密碼,然後我加了帽子,數字和破折號來滿足這些拉默,然後,貝寶抱怨說,因為破折號不夠特殊。SMH ...
六 答案:
Mike Scott
2019-03-06 00:19:08 UTC
view on stackexchange narkive permalink

您的理解是錯誤的。如果密碼存儲為強鹽散列,則管理員無法找到用戶密碼,而是可以通過將散列和鹽值應用於密碼中的每個密碼來找到常用密碼列表中的密碼。列表並尋找匹配項。但是,如果不對存儲的密碼進行加密,則容易得多,因為在這種情況下,您只需要對每個用戶運行一次,而不必對每個用戶運行一次,因此此可以表示未對存儲的密碼進行加密,這與最佳做法相反。

@forest該模式可能是密碼出現在特定列表中。但這首先會破壞使用彩虹表的目的。彩虹表的目的是減少預計算哈希值所需的存儲空間。如果您需要存儲Rainbow表涵蓋的密碼列表,那麼您將一無所獲。
@kasperd是的,從理論上講,歸約函數可以是一個查找表,但是那將是非常愚蠢的。
@forest就是我的意思。
gowenfawr
2019-03-06 01:22:29 UTC
view on stackexchange narkive permalink

據我了解,除非我的密碼以明文形式存儲,否則應該沒有辦法讓他們定期檢查我的密碼。

實際上,存在:破解

有一種已知的做法,系統管理員可以根據散列密碼運行破解工具(John Ripper,Hashcat等)。擁有簡單密碼的人可能會花費很少的時間。因此,按照他們的定義,如果他們破解了您的密碼,就很容易發現它並且有風險。

引用這篇關於開膛手約翰的文章

>

由您決定如何使用John。您可以選擇定期在系統上的所有密碼哈希中運行它,以了解用戶密碼中有多少比例不安全。然後,您可以考慮如何更改密碼策略以減小該比例(可能是通過增加最小長度)。您可能希望與密碼較弱的用戶聯繫並要求他們更改密碼。決定該問題需要某種用戶培訓程序,以幫助他們選擇更安全的密碼,而無需寫下來即可記住它們。

但是,如果該機構運行像bcrypt或PBKDF2這樣的體面的密碼哈希算法,即使這樣做也不可行-這將佔用過多的處理能力。那不正確嗎?假設他們要檢查100,000個簡單密碼中的每個密碼,那麼在恆定的CPU負載下,他們每天要做的事情不只是幾個密碼。
@thomasrutter如果您要嘗試的是從頂部清除“簡單”密碼,那麼DES和PBKDF2之間的周期差異就不如完全暴力攻擊那樣嚴重。同樣,這是一個自定義的問題。在那段時間裡,任何猜想到管理員擁有足夠的CPU來扔的東西都是“易碎的”,這並沒有告訴任何人任何潛在的隱患……這是一個有爭議的方法,因為它使管理員感覺良好,有時功能強大;它並不能總是導致用戶習慣的明顯改善。
@thomasrutter在您的情況下,您期望什麼時間才能驗證一個密碼?您是否在談論複雜性設置,需要整個機器持續幾秒鐘?您認為可以用於實踐嗎?(更不用說有一個與kerberos和/或AD兼容的實際用戶目錄了嗎?)
這些算法具有可伸縮性,因此您基本上可以選擇每次要花費的處理週期,我腦子里通常會花不到一秒鐘的時間來計算平均單個CPU,但是這些僅僅是個小問題。並且有合理的論據可以使其速度提高10倍或100倍。
Ghedipunk
2019-03-06 00:18:48 UTC
view on stackexchange narkive permalink

您的大學可能沒有以明文形式存儲您的密碼。他們有一種非常簡單的方法來獲取密碼的純文本,我懷疑他們每天至少可以訪問兩次。

您每次登錄時都以純文本形式提供密碼

。如果您要登錄由他們託管的應用程序(例如管理在線課程或檢查成績的網站),並且它們具有該在線應用程序的源代碼,則可以輕鬆進行此操作無需存儲您的純文本密碼或將其傳輸到另一個系統即可訪問它,並且可以在那時檢查密碼的安全性。

他們也可以在您登錄時檢查密碼的強度。正在使用單點登錄服務。

但是,它仍然非常混亂。請與您大學的IT部門聯繫,並確認他們正在安全地存儲您的密碼。詢問有關他們如何檢查密碼的明確問題。

我的其余建議遵循標準的Internet身份驗證建議:請勿單擊該電子郵件中的任何鏈接;如果您確實要更改密碼,請通過常規方式而不是通過電子郵件發送給您的鏈接來進行。使用密碼管理器來存儲和生成長隨機密碼。 (理想情況下,您只應該知道兩個密碼:一個用於登錄計算機,一個用於登錄密碼管理器。)切勿出於任何目的重複使用密碼。

與大學的IT部門交談時,向他們詢問有關2因子身份驗證的問題。

“您每次登錄時都會以純文本形式給他們提供密碼”-除非他們從主機的內存中提取密碼(我說這不太可能),或者這是一個配置很差的Web應用程序,我很難想像這是他們進行密碼審核的方式。
@DKNUCKLES您從未見過在發送密碼之前會在本地檢查密碼強度的Web應用程序嗎?它在註冊表單中非常常見,我遇到過在事發後應用它並拒絕“弱”密碼的系統,這迫使使用丟失的密碼系統。(我更喜歡密碼短語而不是$ pec1al character $,而且已經不止一次。)
@LorenPechtel這是不同於OP所指的情況。在設置密碼之前,客戶端對密碼強度的驗證並不困難,並且可以在不暴露明文密碼的情況下完成。OP描述了經過追溯審核的現有密碼。
@DKNUCKLES但是誰說它具有追溯力?將審核代碼放入客戶端,它告訴服務器密碼很弱。
如果只有一次登錄服務,那麼在用戶登錄時可以在服務器端同時檢查密碼強度,這真是令人難以置信。
因此,我們假設使用一些令人費解的陰謀論(如果您的計算機位於域中,那麼他們肯定可以安裝記錄您密碼的鍵盤記錄程序),而不是通過對存儲在域/數據庫中的哈希值運行某些密碼破解工具的明顯解決方案?好吧..可以肯定他們會盡一切努力,但是將其作為標准假設似乎很愚蠢。
@DKNUCKLES,感謝您的反饋。我已經更新了答案,以澄清這種對明文密碼的訪問最有可能的來源是在線應用,其中站點所有者可以訪問源代碼。
@LorenPechtel OP的更新清楚地表明它是可追溯的,密碼是一個舊密碼,不再使用。
@user3067860使用此更新很可能會遇到安全問題。
我已經通過在登錄時攔截密碼來將存儲MD5密碼的系統升級為一種更安全的方法,如本答案所述。因此,在用於登錄時攔截密碼的想法既新穎又聞所未聞。
@Voo不需要鍵盤記錄器。密碼不會在客戶端而是在服務器上轉換為最終形式。而且許多服務都允許可配置的身份驗證模塊,因此您可以交換舊的身份驗證系統並交換新的身份驗證系統。對於知道在交換常規系統包裝系統的系統的人來說,這沒什麼大不了的在將其轉發到真實身份驗證系統之前,它會使用純文本密碼執行某些操作。
-1
在任何情況下都只是為了清楚:是的,人們可以攔截所有密碼,包括安全密碼,這絕對是可怕的做法。但這不應該是imo的默認假設。有些解決方案可以正常運行,而不會帶來任何麻煩。在高風險環境中,進行這種密碼檢查是標準程序,一所大學試圖向學生傳授良好的密碼做法,這是非常好的。
@Voo但是您不能說每個人都必須假設您所描述的是正在發生的事情。那也是我的第一個猜測,但是1)問題本身是在詢問發生了什麼以及密碼是否被洩露,所以這裡的重點是討論可能的事和可能的事,以及2)第一所大學我實際上去了(仍然可能)存儲純文本密碼,許多員工可以直接訪問它們以進行查找-幫助台通常會忘記密碼,並會通過電話告訴人們。我知道,因為我後來是一名員工,也可以使用它。
@Aaron哦,很高興提到該選項(當然可以,Knuth知道有多少組織採用了糟糕的安全做法),但是對我的回答使這聽起來非常邪惡,並且沒有提及完全有效和安全的替代方法。
@Voo您給別人太多了。;)我總是被教導要假設您的所有用戶都是邪惡的(儘管可能並不擅長),並且您所依賴的設計或開發軟件的人都是白痴。當然,這是從計算機部門的角度來看的……當然,這對於人力資源員工或高層管理人員採取這種思維方式將是一場災難。
@Voo,當我的用戶重置密碼時,我個人使用了Pwned Passwords API,以便在受到威脅時通知他們,並且他們應該停止重複使用密碼...因此,是完全有正當理由的。但是,隨著問題的更新,OP表示他們看到了舊密碼,這意味著大學可能不會以明文形式存儲_current_密碼,但是他們肯定是以明文形式存儲已洩露的密碼,這表明他們的權限不足,所以我堅持我的回答是“他們潛在地邪惡/無能”。
Facebook完全按照此答案的描述進行操作。
DKNUCKLES
2019-03-06 00:53:44 UTC
view on stackexchange narkive permalink

這裡需要做一些假設,但是我想您所指的大學密碼就是Active Directory帳戶的密碼。 Active Directory密碼使用NTLM哈希格式處理的密碼,該密碼不會加鹽。考慮到這一點,在不同環境中相同的密碼將具有相同的哈希值。

Troy Hunt提供了一項名為 Pwned Passwords的服務,該服務使管理員可以下載5.17億個密碼哈希。您學校的IT部門可能正在將Active Directory中的密碼哈希與上述數據中多次出現的哈希進行比較。

以明文形式存儲密碼確實有時(主要是在專有Web應用程序中),上述情況是我的假設,即它們如何確定您的密碼很弱。

WoJ
2019-03-07 20:47:04 UTC
view on stackexchange narkive permalink

顯示的密碼是我的一個較舊(較弱)的密碼,它只是用空格分隔的英文單詞,這說明了他們如何找到它

FYI-不,不是的。這取決於單詞及其數量。將幾個隨機詞典單詞粘合在一起實際上是一個很好的密碼。

我當然應該鏈接到相關的xkcd。

重點是*隨機*,並假設有足夠大的單詞池。如果它是語法上有效的SVO句子,則熵會急劇降低。
@Voo:當然可以,這是選擇一個好的密碼的全部問題,而不是“ password”或“ correchorsebatterystaple”。現在,有效的句子本身就不是問題,除非您知道密碼生成方案(=攻擊者知道您將構建正確的名詞-動詞-副詞句子)。* ifindmystackoverflowanswersbrilliant *是一個很好的密碼。
攻擊者不必*知道*它,他們可以嘗試常見的模式來一次又一次地看到您。而且,如果您查看常見的密碼洩漏,您會發現大多數使用句子的人都會以非常特定的格式使用語法正確的句子。參見例如[本文](http://www.jbonneau.com/doc/BS12-USEC-passphrase_linguistics.pdf)展示瞭如何利用它。因此,儘管“ Ifindmystackoverflowanswersbrilliant”可能還不夠好,但xkcd漫畫中顯示的數學對它並不適用-熵要弱得多。
-1
@WoJ除了[現在您已將其發佈到互聯網上](https://security.stackexchange.com/questions/201210/why-is-gbt3fc79zmmefufj-a-weak-password)之外,不再是。
Atul Kumar
2019-03-06 21:25:22 UTC
view on stackexchange narkive permalink

密碼不是以純文本形式存儲的,實際上,應該以任何技術上的方式對其進行加密和存儲。但是,由於符合安全頻帶要求,因此可以使用各種技術算法對密碼進行解密,並通過各種模式查找弱密碼。您的大學一定已經做到了,並通知了您。

我相信您要查找的短語是散列的,而不是加密的。如果您確實表示加密,那麼那是不正確的,因為它是可逆的。我認為您的意思是散列,因為您提到的將過程逆轉的方式稱為“各種技術算法”,而不是簡單的“解密”。
1:定義*'“安全帶遵從性” *。2:*“各種技術算法” *沒有意義。3:提示;您可以刪除問題。
“密碼未以純文本形式存儲”這是不正確的。我參加的第一所大學確實存儲了純文本密碼。實際上,在致電他們的服務台時,支持人員可以(其中一些人確實)口頭告訴您您忘記的密碼是什麼,因為服務台員工(以及許多其他人員)可以直接訪問純文本密碼。我知道直到至少幾年前,這種方式仍然存在。
-1
從上下文來看,我認為Atul的意思是“密碼不應以純文本形式存儲”
為了澄清起見,只想補充一下,作為一種良好做法,密碼和任何敏感信息都不應存儲在計劃文本中。但是,我看到很多情況下,由於設計和開發人員根本不在乎或意識到問題而發生這種情況作為安全性和審計的一部分,發現這是一個更大的問題,整個應用程序或產品都可能出現問題。許多國家/地區都有不同的數據保護法律,這顯然將這視為一個更大的問題。
@AtulKumar僅僅因為法律禁止某些事情,並不意味著它不會發生。您也沒有回答問題。


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