題:
如果提供者看到了我密碼的最後4個字符,他們可以看到完整的密碼嗎?
rhymsy
2015-09-17 19:51:51 UTC
view on stackexchange narkive permalink

我有一些域/網站以及Bluehost的電子郵件。每當我需要支持時,他們都需要該帳戶主密碼的後4個字符。他們無法告訴我他們如何存儲密碼,所以我對他們如何安全地存儲我的密碼並仍然看到最後4個字符感到很感興趣。他們會以純文本形式看到完整的密碼嗎?

所有方案都是可能的。
這是一個有信譽的虛擬主機,因此儘管我們不確定它是否以一種聰明的方式完成,但我們可以(可能)假設他們至少在某種程度上安全地這樣做。但是,確實沒有安全的方法來執行此操作。
下次您需要支持時,請給他們其他四位數。正如@Begueradj所說,所有情況都是可能的。這包括安全劇院。
@emory根據安全劇院的數量,有可能故意為他們提供錯誤的4位數字,這可能會導致索取者的帳戶被鎖定。
@immibis好點。打電話給他們,並使用其他用戶的憑據尋求支持。然後,當他們要求最後一個4時,請整理一下。如果他們繼續提供支持,則很有可能他們沒有用於最後四次驗證的系統,並要求將其全部顯示。
@immibis,您的建議是,“任何人”都可以通過簡單地撥打電話並提供錯誤的信息來鎖定另一個人的帳戶?
聽起來,我會將密碼的後四位有效地視為兩因素身份驗證PIN,並構造了一個強健的密碼,而沒有*後四位。 IE,將“正確的馬電池裝訂釘7684”作為密碼。
如果我按照您的描述進行了體驗,那麼我將盡快停止使用Bluehost。
我們絕對不能對@Chipperyman,承擔任何責任。您可能不知道,他們可能擁有龐大的客戶群,並且還會贈送信用卡號。
@emory到底會如何要求您輸入一部分密碼,以示身份?唯一顯示的是它們完全不具備安全性。
@Octopus的方式與在機場脫鞋保護航空的方式相同,向可能或可能無法驗證它們的服務代表記述4位數字可能會“保護” bluehost。某些用戶將不便等同於安全性。給他們他們想要的。
-1
-1
最後四個字符當然是“ 3456”或“ w0rd”或“ apple”
對於所有傳教士來說,這是“不可能的錯誤決定”-從業務角度來看,這可能是一個完全有效的用例。如果他們的密碼數據庫遭到黑客入侵,這將對公司不利。每個用戶都會被告知“違反安全性,請更改您的密碼”-如果他們不安全地存儲4位數字,密碼將更快地被破解。因此,聲譽受損會更高一些,但是由於無論如何這都是低概率的高風險方案,因此對風險預算的總體影響可能確實很小。用戶不會忘記自己的額外代碼的好處可能更大。
作為Bluehost的前僱員,我可以告訴您,他們不知道整個密碼。代理僅在一個框中鍵入密碼的後四位,然後系統將根據文件中的密碼對其進行檢查。如果匹配,它將變為綠色並被記錄,如果不匹配,則將變為紅色並標記該日誌。即使他們確實知道密碼,該員工所做的所有操作都會記錄在該帳戶上,然後可以查看是否假定有任何事情發生。至於密碼和加密的存儲,擊敗了我,但我從未聽說過
@Mansav仍然可以使用的唯一方法是,如果密碼未加密存儲在某個地方。
從技術上講,@Daniel可以具有2個散列,一個散列用於整個密碼,另一個散列用於最後4個字符。它仍然會降低安全性,但不會降低太多。
他們可以將最後4個字符作為單獨的值存儲在數據庫中(以明文或哈希表形式)-從而易於驗證。
他們可以將所有值相乘,然後將它們存儲為純文本格式。當然,這意味著許多密碼都是有效的,但是我認為這是一個很好的妥協。可能會使用除乘法之外的其他方法來獲取哈希,這將導致許多衝突。
九 答案:
Steve Sether
2015-09-17 20:12:43 UTC
view on stackexchange narkive permalink

