題:
用2種方式加密存儲密碼是否安全?
43Tesseracts
2017-11-23 03:22:56 UTC
view on stackexchange narkive permalink

我是一位在本地學區擁有父母帳戶的父母,因此我可以登錄他們的網站查看孩子的成績等。

我點擊了“忘記密碼”按鈕,並且我的密碼以純文本形式發送給我,這使我感到關注,所以我通過電子郵件向校長發送了電子郵件,其中包括來自此頁面底部的一些鏈接。這是我從組織的IT部門收到的回复:

父密碼不是以純文本存儲的,而是經過加密的。不是單向加密,而是兩向加密。這就是系統能夠通過電子郵件通過Ariande的方式將其顯示回來的方式。

出於支持的原因,某些員工只能看到父母密碼,直到父母成功登錄3次為止。此後,任何員工都看不到該密碼。但是,該密碼存儲在這樣的密碼中。系統本身可以將其發送回經過驗證的電子郵件的方式。如果將來父母成功3次登錄,如果他們忘記了r密碼,將向其經過驗證的電子郵件帳戶發送一個鏈接以重置其密碼,此更改正在進行中。

此說明是否證明通過電子郵件發送的純文本密碼是合理的,並且

如果沒有,我可以用哪些密碼或密碼回复我的密碼?

