security - with - password hash php




我應該如何以道德方式處理用戶密碼存儲以便以後進行明文檢索? (18)

Securing credentials is not a binary operation: secure/not secure. Security is all about risk assessment and is measured on a continuum. Security fanatics hate to think this way, but the ugly truth is that nothing is perfectly secure. Hashed passwords with stringent password requirements, DNA samples, and retina scans are more secure but at a cost of development and user experience. Plaintext passwords are far less secure but are cheaper to implement (but should be avoided). At end of the day, it comes down to a cost/benefit analysis of a breach. You implement security based on the value of the data being secured and its time-value.

What is the cost of someone's password getting out into the wild? What is the cost of impersonation in the given system? To the FBI computers, the cost could be enormous. To Bob's one-off five-page website, the cost could be negligible. A professional provides options to their customers and, when it comes to security, lays out the advantages and risks of any implementation. This is doubly so if the client requests something that could put them at risk because of failing to heed industry standards. If a client specifically requests two-way encryption, I would ensure you document your objections but that should not stop you from implementing in the best way you know. At the end of the day, it is the client's money. Yes, you should push for using one-way hashes but to say that is absolutely the only choice and anything else is unethical is utter nonsense.

If you are storing passwords with two-way encryption, security all comes down to key management. Windows provides mechanisms to restrict access to certificates private keys to administrative accounts and with passwords. If you are hosting on other platform's, you would need to see what options you have available on those. As others have suggested, you can use asymmetric encryption.

There is no law (neither the Data Protection Act in the UK) of which I'm aware that states specifically that passwords must be stored using one-way hashes. The only requirement in any of these laws is simply that reasonable steps are taken for security. If access to the database is restricted, even plaintext passwords can qualify legally under such a restriction.

但是,這確實帶來了另一個方面:法律優先。如果法律優先權表明您必須使用您的系統所在行業的單向哈希值,那麼這完全不同。那是你用來說服你的顧客的彈藥。除此之外,提供合理風險評估的最佳建議,記錄您的異議並以最安全的方式實施系統,以滿足客戶的要求。

隨著我繼續構建越來越多的網站和Web應用程序,我經常被要求存儲用戶密碼,以便在用戶遇到問題時可以檢索用戶密碼(通過電子郵件發送已忘記的密碼鏈接,電話等)當我可以為這種做法而苦澀的時候,我會做很多“額外的”編程來使密碼重置和管理協助成為可能,而不需要存儲他們的實際密碼。

當我無法與它戰鬥(或不能贏)時,我總是以某種方式對密碼進行編碼,以至於它至少不會作為明文存儲在數據庫中 - 儘管我知道如果我的數據庫被黑客入侵對於破解密碼的罪魁禍首並不多,所以這讓我感到不舒服。

在一個完美的世界裡,人們會經常更新密碼,而不是在許多不同的網站上複製密碼 - 不幸的是,我知道很多人擁有相同的工作/家庭/電子郵件/銀行密碼,並且甚至在他們需要幫助時可以自由地給我。 如果我的數據庫安全程序出於某種原因失敗,我不想成為他們財務危機的責任人。

在道德和倫理方面,我認為對於一些用戶保護他們的生計負有責任,即使他們以更少的尊重對待他們。 我確信有很多方法可以用來處理醃製散列和不同的編碼選項,但是當你需要存儲它們時,是否有一個“最佳實踐”? 幾乎在所有情況下,我都使用PHP和MySQL,如果這樣做會影響我處理細節的方式。

附加信息賞金

我想澄清一點,我知道這不是你想要做的事情,並且在大多數情況下拒絕這樣做是最好的。 然而,我不想尋求採用這種方法的優點,我正在尋找採取這種方法的最佳步驟。

在下面的一個註釋中,我指出,當被要求執行安全密碼恢復程序時,主要針對老年人,精神障礙者或非常年輕的網站可能會讓人感到困惑。 儘管在這些情況下我們可能會發現它簡單而平凡,但有些用戶需要獲得服務技術人員幫助他們進入系統或通過電子郵件直接發送給他們的額外幫助。