有多種可能性。

  1. 他們可能會以明文形式存儲完整密碼,並且只向支持人員顯示最後4個字符。

  2. 他們可能會兩次對密碼進行哈希處理。一旦對完整密碼進行哈希處理,然後僅對最後一個密碼進行哈希處理,則支持人員將鍵入最後四個密碼,以查看其是否與哈希值匹配。這樣做的問題在於,由於後4個字符位於單獨的哈希中,因此可以更輕鬆地強制使用完整密碼,從而減少了熵。並存儲最後4個inplaintext。顯然,如果可以訪問密碼數據庫的攻擊者知道後4位數字,那麼使用強行破解密碼就容易得多。

  3. 後4位字符存儲在其他地方發現能力的方式,例如Mike Scott在下面提到的加密。如果能夠找到解鎖這4個字符的秘密,就和純文本一樣糟糕。

  4. ol>

    所有方案都非常糟糕,大大降低了系統的安全性。不可能知道他們正在使用哪種方案,但是每種方案都缺乏對安全漏洞的考慮。如果這是您關心帳戶遭到破壞的網站,我建議您謹慎。

至少還有一個選擇。他們可能會散列完整的密碼,並使用對稱加密來保存最後四個字符,因此他們的軟件可以為支持人員解密它們。仍然很糟,但不是很糟。
而且,大多數好的網站都會說出這樣的話:“這裡沒有人會**永遠**要求您輸入密碼。”當然,意思就是最後四位數字都沒有...
我剛剛檢查了Bluehost帳戶上的密碼更改表。不幸的是,該網站允許您使用短至8個字符的密碼,這意味著後四位數字會大大削弱某些密碼。 (我猜想對於足夠長的密碼,讓後四個字符被發現並不能將您的熵降低到足以引起實際關注的程度)
出於所有目的和目的,存儲後4個散列也等同於存儲純文本。使用現代GPU,您可以立即使用該功能。
一個好方案:密碼已拆分。前一個字符用一個鹽進行哈希處理,後四個字符用另一個鹽進行哈希處理。
@Ismael:仍然可以減少從O(2 **(n + k))到O(2 ** n + 2 ** k)的中斷時間,這真的很糟糕。可以想像到的與“好方案”相差甚遠(公認的是,比存儲純文本更好)
@IsmaelMiguel如果您要對四個字符進行哈希處理,那麼加鹽將無法為您節省。假設這些字符是從90個左右的一組字符中選擇的,那麼只有六千五百萬種可能性,並且可以很快對其進行暴力破解(除非他們使用像bcrypt之類的東西,且其工作因子足夠高,以至於減慢操作速度)。用戶注意到滯後的點)。
如果最後四個字符是使用具有大量衝突的哈希值存儲的,該方法將用於一次簡單的嘗試驗證,該怎麼辦?如果此哈希值被強行使用,它將生成許多錯誤結果,這將無助於獲得完整密碼。
@MikeScott您還將如何存儲4個字符的哈希?我雖然暗示它應該使操作盡可能慢。
@IsmaelMiguel您不會以存儲四個字符串的加密散列的方式來構建系統-沒有正確的方法,所以請不要這樣做。
@MikeScott精細精細精細精細精細精細精細精細精細。但是,您將如何保護4字符的引腳?
值得注意的是,最不安全的選擇也是最簡單的選擇,因此很可能是最可能的選擇。
如果我理解正確,它們可能僅允許您通過電話“輸入”四位數密碼。我想知道這是否會大大降低安全性,因為無法通過電話語音每秒進行數千次嘗試:)。 “第二”密碼可以存儲在具有隻讀訪問權限的數據庫中。我想知道這種情況對安全性有何影響。
如果將最後4個字符存儲為校驗位(類似於上述高衝突哈希),則不會顯著削弱實際密碼的哈希,因為可以安全地存儲該密碼。
-1
...但這對提供者來說仍然很愚蠢,因為他們還沒有向提問者解釋後果。他們本來可以要求單獨的4個字符的支持“密碼”。當然,如果這樣做,用戶仍然有可能會從主密碼中給您4個字符,否則很難說服他們。因此,您可以為他們生成該代碼,但隨後他們將不記得了,等等。或者您可以登錄並單擊一個按鈕以生成臨時支持代碼,但這對那些因支持問題而被鎖定的人沒有幫助他們的帳戶...
@IsmaelMiguel您必須將引腳存儲在硬件TPM中。銀行就是這樣做的。
@Navin那些不是只讀的嗎?此外,您將如何更改帳戶的密碼? (就我而言,我擁有的是ATM讀取的這本書,而不是信用卡,就像一張巨大的磁卡。您認為該書如何存儲?
一些銀行正在發行帶有PIN碼的信用卡,這些PIN碼會在嘗試了幾次有限次數後實際上阻止了對芯片的訪問。他們每個客戶可以擁有一個這樣的芯片,並安全地存儲其中的最後4個字符。他們可能沒有。
無論如何,絕不會通過預期的接口來進行@CommuSoft,暴力破解嘗試。那就太慢了。當/如果有人可以訪問數據庫,麻煩就會來了。將其與主哈希值分開存儲是無濟於事的,也不能使其只讀。
@ChrisMurray:我知道。關於只讀:我犯了一個錯誤,對於通過服務器進行連接具有隻讀訪問權限的數據庫呢?這將為規避造成額外的障礙。
@CommuSoft,不能使其僅寫,因為支持系統需要能夠針對它驗證給定的密碼。
@ChrisMurray:我的意思是數據庫服務器具有兩個連接:一個連接到僅寫的(webserver)。連接到“內聯網”的第二個可以管理讀取內容。顯然,可以嘗試破解訪問權限,但這會使它至少難上一步。顯然,只有一種方法可以寫入數據的設備只會增加宇宙中的熵。
如果我有密碼abcdef怎麼辦。他們對除最後四個字符(ab)以外的所有字符進行哈希處理,然後對最後四個字符(cdef)進行哈希處理。這意味著有兩個哈希可以完全獨立於不同的鹽。當您登錄時,檢查兩個哈希,但是客戶服務僅檢查一個。
@the_lotus這也是可能的,同樣也很糟糕。有很多不同的方法可以做到這一點,但是所有這些方法都會損害哈希過程。我不知道以不損害安全性的方式來執行此操作,除非您依賴TPM之類的方法,否則這樣做甚至可能是不可能的。
@CommuSoft我經營一家業務,處理很多交易,而這正是我的職責! Web服務器只能“寫入”存儲SSN,比特幣私鑰等的數據庫。只有具有物理訪問權限的人才能“讀取”數據庫。
“所有情況都非常糟糕”,請突出顯示答案的這一部分。使其盡可能黑,盡可能大和盡可能大寫。
列表的另一種選擇是可以使用HSM +對稱加密的密碼來完成。正確實施這並不是不安全的(例如,許多銀行/所有銀行都使用卡PIN)。
@GustavoRodrigues這也將增加錯誤的肯定身份確認的可能性。
我還看到了另一種方法(有時用於證書)-所有PIN都存儲在單獨的計算機上,僅通過簡單的串行鏈接進行連接。唯一可能的操作是“發送PIN->讀取成功/失敗”。除非有人*物理*地上電腦,否則它就一樣安全。而且,我們都知道一旦接觸到計算機,您可以使用計算機做什麼:)
請記住,在討論強行使用4個字符時,它們是通過口頭方式提供給服務代表的;不會一次自動嘗試數千次。
-1
WhiteWinterWolf
2015-09-17 20:10:35 UTC
view on stackexchange narkive permalink