*你能數嗎?指望自己!*不要重複使用密碼,請使用密碼管理器。
如果您沒有超出問題標題的範圍,那麼我可以回答“否”,並可以99.999%的確定我的觀點是正確的。主要關注互聯網通信的公司和組織都犯了這個錯誤。一個資金不足的學區,其現有目的完全不同,僅使用電子通信作為隨時可用的便利,就很難理解安全性的微妙之處。真正的問題不是“他們是”,而是“為什麼以及為什麼不”。
IT專家在一個軟件標題中打了兩次錯字,這與您確實通過郵件發送密碼一樣有效……
克里基!這件事很酷,是IBM!也許學校缺少資金和專業知識,但這就是為什麼他們使用供應商。沒有任何藉口。沒有。
“父母的密碼對某些員工是可見的” –使用密碼管理器,小心輸入平台上的內容甚至都無濟於事。您的密碼被其他方知道,因此您可以被假冒
考慮到有多少人使用單個密碼來處理所有事情,員工在任何情況下都可以看到密碼這一事實確實令人擔憂。用戶註冊時會收到通知嗎?
IT部門的這些評論不僅證實了您的擔心,還顯示出嚴重的其他缺陷:它們使工作人員可以看到您的密碼-我的意思是為什麼!也沒有正當的理由。如果它違反了他們應該遵循的某些規定,我不會感到驚訝。
該站點不在主題之列,但假設適用美國聯邦法律,則“某些工作人員可以看到父密碼”這一事實意味著該系統無法檢測到非法[FERPA](https://www2.ed.gov/policy/gen/guid/fpco/brochures/parents.html)表示,這些員工可以訪問受保護的教育記錄和個人身份信息。
他們顯然對此進行了很多思考,並提出了錯誤的答案。如果他們對此未作過多考慮,我會更好地理解(教育孩子而不是互聯網安全應該是他們的重點)。由於他們考慮了很多,仍然對FUBARed感興趣,所以我必須假設他們在教學法方面也很差勁。忘記密碼了。您現在正在自學。
@emory校務委員會IT人員!=教學人員
@Blorgbeard:當密碼對站點人員可見時,使用密碼管理器無疑會有所幫助。因為您使用的是密碼管理器,所以它們擁有的是從主密碼和鑰匙串一起獲得的站點密碼,而不是您的主密碼。因此,這將不利於他們訪問其他帳戶。當然,沒有密碼管理器就可能有成百上千個唯一的每站點密碼,但這是完全不切實際的。因此,員工訪問密碼而不使用密碼管理器的真實效果是,他們學習了在某些站點組上重複使用的密碼。
值得注意的是:安全性和可用性通常是平衡的。在這種情況下,他們似乎很不願意換取高可用性。對於學校,這可能是必要的。
@EricTowers假設任何一個甚至在系統中。有什麼風險?有人使用您的密碼可以做什麼?看到他的成績嗎?獲取您的信用卡號?將孩子的健康保險轉移給孩子?更改他的醫療/過敏清單?將您的孩子從課堂上拉出來,然後把他送到麵包車裡一個令人毛骨悚然的傢伙嗎?許多密碼沒有任何價值。
@EricTowers:我不關注。“某些職員”也看不到學生的成績嗎?難道“某些員工”常常不必在線進入系統評分?難道他們只是因為工作的一部分並且在法律要求下不披露信息而被授權做他們正在做的事情嗎?您如何得出結論,這必然是FERPA違規?
@Mehrdad:我沒有。您應該仔細閱讀。此外,您假設可以看到密碼的一組職員和允許查看“所有”記錄的一組職員是否相等。您似乎也不了解FERPA固有的法律要求的廣度和深度。
我以為@EricTowers:假設您的意思是無法檢測到非法訪問是FERPA違規行為,但是如果沒有,那麼問題就更少了。問題是,我看不到FERPA問題。這些集合為什麼不能基本相交?“某些職員”還可以更改父母的密碼,以該父母的身份登錄,然後再將其更改回。如果您正在考慮“但在日誌中可以看到”,那麼,工作人員查看密碼的操作可能同樣容易在所述日誌中引發標記。現在,與其嘲笑我缺乏法律知識並任由其嘲笑,不如將其解釋為更有益的。
@Mehrdad:僅僅因為學校IT成員有權查看父母密碼,並不意味著他們被授權模仿他們訪問記錄。當然,無法檢測到未經授權使用這些憑據。我希望我能生活在您的虛構世界中,每個人都可以使用它,但是沒人會濫用它。
-1
@Mehrdad:您似乎拒絕理解“無法檢測到非法FERPA訪問”的含義。為什麼我要比您更努力地了解您?
“ @mickeyf” ...很難指望了解安全性的精妙之處。抱歉,這種態度是問題的一部分。當您對用戶數據進行任何處理時,了解安全只是保持能力的一部分。期。這還不算什麼。這只是對問題的了解。
五 答案:
Tobi Nary
2017-11-23 03:32:06 UTC
view on stackexchange narkive permalink

不,這不是一個好習慣。有兩個明顯的問題。

  • 加密密碼而不是散列密碼是一個壞主意,並且是存儲純文本密碼的邊界。慢散列函數的整體思想是阻止用戶數據庫的外洩。通常,如果Web應用程序有權訪問該數據庫,則可以預期已經具有數據庫訪問權限的攻擊者也可以訪問該加密密鑰。

    因此,這是邊界明文。我幾乎投票結束了這個問題,作為這個問題的重複,因為這幾乎是相同的,而且鏈接的答案幾乎直接適用,尤其是關於明文犯規者;對於明文違規者也有另一個答案

  • 通過純文本電子郵件發送純文本密碼是一個壞主意。他們可能會爭辯說,密碼重用不會發生,但我懷疑他們什至會知道那是什麼以及為什麼認為這是不好的做法。另外,密碼重用非常普遍,因此不是一個很好的答案。

此外,因為密碼重用似乎在第二部分中起作用(即使密碼重置鏈接也是如此)純文本電子郵件在同一範圍內,即可以從純文本郵件中讀取密碼的威脅也可以讀取鏈接(也許在您可以之前),您可以向他們解釋關於不從我的答案中散列的問題,可以直接鏈接此答案

甚至可以解釋加密是一種方法,但始終可以通過所討論的加密系統的反函數(適當地稱為解密)來逆轉。使用“單向加密”和“雙向加密”之類的術語而不是“散列”和“加密”表示缺乏理解。

真正的問題是:他們實施密碼重置並不意味著將來會(正確)進行哈希處理;除了使用密碼管理器並創建一個長而強大的密碼短語(對於此網站來說是唯一的,並希望獲得最好的密碼),您無能為力。

尤其如此,因為他們似乎想要保留告訴員工密碼的系統部分(完全出於的充分理由)。這意味著他們一直沒有正確進行哈希處理-他們說工作人員只能在三個登錄時間範圍不正確的情況下看到密碼;如果Web應用程序可以訪問密鑰,則管理人員也可以訪問該密鑰。也許不再是客戶支持人員,但他們首先應該看不到它。這是非常糟糕的設計。

根據您所在的位置,作為公共部門一部分的學校有義務擁有您可以直接聯繫的CISO,表達您的疑慮。而且像往常一樣,在公共部門中,應該有一個監督學校的組織;他們至少應該有一個CISO,他們可能對此過程很感興趣。

可能還會將他們(即學區的負責人)指出[從Adobe網站大量洩漏密碼](https://arstechnica.com/information-technology/2013/11/how-an-epic-之所以會犯錯,是因為adobe可以加強手的密碼破解器/),這是因為密碼未正確(單向)散列,而所有密碼(兩向)都使用相同的加密密鑰進行了加密。另外,將他們指向[plaintextoffenders.com](http://plaintextoffenders.com/)可能是一個好主意-因為他們可能不喜歡到此為止。
值得注意的是,可以對密碼進行加密,並且Web服務/服務器無法訪問解密密鑰。使用其他服務器的reset方法有幾種方法可以實現這種非對稱密鑰。存儲密鑰並用於加密/解密操作的HSM是另一種方法。當然,這兩種情況都不是。
@SteffenUllrich純文本違規者是我鏈接其他問題的原因
至少有可能不故意使用術語“哈希”和“加密/解密”,以免聽起來不太技術,而不是缺乏理解。他們只是使用非技術性讀者通常會理解的描述性術語。@43Tesseracts顯然知道他在說什麼,但是學校可能還沒有從他的電子郵件中得知這一點。
@AndrewLeach是真的。但是,加密密碼而不是哈希確實指向了另一個方向。
-1
@SteffenUllrich plaintextoffenders.com似乎已經死了,他們是否移動了,或者在其他地方有其他人在運行它(或類似網站)?
@ZN13還沒死,他們只是將格式切換為tumblr。
@SmokeDispenser的最新發布是2016年6月3日,也就是一年多前,一個月前。出現。網站上其他地方還有其他評論,詢問它是否已死。
MrZarq
2017-11-23 15:26:14 UTC
view on stackexchange narkive permalink

每個人都將重點放在加密與散列上,但是雖然這本身很不好,但我發現以下內容更加糟糕:

出於支持的原因,某些員工可以看到父密碼直到父母成功登錄3次為止。

您應該將其解釋為“ IT員工知道我的密碼”。他們公開承認某些職員可以知道您的密碼。這是很糟糕的。我假設您更改密碼後此計數器已重置,因此使用3次虛擬密碼然後將其更改為“真實”密碼將無濟於事。請勿在您不想公開的平台上放置任何東西,如果您在其他站點上使用了相同的密碼,請進行更改。

對每個站點使用隨機生成的密碼的另一個重要原因。
在登錄服務時,如何阻止IT人員攔截密碼?如果管理員需要,他們仍然可以提取您的密碼。我的意思是不管這3個瘋狂的登錄政策。
好吧,我認為密碼應該在客戶端進行哈希處理。您可以通過檢查發送到服務器的數據來驗證是否發生這種情況。
客戶端哈希可以完成什麼工作?無論您發送到服務器的是“真實”密碼,無論是“ password”還是“ 5f4dcc3b5aa765d61d8327deb882cf99”。
這意味著攔截器無法在其他站點上重複使用您的密碼(假設該網站使用了某種特定於該站點的鹽)。這與保護您在該站點上的帳戶無關,而是關於在所有其他站點上的保護。
客戶端上的哈希運算是否不會破壞存儲密碼哈希而不是存儲密碼本身的意義?如果攻擊者知道我的用戶名和密碼的哈希值,他們可以將其發送過來並訪問我的帳戶,而無需輸入密碼。
@akostadinov可以對該站點進行編程,以便在服務器處理請求的確切時間點複製密碼(除非使用適當的物理控制方法本身就可以防止複制),因此密碼不會放入日誌中,或者可以通過其他方式訪問。所有這些都要求您信任該站點以保護您的密碼,但是如果您不這樣做,我們還是會回到第一位。
@akostadinov是的,您必須信任該應用程序,並且工作人員不會以純文本格式記錄您的密碼。工作人員*告訴您*他們可以訪問純文本密碼的事實仍然破壞了這種信任。
@jpmc26`出於支持的原因,某些密碼對某些職員是可見的,直到父母成功登錄n次為止。`您能描述一下您對n的信心是n的函數(假設所有其他條件都不變)。從0、1、2、3、4、5,...開始,n真的重要嗎?
@emory我指的是這樣一個事實,無論有什麼保護措施,Web應用程序*總是*可以訪問純文本密碼。(即使您執行客戶端哈希處理,實際上也只是更改了密碼的值。)您必須相信Web應用程序不會將此信息記錄在某處。一旦他們告訴您可以訪問您的密碼,信任就降為零,但是我說的是,在某種程度上,沒有技術保護,信任是唯一的選擇。
@MrZarq感謝您的答复。這是很有趣的一點;我認為這是我第一次看到使用javascript有助於提高安全性,而沒有帶來任何漏洞。
John Deters
2017-11-23 03:46:17 UTC
view on stackexchange narkive permalink

不,正如您正確推測的那樣,此行為顯然是不安全的。

您可以而且應該做的是不信任他們的系統。請勿在學校系統上使用類似於銀行密碼或其他密碼的密碼。請不要輸入比讓孩子上學絕對需要的更多信息。如果您的孩子帶回家的紙條上寫著“登錄並更新您的信息”,請不要放任何您不願意透露的內容。

至少在他們的“未來”情況下,聽起來像是實現他們需要的行為以支持安全地哈希密碼;他們是否會真正安全地對密碼進行哈希處理(三個登錄後)而不是對密碼進行加密將是另一個問題。而且您將無法通過觀察回答該問題。如果您仍然擔心,可以聯繫軟件供應商,並詢問他們的工作方式。

“您可以而且應該做的就是不信任他們的系統。”這應該是您的默認狀態。假設所有網站都在濫用您的數據,並最大程度地減少了對它們的破壞。
“不要在學校系統上使用類似於銀行密碼或其他密碼的密碼”-聽起來很奇怪。如果某個陰暗的網站說“我們對密碼進行哈希處理,請保證!”你會做出“感謝上帝,我可以重用我的銀行密碼”的反應嗎?
@el.pescado,對我們來說可能顯而易見,但許多人從未想過。鑑於仍有大量成功的“帳戶接管”攻擊正在進行,因此很明顯仍需要此建議。
@JohnDeters我的意思是,該建議聽起來像是“不要在似乎沒有哈希密碼的網站上重複使用密碼”,而我認為應該是“不要重複使用密碼。期限”。
@el.pescado,我明白。我正嘗試為絕對始終使用密碼的普通人寫一個答案。我們實際上不希望改變這種情況,因此我們需要提供可能有所作為的答案。
很難正確地說出這句話。我使用密碼管理器,因此學校密碼恰好是銀行密碼的可能性很小,但大於零。密碼管理器除了強制執行概率外不會採取任何其他措施來強制密碼不同。
@emory,一個好的密碼管理器產生衝突的機會微不足道-很小,因此不值得討論。另一方面,錯誤的密碼生成器具有極大的風險,絕非偶然。
@JohnDeters我同意。“在學校系統上不要使用密碼之類的”字眼暗示了我不認為您的意思。我很難想到更好的單詞。
Machavity
2017-11-23 09:35:07 UTC
view on stackexchange narkive permalink
  1. 您不應假定您的密碼曾經是安全的。推薦使用密碼管理器

    是有原因的。事實是,在您自己嘗試處理所有這些密碼時,您將犯下的主要罪行重用一些。實際上,這比使用密碼管理器要冒險得多。如果使用此密碼的單個站點掉線,則使用該密碼的每個帳戶都會受到威脅。您需要記住所有重複使用該密碼的站點,然後將其全部更改。

  2. 推薦的重置方法是生成唯一密鑰,以供用戶在受TLS保護的網站上進行自己的重置。即使啟用了TLS,電子郵件仍然固有地不安全

    儘管TLS和SSL無疑為任何公司的數據安全方法奠定了至關重要的基礎,但仍有一些證據暗示它是一個帶有許多潛在漏洞的系統。

    主要的弱點是由於公司缺乏對如何加密電子郵件的了解,許多人認為傳輸渠道不明確,

  3. 散列與加密在本質上是不同的。 在堆棧溢出上進行了很好的研究

    [加密函數]在任意長度的輸入和輸出之間提供1:1映射。 而且它們始終是可逆的

    如SmokeDispenser所述,如果他們可以獲取數據庫,則可以獲取加密密鑰。這與散列有何不同?哈希始終為單向。數據進入,永不消失。換句話說,沒有鑰匙可以偷。

    在檢查輸入數據的有效性時,請使用哈希函數。這就是他們的目的。如果您有2個輸入,並且想要檢查它們是否相同,則通過哈希函數運行這兩個輸入。對於較小的輸入大小(假設哈希函數良好),發生碰撞的可能性在天文上較低。這就是為什麼建議使用密碼的原因。

    換句話說,您將密碼存儲在我的網站上。我用一個緩慢的東西(如bcrypt)反复地用一個隨機字符串(稱為salt)對其進行哈希處理。為了驗證您的身份,您再次輸入密碼,然後我將其洗完為止。使用相同的算法(再加上我多次運行,稱為成本),鹽和密碼,我應該獲得與存儲的相同的哈希值。因此,我不需要存儲可逆的加密或未加密的密碼。

  4. ol>
雖然我100%同意這是一個非常糟糕的系統,但我不確定我是否同意“如果他們可以獲取您的數據庫,他們可以獲取加密密鑰”。如果他們使用sql注入竊取了數據庫,那將使他們無法獲取加密密鑰(位於Web服務器中)。敏感數據必須可檢索的地方(即在這種情況下不是這樣),加密才有價值
碰撞的可能性不取決於輸入大小。它取決於輸入的數量,但我看不到它的相關性。
對於較小的輸入量,發生碰撞的可能性不僅在天文數字上較低,而且對於所有輸入(無論大小),碰撞的可能性也極低。唯一的例外是當使用已知有缺陷的哈希函數(例如MD5)時,發現衝突比聲稱的要容易得多。編輯:對不起,我知道我重複了以上評論
@RichardTingle-鑑於該系統的開發人員顯然遵循“最佳實踐”存在問題,因此我不希望他們不要使用將選擇明文或已知明文攻擊引入系統的方式進行加密(例如,使用ECB模式密碼)。
我同意(1)的第一部分,您不應假設自己的密碼是安全的。//唯一可以做的就是使系統相對更安全,而不是絕對安全。任何復雜的系統都將具有備份。使用脫機服務器,可以還原備份,然後由設計代碼和數據庫的團隊隨意操作。
gnasher729
2017-11-26 04:35:25 UTC
view on stackexchange narkive permalink

根據定義,如果密碼由您以外的其他人存儲,則該密碼不會安全存儲。無需存儲密碼。

如果IT人員出於正當理由在沒有您提供密碼的情況下訪問您的帳戶,則他們不需要將密碼存儲在某個地方。他們可以重設密碼,訪問您的帳戶,或將密碼替換為原始密碼。全部都不知道您的密碼。

如果他們可以將您的密碼發送給您,那麼他們可以將其發送給偽裝成您的人。因此,這是不安全的。

PS。他們絕對不需要存儲用於身份驗證的密碼。他們可以存儲一個加鹽的哈希,無法從中恢復密碼。這是標準做法。他們如何將其發送給假裝為您的人?這就是所謂的社會工程學。有人打來電話,說服他們是您,並且您的電子郵件地址已更改,然後他們將密碼發送給錯誤的人。

“發送”給您意味著自動化系統。SocEng繞過此系統。您將不平等的過程等同起來。同樣,語義,但是有點混亂。


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