在這樣的系統中,如果用戶沒有獲得這種級別的訪問幫助,那麼這些人口統計數據中的損耗率可能會使應用程序陷於癱瘓,所以請回答一下這樣的設置。

謝謝大家

這是一個很有趣的問題,有很多爭論,我很喜歡它。 最後,我選擇了一個答案,既保留密碼安全性(我將不必保持純文本或可恢復的密碼),而且還可以讓我指定的用戶群登錄系統,而沒有發現從我發現的主要缺點正常的密碼恢復。

和往常一樣,我希望有5個答案因為不同的原因被標記為正確,但我必須選擇最好的答案 - 其餘的答案都是+1。 感謝大家!

此外,感謝Stack社區中的每個人都投票贊成此問題並/或將其標記為最愛。 我以100票贊成作為恭維,並希望這次討論能夠幫助其他人以我的同樣關切。


不要放棄。 你可以用來說服你的客戶的武器是不可否認的。 如果您可以通過任何機制重建用戶密碼,您已經為其客戶提供了合法的不可否認機制,並且可以否認依賴該密碼的任何交易,因為供應商無法證明他們沒有重建密碼並通過他們自己完成交易。 如果密碼被正確存儲為摘要而不是密文,那麼這是不可能的,無論是最終客戶自己執行交易還是違背了密碼的注意義務。 在任何一種情況下,都會使他承擔責任。 我已經研究過那些數額達數億美元的案例。 不是你想錯的東西。


你可以使用公鑰加密密碼+鹽。 對於登錄,只需檢查存儲的值是否等於從用戶輸入+ salt計算出的值。 如果有一段時間,當密碼需要以明文恢復時,您可以使用私鑰手動或半自動解密。 私鑰可以被存儲在其他地方並且可以被對稱地加密(然後需要人工交互來解密密碼)。

我認為這實際上類似於Windows恢復代理的工作方式。

  • 密碼被加密存儲
  • 人們可以在不解密的情況下登錄到純文本
  • 密碼可以恢復為純文本,但只能使用私鑰,可以存儲在系統外部(如果需要,可以在銀行保險箱中)。

允許用戶檢索其原始密碼的唯一方法是使用用戶自己的公鑰對其進行加密。 只有該用戶才能解密他們的密碼。

所以這些步驟將是:

  1. 用戶在您的網站上註冊(當然是通過SSL),無需設置密碼。 自動登錄或提供臨時密碼。
  2. 您提供存儲其公共PGP密鑰以供將來密碼檢索。
  3. 他們上傳他們的公共PGP密鑰。
  4. 你要求他們設置一個新密碼。
  5. 他們提交他們的密碼。
  6. 您可以使用可用的最佳密碼哈希算法(例如bcrypt)來哈希密碼。 驗證下一次登錄時使用此項。
  7. 您使用公鑰對密碼進行加密,並將其單獨存儲。

如果用戶要求輸入密碼,則使用加密(而非散列)密碼進行響應。 如果用戶不希望將來能夠檢索自己的密碼(他們只能將其重置為服務生成的密碼),則可以跳過步驟3和7。


在獨立服務器上打開數據庫,並為需要此功能的每個Web服務器提供加密的遠程連接。
它不一定是關係數據庫,它可以是一個具有FTP訪問權限的文件系統,使用文件夾和文件而不是表格和行。
如果可以的話,為Web服務器提供只寫權限。

在網站的數據庫中存儲不可檢索的密碼加密(讓我們稱之為“pass-a”),就像普通人一樣:)
對每個新用戶(或密碼更改)在遠程數據庫中存儲密碼的普通副本。 使用服務器的ID,用戶的ID和“pass-a”作為該密碼的組合鍵。 您甚至可以在密碼上使用雙向加密,以在夜間更好地睡眠。

現在為了讓某人獲得密碼和它的上下文(網站ID +用戶ID +“pass-a”),他必須:

  1. 攻擊該網站的數據庫以獲得(“pass-a”,用戶id)配對。
  2. 從某個配置文件中獲取該網站的ID
  3. 找到併入侵遠程密碼數據庫。