由於我們不是Bluehost的秘密,所以總是很難回答這樣的問題,所以我們只能猜測並做出假設。

但是,您描述的行為仍然可能,而無需存儲任何明文形式的密碼:

  • 當您創建新帳戶或重置密碼時,密碼將發送到服務器,最有可能是受TLS保護的明文形式,
  • 然後服務器將生成相同密碼使用兩個不同的哈希值:
    • 第一個哈希值使用您的完整密碼並用於常規身份驗證,
    • 第二個哈希值僅使用密碼的最後四個字符,
  • 當您與他們的支持團隊聯繫時,您告訴他們您的最後四個字符,他們在其軟件上鍵入它們,然後他們的軟件將在內部計算哈希值,對其進行檢查並將結果顯示給支持技術人員。
他們為什麼會為此使用您的一部分密碼?這就是安全PIN的用途。
-1
bishop
2015-09-19 00:40:16 UTC
view on stackexchange narkive permalink

BlueHost建議使用強密碼的合理規則,因此他們可能僱用至少一個知道他在做什麼的人。

假設這樣,BlueHost可能正在使用 Shamir的秘密分享或該主題的變體。 Shamir的理論上是安全的,因此我不會立即得出結論(如其他答案所言),任何這樣做的方案本質上都不那麼安全。

另一方面,實現Shamir並非易事,因此,其他任何答案都可以同樣適用。由於安全性最終是關於信任的,因此,如果您對這種方案感到“不安全” ,建議您另找一個提供商!