您可以控制密碼檢索服務的可訪問性(僅將其作為安全Web服務公開,僅允許每天檢索一定數量的密碼,手動執行等),甚至可以為此“特殊安全安排”收取額外費用。
密碼檢索數據庫服務器相當隱蔽,因為它不提供許多功能,並且可以更好地保護(您可以嚴格地調整權限,流程和服務)。

總而言之,你讓黑客更加努力工作。 在任何一台服務器上發生安全漏洞的可能性仍然相同,但有意義的數據(帳戶和密碼匹配)很難組裝。


在這個問題上採取另一種方法或角度怎麼樣? 詢問為什麼密碼需要以明文形式存在:如果用戶可以檢索密碼,那麼嚴格來說你並不需要檢索他們設置的密碼(他們不記得它是什麼),你需要能夠給他們一個他們可以使用的密碼。

想一想:如果用戶需要檢索密碼,那是因為他們已經忘記了密碼。 在這種情況下,新密碼與舊密碼一樣好。 但是,現在使用的通用密碼重置機制的缺點之一是在重置操作中產生的生成密碼通常是一串隨機字符,因此用戶難以正確輸入,除非他們複製n-糊。 這對於不那麼聰明的計算機用戶來說可能是個問題。

解決這個問題的一個方法是提供自動生成的密碼,它們或多或少是自然語言文本。 雖然自然語言字符串可能不具有長度相同的隨機字符串的熵,但沒有任何說自動生成的密碼只需要8個(或10或12個)字符。 通過將幾個隨機單詞串聯起來獲得一個高熵自動生成的密碼短語(在它們之間留下一個空格,這樣它們仍然可以被任何可以閱讀的人識別和鍵入)。 六個不同長度的隨機單詞可能比10個隨機字符更容易正確和自信地輸入,並且它們也可以具有更高的熵。 例如,從大寫,小寫,數字和10個標點符號(總共72個有效符號)中隨機抽取的10個字符的密碼的熵將具有61.7比特的熵。 使用7776字(作為Diceware使用)的字典可以隨機選擇一個六字密碼,密碼將有一個77.4位的熵。 有關更多信息,請參閱Diceware常見問題解答

  • 一個約77位熵的密碼:“承認散文表格急性風格”

  • 一個包含約74位熵的密碼:“K:&$ R ^ tt〜qkD”

我知道我更喜歡輸入這個短語,並且使用複制粘貼,這個短語不難輕易使用密碼,所以在那裡不會有任何損失。 當然,如果您的網站(或任何受保護的資產)不需要77位熵來生成自動生成的密碼短語,則可以生成更少的單詞(我相信您的用戶會喜歡)。

我了解有密碼保護資產的論據,這些資產確實沒有高價值,所以違反密碼可能不是世界末日。 例如,如果我在各種網站上使用的密碼中有80%被違反,我可能不會在意:所有可能發生的情況都是一些垃圾郵件或以我的名字發布一段時間。 這不會很好,但它不像他們會闖入我的銀行賬戶。 但是,鑑於很多人在他們的網站論壇網站上使用的密碼與他們的銀行帳戶(可能是國家安全數據庫)使用相同的密碼,我認為最好是將那些“低價值”密碼處理為非-recoverable。


如果你不能僅僅拒絕存儲可恢復密碼的要求,那麼作為你的反駁論點呢。

我們可以正確地散列密碼並為用戶構建重置機制,或者我們可以從系統中刪除所有個人身份信息。 您可以使用電子郵件地址來設置用戶首選項,但就是這樣。 使用cookie自動調整未來訪問的偏好,並在合理的時間段後丟棄數據。

密碼策略經常被忽視的一個選項是密碼是否真的需要。 如果您的密碼政策唯一的作用是引起客戶服務電話,也許您可以將其清除。


將用戶安全問題的答案作為加密密鑰的一部分,並且不要將安全問題答案存儲為純文本(取而代之)


從我對這個主題的理解很少,我相信如果你正在建立一個帶有登錄/密碼的網站,那麼你甚至都不應該在你的服務器上看到明文密碼。 在密碼離開客戶端之前,密碼應該被散列並且可能被醃製。

如果您從未看到明文密碼,則不會出現檢索問題。

另外,我從網上收集到(據稱)一些算法,如MD5,不再被認為是安全的。 我無法判斷我自己,但這是需要考慮的事情。


您不能道德地存儲密碼以供以後的明文檢索。 就這麼簡單。 即使喬恩Skeet不能道德地存儲密碼為以後的明文檢索。 如果您的用戶可以以某種方式或以其他方式以純文本方式檢索密碼,那麼黑客在您的代碼中可能會發現安全漏洞。 這不僅僅是一個用戶的密碼被洩露,而是所有這些。

如果您的客戶遇到問題,請告訴他們可以通過密碼進行存儲是違法的。 在英國,無論如何,1998年的“數據保護法”(特別是附錄1第二部分第9段)要求數據控制人員採用適當的技術措施保證個人數據的安全,同時考慮到如果數據遭到破壞可能會造成危害 - 這對於在站點間共享密碼的用戶可能相當可觀。 如果他們在處理這個問題時仍然有困難,請將它們指向一些真實世界的例子,比如這個例子。

允許用戶恢復登錄的最簡單方法是通過電子郵件向他們發送一次性鏈接,使其自動登錄並將其直接帶到可選擇新密碼的頁面。 創建一個原型並將其展示給他們。

這裡有幾篇關於這個主題的博文:

更新:我們現在開始看到針對未能妥善保護用戶密碼的公司提起訴訟和起訴。 例如: LinkedIn打擊了500萬美元的集體訴訟 ; 索尼被PlayStation數據破解罰款25萬英鎊 。 如果我沒有記錯,LinkedIn實際上是在加密其用戶的密碼,但它使用的加密功能太弱而無法生效。


我實現了多重身份驗證系統,因此對我來說,認為您可以重置或重建密碼是很自然的事情,而臨時只使用一個較少的因素來驗證用戶的身份,只需重置/重建工作流程即可。 特別是使用OTP(一次性密碼)作為一些附加因素,可以在建議工作流程的時間窗口較短時減輕大部分風險。 我們已經實施了用於智能手機的軟件OTP生成器(大多數用戶已經整天攜帶自己),取得了巨大的成功。 在投訴出現商業插件之前,我所說的是我們可以降低密碼容易檢索或重置的固有風險,因為它們不是用於驗證用戶身份的唯一因素。 我承認,對於站點場景中的密碼重用,情況仍然不是很好,因為用戶會堅持使用原始密碼,因為他/她也想打開其他站點,但是您可以嘗試將重建的密碼最安全的方式(在HTML上htpps和謹慎的外觀)。


我有同樣的問題。 同樣的,我總是認為有人破解我的系統,這不是“如果”而是“何時”的問題。

所以,當我必須做一個需要存儲可恢復的機密信息(如信用卡或密碼)的網站時,我所做的是:

  • 使用以下命令進行加密: openssl_encrypt (string $ data,string $ method,string $ password)
  • 數據參數
    • 敏感信息(例如用戶密碼)
    • 如果需要序列化,例如,如果信息是像多個敏感信息那樣的數據陣列
  • 密碼參數 :使用只有用戶知道的信息:
    • 用戶牌照
    • 社會安全號碼
    • 用戶電話號碼
    • 用戶母親的名字
    • 隨機字符串通過電子郵件和/或在註冊時由短信發送
  • 方法arg
    • 選擇一種密碼方法,如“aes-256-cbc”
  • 切勿將數據庫中的“密碼”參數中使用的信息(或系統中的任何位置)

當需要檢索這些數據時,只需使用“openssl_decrypt()”函數並詢問用戶的答案。 例如: “要接收密碼,請回答問題:您的手機號碼是什麼?”