或者他們能夠從其他人那裡“複製”一系列合理的規則。不幸的是在這裡。顯然是從[密碼的舊Microsoft頁面]複製的(https://web1.tcdsb.org/CCRFProduction/images/Strong%20Passwords.pdf)。他們甚至沒有對其進行調整以使其適合自己的網絡,例如“此網站上的密碼檢查器是非記錄功能_”(鏈接到Microsoft的密碼檢查器),或者討論了不同Windows版本上的空白密碼(超出bluehost的範圍)。
有了這些提示,他們甚至都不承認此內容來自2006年Microsoft的一篇文章(難道很難說“ Microsoft推薦以下技巧來提供安全建議”?),我非常懷疑它們得到了獲得版權所有者(可能是Microsoft)的複制許可。但是,比侵犯版權更為重要(對於一家公司而言,這足夠麻煩了),我認為我們可以推翻畢曉普的結論,並得出這樣的結論,即他們沒有僱用一個了解這一點的人(或者至少他們沒有聘請知道這一點的人) ')。
這使我更加警惕這家公司的安全性。如果他們因不正確的密碼建議而錯了事,**我怎麼能確定他們對重大決定是正確的呢?**尤其是在得知他們已經“將電話的最後四個密碼字符”用於電話之後,驗證…
@Angel進行了不錯的研究,並表示同意:由於沒有其他任何有關安全意識的證據,我懷疑它們的動機和實現。
我不明白為什麼這樣做會更安全。唯一安全的方法是,您可以為服務台人員提供一個“零件”,該零件必須經過社交工程設計。除此之外,您現在只需將4個字符與其他已知部分一起暴力破解,直到獲得與之匹配的秘密為止。即使在需要k + 2個部分的情況下,系統中有k個部分,k個服務台人員和1個僅由客戶知道的秘密,您最終最多還是可以擁有k個部分,您可以將其與另一個秘密進行比較找出哪一部分不起作用,因此必須是客戶的一部分。
kasperd
2015-09-17 23:13:03 UTC
view on stackexchange narkive permalink

我無法確切告訴您他們如何存儲密碼。但是從您對他們的過程的描述中,我們可以證明密碼必須以不安全的方式存儲。

我假設,當他們要求輸入最後四個字符時,他們實際上將能夠驗證正確性

這意味著他們擁有的數據將使他們能夠在短時間內驗證您告訴他們的字符。可以在蠻力攻擊中使用相同的數據來破壞密碼的後四個字符。四個字符肯定太短了,無法阻止堅定的攻擊者。

一旦攻擊者擁有最後四個字符,就可以在較早的字符上發起另一次攻擊。對於這種蠻力攻擊,密碼的後四個字符沒有任何安全性,因此充其量,您可以得到比實際短四個字符的等效密碼。

可以解決該問題。通過選擇一個安全密碼,然後附加四個完全獨立於最初選擇的密碼的附加字符來修復漏洞。如果他們只能驗證後四個字符而不是任意長度的後綴,那麼這將是安全的。

如果他們實際上能夠驗證任意長度的後綴,而不僅是四個字符的後綴,密碼存儲會更弱。這與將其存儲為明文一樣不安全,在這種情況下,您無法通過選擇更強的密碼來解決它。

的確,如果您可以驗證任意長度的後綴,那就結束了。只需256次猜測(或更少)即可驗證最後一個字節,然後再進行256次猜測即可驗證最後兩個字節(知道最後一個字節),依此類推,直到您知道256 * n次猜測中的完整密碼為止。正如您所說,就存儲散列的脫機攻擊而言,也可能是純文本。
hogarth45
2015-09-17 20:02:00 UTC
view on stackexchange narkive permalink

您知道密碼在存儲之前應先經過哈希處理,因此您必須問自己是否天氣,為了語音授權目的,它們存儲的是後4個字符,然後在存儲之前對密碼進行哈希處理,否則只是將其存儲為純文本。
我猜是後者。

emory
2015-09-18 09:19:45 UTC
view on stackexchange narkive permalink

我認為這不可能,只是可能。

每次OP需要支持時,他們都會要求輸入他密碼的最後4位數字。他們對它進行加鹽和散列,並將鹽和散列以及足夠的信息存儲在特殊的支持表中以重建支持。

然後,當OP登錄(使用完整密碼)時,他們可以查看支持表並計算哈希。然後他們提交經過驗證的“支持”並否定偽造的“支持”。

這當然假設

  • 支持是可以提交或廢除的東西在以後的時間

  • 詢問後4個信息的過程不會洩漏信息(有人詢問您最後4個信息的資格不合格,因為我們無法可靠地擦除他們的記憶) 。

我無法想像這種情況具有商業意義。但是,如果這樣做的話,我想我應該為用戶提供一個特殊的4位“支持”密碼。

並且,如果存儲的尚未驗證的“支持”可以與散列的完整密碼一起被盜,它們仍然是解密者的寶貴幫助。
@BenVoigt是的,強行強制使用最後4位數字是可行的,因此將其加鹽不會增加太多價值。或者,如果攻擊者可以觀察到哪些支持被落實或拒絕,並且攻擊者可以在不觸發中斷的情況下自動執行支持請求,則觀察者可能可以在線暴力破解最後4個支持。
如果用戶提出了一堆支持請求,然後忘記了密碼,則將提交或拒絕支持請求。如果提交,則攻擊者可以提出一堆支持請求,然後假裝為用戶“忘記密碼”。如果拒絕,則攻擊者可以拒絕真實用戶的支持請求。
CoffeDeveloper
2015-09-23 15:52:32 UTC
view on stackexchange narkive permalink

他們可以看到完整的密碼嗎?是的,他們絕對有可能會猜測密碼(如果最後4位數字是一個日期或一個單詞的一部分。如果密碼被完全散列,則知道4位數字就足以進行蠻力攻擊甚至嘗試對哈希函數進行試探以查看4位數字如何傳播回去,從而大大減少了可能的密碼範圍。

猜密碼:

  ** ******* ange  

或者這個:

  **** 1994  

它他們有可能成為黑客並利用客戶支持API(如果有)來訪問用戶信息,知道4位數字甚至會使這項任務變得更加容易。

他們不應該這樣做,在任何情況下都不應給出將密碼的一部分提供給陌生人也是一個不錯的選擇(特別是,如果他被解雇了,他可能會試圖傷害用戶,並且有很多歷史例子),如果它是客戶支持的一部分。

客戶支持人員應該無法訪問原始密碼,應該通過臨時API進行操作nt做得不好(仍然支持人員不能訪問完整數據)。

此外,如果客戶支持人員要求輸入4位密碼,則不能向用戶發送警告,例如“從不輸入密碼”密碼,因為我們不這樣要求。”“因為您實際上是在要求並培訓用戶提供個人詳細信息,可能會幫助他們被網絡釣魚電子郵件捕獲。

如果他們真的想檢查用戶的機密性,則應該使用諸如SMS代碼,秘密問題或僅是電子郵件發送鍵之類的東西。

我仍然認為,發送電子郵件或SMS比花1-2分鐘執行相同操作的人要便宜得多(除非她/他確實是薪水低的人)。

如果服務真的需要檢查某人的重要身份,我可能會使用網絡攝像頭流,以便操作員可以看到用戶的臉部,然後要求其執行特定操作(例如在紙上寫一個字並顯示他回來),以防止他人使用錄製的視頻。

當然,由於隱私^^

,用戶當然不會喜歡它。
您的答案沒有回答問題。附帶說明:我不相信這裡的任何人都在倡導這樣的系統是最佳實踐,甚至沒有問題,但這並不是這裡的主題。
現在正在回答^^,我忘了寫那部分,因為我正忙於寫答案的“其他部分”。 @Selenog
@Selenog和這一點上的否決票應予以撤銷?
Falantar
2018-12-21 04:45:43 UTC
view on stackexchange narkive permalink

正如其他人所說,此提供程序可以採用多種方法來保護密碼的“後四位數字”。但是,無論何時廣播甚至一部分密碼,您都在敞開心to讓自己的帳戶遭到破壞。似乎沒有人提到的一件事是,您輸入到聊天日誌中的密碼的後4位可能未加密。顯然,聊天記錄需要易於訪問。即使遵循基本的密碼複雜性規則,您也僅將密碼的有效長度減少了4個字符。現在想像一下,如果您在其他地方使用的密碼安全性較輕(不幸的是,很多人都這樣做)。

TL:DR這是一種荒謬的做法,我將不惜一切代價避免使用它們。

我會說這是明顯的白痴。看不見的白痴會帶來更多問題(例如,允許軟件開發公司聘用他們開發客戶關係系統的人員,並在加密之前先查看已加密的密碼)。
rocccccc
2015-09-17 22:03:20 UTC
view on stackexchange narkive permalink

他們可能會存儲您整個密碼的哈希值,再加上最後四個字符的哈希值,然後是12個隨機生成的字符。如果它們生成隨機字符的方式與散列過程一樣安全,那麼它應該與自己存儲密碼一樣安全。

那行不通。您將如何自己驗證最後四個字符?
這與用12個字符的salt字符對4個字符的尾部口令加鹽不一樣嗎?問題是4個字符太小,以至於鹽不能阻止強力搜索。加鹽仍然不能阻止暴力搜索。
任意數量的附加字符確實增加了這個答案的荒謬性。


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