PS 1 :從不使用存儲在數據庫中的數據作為密碼。 如果您需要存儲用戶手機號碼,則請勿使用此信息對數據進行編碼。 始終使用只有用戶知道的信息,或者知道某個非親屬很難。

PS 2 :對於信用卡信息,如“一鍵購買”,我所做的就是使用登錄密碼。 該密碼在數據庫(sha1,md5等)中散列化,但在登錄時,我將純文本密碼存儲在會話中或存儲在非持久性(即內存)安全cookie中。 這個普通的密碼永遠不會留在數據庫中,實際上它始終保留在內存中,在部分末尾被銷毀。 當用戶點擊“一鍵購買”按鈕時,系統使用該密碼。 If the user was logged in with a service like facebook, twitter, etc, then I prompt the password again at buying time (ok, it's not a fully "on click") or then use some data of the service that user used to login (like the facebook id).


根據我就這個問題發表的評論:
重要的一點幾乎每個人都掩蓋了......我最初的反應非常類似於@邁克爾布魯克斯,直到我意識到,像@stefanw一樣,這裡的問題違反了要求,但這些都是他們的要求。
但是,那對我來說可能並非如此! 這裡缺少的一點是應用程序資產的潛在價值 。 簡而言之,對於一個低價值的系統來說,一個完全安全的認證機制,包括所有的過程,將會是過度的,也是錯誤的安全選擇。
顯然,對於一家銀行來說,“最佳實踐”是必須的,而且沒有辦法從倫理上違反CWE-257。 但很容易想到低價值的系統,它不值得(但仍需要一個簡單的密碼)。

重要的是要記住,真正的安全專業知識是在尋找適當的權衡,而不是在教條中吐出任何人都可以在線閱讀的“最佳實踐”。

因此,我建議另一個解決方案:
取決於系統的價值,並且只有當系統適當的低價值且沒有“昂貴”的資產(身份本身,包括在內)時, 並且存在有效的業務需求,這使得正確的過程變得不可能(或者足夠困難/昂貴) ,而客戶意識到所有的注意事項...
那麼簡單地允許可逆加密是合適的,沒有特殊的箍環可以跳過。
我不想說加密就根本不用說,因為它的實現非常簡單/便宜(甚至考慮可通過密鑰管理),並且它提供了一些保護(比實現它更多的成本)。 此外,它的價值在於如何向用戶提供原始密碼,無論是通過電子郵件,在屏幕上顯示等。
由於這裡的假設是被盜密碼的價值(即使是合計)非常低,所以這些解決方案都可以是有效的。

由於正在進行熱烈的討論,實際上幾個活躍的討論,在不同的帖子和單獨的評論主題中,我會補充一些說明,並回應一些在此提到的非常好的觀點。

首先,我想這裡的每個人都很清楚,允許用戶的原始密碼被檢索出來,是壞習慣,而且通常不是一個好主意。 這完全沒有爭議......
此外,我會強調,在很多情況下,不管怎樣,情況 - 這確實是錯誤的,甚至是犯規,討厭和醜陋

然而,問題的關鍵在於原則 ,是否存在可能不需要禁止這種情況的情況 ,如果是這樣,那麼如何以適合於該情況最正確的方式來做到這一點。

現在,正如@Thomas,@sfussenegger和其他幾位提到的那樣,回答這個問題的唯一正確方法就是對任何給定的(或假設的)情況進行徹底的風險分析 ,了解受到什麼危害 ,保護多少值得,還有哪些緩解措施可以起到保護作用。
不,它不是流行詞,這是真實安全專家的基本,最重要的工具之一。 最佳實踐很好(通常作為缺乏經驗和黑客的指導方針),在此之後進行深思熟慮的風險分析。

你知道,這很有趣 - 我一直認為自己是安全狂的一員,不知何故,我處於那些所謂的“安全專家”的另一面......呃,事實是 - 因為我是一個狂熱的人,和一位真實的現實安全專家 - 我不相信在沒有那麼重要的風險分析的情況下發布 “最佳實踐”教條(或CWE)。
“要小心安全狂,他可以迅速將所有東西都應用到他們的工具帶中,而不必知道他們正在防禦的實際問題是什麼,更多的安全性並不一定等同於良好的安全性。”
風險分析和真正的安全狂熱者會根據風險,潛在損失,可能的威脅,補充緩解措施等指向更明智的,基於價值/風險的折衷。任何不能指出聲音風險分析的“安全專家”他們建議的基礎,或支持邏輯權衡,但寧可吹噓教條和CWE,甚至沒有理解如何進行風險分析,都沒有,但安全黑客,他們的專業知識是不值得他們打印它的衛生紙。

事實上,這就是我們如何得到機場安全的荒謬。

但在我們討論在這種情況下做出適當的權衡之前,讓我們來看看明顯的風險(很明顯,因為我們沒有關於這種情況的所有背景信息,我們都假設 - 因為問題是假設可能會有......的情況)
讓我們假設一個LOW-VALUE系統,但不是那麼複雜以至於它是公共訪問 - 系統所有者想要防止偶然模仿,但“高”安全性不像易用性那樣重要。 (是的,這是一個合理的權衡,以接受任何熟練的腳本小子可以入侵網站的風險......等等,現在不是流行的APT ......?)
舉個例子,假設我正在為一個大型家庭聚會安排一個簡單的網站,讓大家在今年我們想去的露營之旅上集思廣益。 我不那麼擔心一些匿名黑客,或者甚至表弟弗雷德一再提出建議,要回到Lake Wantanamanabikiliki湖,因為我是關於Erma阿姨無法在需要時登錄的。 現在,作為核物理學家的埃爾瑪嬸嬸在記憶密碼,甚至根本不使用計算機方面都不是很擅長......所以我想消除她所有可能的摩擦。 再次,我不擔心黑客,我只是不想要錯誤的登錄愚蠢的錯誤 - 我想知道誰來,什麼他們想要的。

無論如何。
那麼,如果我們對密碼進行對稱加密,而不是使用單向散列,那麼我們的主要風險是什麼?

  • 冒充用戶? 不,我已經接受了這個風險,沒有意思。
  • 邪惡的管理員? 好吧,也許...但是,再次,我不在乎是否有人可以冒充另一個用戶,INTERNAL或不... ...無論如何,無論如何,惡意管理員都會得到您的密碼 - 如果您的管理員失敗了,它的遊戲無論如何。
  • 另一個被提出的問題是,身份實際上是在幾個系統之間共享的。 啊! 這是一個非常有趣的風險,需要仔細觀察。
    讓我首先斷言它不是共享的實際身份 ,而是證明或身份驗證憑證。 好吧,由於共享密碼將有效地允許我進入另一個系統(比如我的銀行帳戶或gmail),這實際上是同一個身份,所以它只是語義......除了它不是 。 在這種情況下,身份由每個系統單獨管理(雖然可能會有第三方ID系統,比如OAuth - 仍然與本系統中的身份分離 - 稍後會有更多介紹)。
    因此,這裡的風險核心是用戶願意將他的(相同)密碼輸入到幾個不同的系統中 - 現在,我(管理員)或我的網站的任何其他黑客都可以訪問Erma阿姨的密碼核導彈現場。

嗯。

這裡有什麼似乎對你沒有好處?

這應該。

讓我們從保護核導彈系統不是我的責任開始 ,我只是建立一個frakkin家庭郊遊網站(對於我的家人)。 那麼誰的責任呢? 呃...核導彈系統呢? 咄。
其次,如果我想竊取某人的密碼(知道在安全站點之間重複使用相同密碼的人,以及不那麼安全的站點),為什麼我會打擾黑客攻擊您的站點? 還是與你的對稱加密掙扎? Goshdarnitall,我可以建立我自己的簡單網站 ,讓用戶註冊接收非常重要的新聞,無論他們想要什麼......普福普雷斯托,我“偷走了”他們的密碼。

是的,用戶教育總是會回來咬我們在hienie,不是嗎?
而且你無法做到這一點...即使你想在你的網站上密碼,並且做了TSA可以想到的所有其他事情,你也可以加密保護他們的密碼NOT ONE WHIT ,如果他們要保留將密碼混雜在他們遇到的每個站點中。 不要偶爾打擾嘗試。

換句話說, 你不擁有自己的密碼 ,所以不要像你那樣行事。

所以,我的親愛的安全專家,作為一個曾經要求溫迪的老太太,“哪裡有風險?”

還有幾點要回答上面提出的一些問題:

  • CWE不是法律,法規,甚至是標準。 它是一個共同的弱點 ,即“最佳實踐”的反面。
  • 共享身份的問題是一個實際問題,但在這裡被反對者誤解(或歪曲)。 這是一個共享身份本身(!)的問題,而不是破解低價值系統上的密碼。 如果您在低價值系統和高價值系統之間共享密碼,問題已經存在!
  • 由此,以前的觀點實際上會指出,對這些低價值系統和高價值銀行系統使用OAuth等都是不贊同的
  • 我知道這僅僅是一個例子,但是(可悲的是)FBI系統並不是最安全的。 不像你貓的博客服務器,但它們也不會超過一些更安全的銀行。
  • 對加密密鑰的分裂知識或雙重控制不會發生在軍事上,事實上PCI-DSS現在基本上要求所有商家都這樣做,所以它現在不再那麼實際(如果值得說明的話)。
  • 對於那些抱怨這樣的問題讓開發人員職業看起來很糟糕的人來說:這些答案就是這樣,這會讓安全行業看起來更糟糕。 再次,以業務為中心的風險分析是必需的,否則你會使自己無用。 除了錯誤之外。
  • 我想這就是為什麼不聘請一個普通的開發人員並將更多的安全責任放在他身上,而沒有經過訓練思考不同,並尋找正確的權衡。 沒有冒犯,對於你們這些人來說,我都是為了它 - 但是更多的訓練是為了。

呼。 多長的帖子...
但要回答你原來的問題,@Shane:

  • 向客戶解釋做事的正確方法。
  • 如果他仍然堅持,請多說一些,堅持,爭辯。 如果需要,投擲發脾氣。
  • 向他解釋業務風險。 細節是好的,數字更好,現場演示通常是最好的。
  • 如果他仍然堅持,並提出有效的商業理由 - 現在是您做判斷的時候了:
    這個網站是低價值嗎? 這真的是一個有效的商業案例嗎? 對你來說足夠好嗎? 是否沒有其他風險可以考慮,這會超過有效的商業原因? (當然,客戶端不是一個惡意網站,但那是呃)。
    如果是這樣,就直接前進。 這是不值得的努力,摩擦和失去使用(在這種假設的情況下),以實現必要的過程。 任何其他決定(再次,在這種情況下)是一個壞的折衷。

因此,底線和實際答案 - 使用簡單的對稱算法對其進行加密,使用強ACL和最好是DPAPI或類似方法保護加密密鑰,將其記錄下來並讓客戶(有足夠資深的客戶做出該決定)簽名它。


正常使用用戶密碼。 在登錄用戶時,同時允許用戶的密碼(salting / hashing後),但也允許用戶輸入的內容與之匹配。

這允許用戶輸入他們的密碼,但也允許他們輸入密碼的醃製/散列版本,這是人們從數據庫中讀取的。

基本上,使醃/哈希密碼也是一個“純文本”密碼。


處理丟失/遺忘的密碼:

沒有人應該能夠恢復密碼。

如果用戶忘記了密碼,他們至少必須知道他們的用戶名或電子郵件地址。 根據請求,在用戶表中生成一個GUID,並發送一封電子郵件,其中包含一個包含guid的鏈接作為用戶電子郵件地址的參數。

鏈接後面的頁面驗證參數guid確實存在(可能有一些超時邏輯),並要求用戶輸入新密碼。

如果您需要熱線幫助用戶,請向您的授予模型添加一些角色,並允許熱線角色以識別的用戶身份臨時登錄。 記錄所有此類熱線登錄。 例如,Bugzilla為管理員提供了這種模擬功能。


邁克爾布魯克斯一直對CWE-257抱有很高的評價 - 無論你使用什麼方法,你(管理員)都可以恢復密碼。 那麼這些選項如何:

  1. 別人的公鑰加密密碼 - 一些外部權限。 這樣你就不能親自重建它,用戶將不得不去找那個外部權限並要求恢復他們的密碼。
  2. 使用從第二個密碼生成的密鑰加密密碼。 在客戶端執行此加密操作,並且絕對不要將其傳輸到服務器。 然後,為了恢復,再次通過從其輸入中重新生成密鑰來執行解密客戶端。 無可否認,這種方法基本上是使用第二個密碼,但您始終可以告訴他們寫下來,或使用舊的安全問題方法。

我認為1.是更好的選擇,因為它使您能夠指定客戶公司內的某個人持有私鑰。 確保他們自己生成密鑰,並將它們與指令一起保存在安全的地方等等。你甚至可以通過選擇只加密和提供密碼中的某些字符給內部第三方來增加安全性,這樣他們就不得不破解密碼來猜測它。 提供這些字符給用戶,他們可能會記得它是什麼!


閱讀完這部分內容後:

在下面的一個註釋中,我指出,當被要求執行安全密碼恢復程序時,主要針對老年人,精神障礙者或非常年輕的網站可能會讓人感到困惑。 儘管在這些情況下我們可能會發現它簡單而平凡,但有些用戶需要獲得服務技術人員幫助他們進入系統或通過電子郵件直接發送給他們的額外幫助。

在這樣的系統中,如果用戶沒有獲得這種級別的訪問幫助,這些人口統計數據中的損耗率可能會讓應用程序陷於癱瘓,所以請記住這樣的設置。

我還想知道這些要求中的任何一個是否要求可檢索的密碼系統。 例如:Mabel阿姨打電話說:“你的互聯網程序不能工作,我不知道我的密碼”。 “OK”表示客服無人機“讓我查看一些細節,然後我會給你一個新的密碼 。當你下次登錄時,它會問你是否要保留密碼或將它改為你能記得的東西更容易“。

然後系統設置為知道何時發生密碼重置並顯示“您想保留新密碼還是選擇新密碼”消息。

這種情況如何比被告知舊密碼的人更少? 雖然客戶服務人員可以搗蛋,但數據庫本身在被破壞的情況下更安全。

評論我的建議有什麼不好,我會建議一個解決方案,它實際上做你最初想要的。


您可能沒有考慮過的另一個選項是通過電子郵件進行操作。 這有點麻煩,但是我為一個客戶端實現了這一點,它需要用戶在系統外“查看”(只讀)系統的某些部分。 例如:

  1. 一旦用戶註冊,他們就可以完全訪問(像普通網站一樣)。 註冊必須包含電子郵件。
  2. 如果需要數據或操作並且用戶不記得他們的密碼,他們仍然可以通過點擊常規“ 提交 ”按鈕旁邊的特殊“ 給我發電子郵件許可 ”按鈕來執行操作。
  3. 該請求然後通過超鏈接發送給電子郵件,詢問他們是否希望執行該操作。 這與密碼重置電子郵件鏈接類似,但不是重置密碼,而是執行一次性操作
  4. 然後,用戶點擊“是”,確認應該顯示數據,或執行操作,顯示數據等。

正如你在評論中提到的那樣,如果電子郵件遭到入侵,這將不起作用,但它確實解決了@joachim關於不想重置密碼的評論。 最終,他們將不得不使用密碼重置,但他們可以在更方便的時間,或者在管理員或朋友的協助下,根據需要進行重置。

這種解決方案的一個轉折是將操作請求發送給第三方可信管理員。 這對老年人,精神障礙者,年輕人或其他困惑的用戶來說效果最好。 當然這需要這些人的可信管理員來支持他們的行動。





password-storage