2009-09-12 76 views
0

這裏的情況 - 從其他數據庫/密碼問題它有點不同的StackOverflow.com建議在數據庫中存儲的密碼

我有兩套用戶。一個是「主要」用戶。其他人是「次要」用戶。每個人都有我的網站的登錄名/密碼(比如mysite.com - 這不重要)。

背景:主要用戶可以訪問第三個站點(比如www.something.com/PrimaryUser1)。每個輔助用戶「屬於」主要用戶,並且希望訪問該其他站點的子部分(比如www.something.com/PrimaryUser1/SecondaryUser1)。

在mysite.com上,主要用戶必須向我提供他們的憑證,他們用它來訪問www.something.com/PrimaryUser1,並指定他們選擇的次要用戶可以訪問哪些「子部分」。

Mysite.com幫助管理輔助用戶對主用戶站點的子訪問。次要用戶不能「看到」他們的主要用戶的密碼,但通過我的網站,他們可以訪問其他站點的「子部分」 - 但只能訪問其受限制的子部分。

粗略地說,我實現了OAuth(或類似的東西)。

這裏的問題是 - 我應該如何將主用戶的憑據存儲到其他網站?這裏的關鍵是mysite.com使用這些憑證來提供對二級用戶的訪問,所以它必須能夠讀取它。但是,我希望以這種方式存儲它,主要用戶可以放心,我(作爲網站所有者)無法讀取其憑據。

我想這是更多的理論方法問題。密碼學領域有什麼可以幫助我呢?


文補充說:

由於大多數脂肪酶完全缺失的問題,這裏的嘗試#2在解釋它。

PrimaryUser1有一個用戶名/密碼www.something.com/PrimaryUser1Site

他希望給分獲得兩項以人爲SecondaryUser1和SecondaryUser2到文件夾 - www.something.com/PrimaryUser1Site/SecondaryUser1和www.something.com/PrimaryUser1Site/SecondaryUser2

Mysite.com負責此子用戶管理,因此PrimaryUser1會去那裏並向Mysite.com提供他的憑據。 MySite.com內部使用PrimaryUser1提供的憑據爲子用戶提供有限的訪問權限。現在,SecondaryUser1和SecondaryUser2可以通過MySite.com訪問www.something.com/PrimaryUser1Site上的各自文件夾。現在,問題出現了,我應該如何存儲PrimaryUser1提供的憑證?

回答

1

這取決於您的主站點和輔助站點達成一致的身份驗證類型。它是表單身份驗證,HTTP基本還是HTTP摘要?如果是表格或者基本的話你別無選擇,你需要存儲密碼,所以你唯一的選擇就是加密它。您無法存儲密碼哈希,因爲您必須在對錶單和HTTP Basic進行身份驗證時顯示明文。存儲加密密碼產生的問題是由於密碼學使用不正確(即,您不使用IV或鹽,或者您沒有正確使用流密碼),但更重要的是,您將擁有密鑰管理問題(在哪裏存儲用於加密密碼的密鑰以及如何從非交互式服務/惡魔訪問它)。因爲您可以構建直接從HA1開始的摘要響應,所以您可以存儲摘要哈希的HA1 hash部分(即,username:realm:password的MD5)。如果第三方站點接受HTTP摘要,那麼您運氣更好。

我沒有解決用戶如何提供輔助憑證(即如何獲得輔助站點用戶名和密碼),我假設您已獲得受保護的通道(即從客戶端到您的主要HTTPS現場)。

順便說一句,這假設身份驗證發生在主站點和輔助站點之間,並且輔助站點內容通過對主站點發出的HTTP請求進行隧道傳輸。如果情況並非如此,並且輔助站點實際上是直接從瀏覽器訪問的,則輔助站點必須支持第三方(如OAuth)的某種預先認證令牌的授權。當瀏覽器真正需要證書時,憑藉憑證認證並將證書存儲在主站點上有許多問題甚至不值得討論。

0

你有沒有想過接受像Stack Overflow這樣的OpenID?這樣你根本就不負責存儲密碼。

+0

我確實需要主用戶爲第三方站點提供密碼。 – Steve 2009-09-12 13:36:57

0

有得到了一個更好的辦法來解釋這個:(

,但如果你只是想知道如何存儲密碼的安全做到這一點:

用戶名:約翰,密碼:通過

鍵= '!! @ ijs09789 ** & *';

MD5(username.password.key);

登錄時只需要檢查如果md5(username.password.key)=等於db中的那個 - 你也可以使用sha1和/或任何其他加密方法。

http://us.php.net/md5 & http://us.php.net/sha1

+1

MD5已損壞 - 請勿使用它。同樣,你應該對哈希進行醃製,以便如果兩個人擁有相同的密碼,則通過查看哈希值無法判斷。 – 2009-09-12 13:31:51

+0

儘管使用大寫的用戶名,否則用戶名將區分大小寫。 – 2009-09-12 13:32:09

+0

嗨。這個答案沒有解決我有的問題。據我瞭解,我必須以ME可讀的格式存儲PrimaryUser的密碼,以便我可以在他登錄時授予SecondaryUser訪問權。 – Steve 2009-09-12 13:35:54

0

只有一個做到這一點的方式,它可能是太burdomesome的用戶。

您可以使用公鑰/私鑰加密用戶密碼,用戶保留其密鑰,以便只有在密鑰被提交回服務器時才能加密密碼。使這個簡單的唯一方法是使用一些自動提交信息的Web瀏覽器插件。

無論如何,你總是可以嗅探到/從服務器的通信,所以它仍然是毫無意義的。

0

如果您想自己存儲密碼,最好的方法是使用單向哈希算法,如MD5或SHA-1。這種方法的優點是不能從散列值中派生密碼。

準確選擇哪種算法取決於您使用的精確產品。一些前端工具提供這些功能,就像一些數據庫產品一樣。否則,你需要一個第三方庫。

編輯

次級用戶應該有自己的passowrds。他們爲什麼不呢?

0

從不在數​​據庫中存儲密碼,但存儲鹽漬和散列版本的每個密碼。

檢查此article如果這是中國給你。

4

第一條規則:永遠不要存儲密碼! 第二條規則:使用額外的鹽計算密碼哈希值,並將其存儲在數據庫中。 第三條規則:用戶名(uppercased)可以用作鹽,但最好加一點鹽! (一些額外的文本,最好是很長的一段) 第四條規則:散列算法的安全性並不重要,它們遲早都會被黑掉。所需要的只是時間! 第五條規則:您網站的安全性取決於它背後的價值。內容越有價值,你就越有可能遭到攻擊! 第六條規則:您遲早會發現您的網站遭到黑客攻擊,但不是通過黑客竊取的密碼,而是通過您代碼中其他位置的漏洞。如果您已經實施了一些強大的安全措施,最大的風險就是期待您的網站安全。第七條規則:如果只有人願意投入足夠的時間這樣做,所有的安全都可以被破壞,所有的網站都可以被黑客入侵,所有的祕密都可以被發現。

安全是一種幻想,但只要沒有人打破它,你可以繼續夢想!總是要做好準備,要求你再次重建你的幻想。 (換句話說,定期備份!(最好每天)。不要覆蓋上週的備份,並確保每週至少保留一次備份,以防萬一您在幾個月前發現您的網站遭到黑客入侵,並且全部如果你真的需要存儲密碼,請使用hash值加上用戶名和密碼,然後用hash加上salt再次哈希!更好的是,創建一個salt列表(只是列出單詞),並且每當創建一個新的用戶帳戶時,選擇一個隨機的鹽詞用來散列他的用戶名和密碼。存儲用戶帳戶的鹽索引,以便您知道每當他再次登錄時要使用哪一個。

And: 八條規則:總是使用HTTPS!它不像大多數PE那樣安全ople的東西,但它確實給你的用戶一種安全感!


既然你已經添加了文字,我會添加更多答案。

由於您希望user1授予對用戶2的臨時訪問權限,因此您需要一個輔助用戶表。 (或者用父用戶ID展開用戶表,並添加一個時間戳記以記錄帳戶的年齡,用戶1可以創建憑證,這是以正常的方式完成的,只需存儲一個包含用戶名和鹽的散列。在這種情況下,使用用戶1的用戶名作爲額外的鹽!只要確保在用戶1註銷或某段時間過去時禁用用戶2帳戶,並允許用戶1再次啓用所有帳戶他創建的,所以他們可以重新使用一個帳戶,而不必一直創建新的帳戶。

安全性不是依賴於主用戶或次用戶的問題。用戶有額外的好處,你可以使用主帳戶作爲額外的鹽,其餘的與認證無關,它是你正在處理的授權。 d授權有很強的關係,請注意您應該將它們視爲兩種不同的獨立技術。

當用戶1登錄時,他被授予訪問主站點的權限。當他授予對用戶2的訪問權限時,用戶2獲得一組縮減的角色。但這與存儲用戶名或密碼無關。你只需要一個用戶ID,它恰好是某些角色或組的成員。或者不是,但那些將無法訪問。

他們都只是用戶,一個擁有比另一個更多的權利。

0

你讓它太複雜了。您需要停止嘗試混合身份驗證和授權。

你想要做的是爲每個人建立憑據,而不是擔心在這一點上,如果他們是「主要」或「次要」用戶。然後在管理用戶和主要/次要關係的主站點上,您可以確定哪些用戶是主要或次要用戶的邏輯,並將所有這些內容存儲在表中。只要主要用戶更新他們與他們的關係,就可以授予或拒絕您希望每個輔助用戶的任何權利和子權利。完成後,您最終需要將適當的用戶憑證從主站點複製到輔助站點。

然後,當次要用戶想要前往場中的任何站點時,他們僅以自己身份驗證自己 - 他們從不冒充主要用戶!當主用戶給予他們「次要」身份時,他們只擁有你授予他們的權利。

-

OK,因爲你投的那個解下來的意見,考慮一下:

首先,我懷疑任何將是真正安全的。如果您監控用戶的活動,您隨時可以恢復密碼。

現在,這是完全關閉的袖口,我還沒有密碼分析,但檢查什麼是所謂的secret sharing計劃。將「有效」或「真實」主站點主用戶密碼存儲爲共享密碼。使用由主用戶給出的密碼的鹽漬散列作爲一個祕密。使用第一個輔助用戶給出的密碼的鹽漬散列作爲另一個祕密,以此類推。不要儲存鹽漬的哈希!只需存儲鹽和受保護的共享密鑰即可。

當用戶輸入密碼時,您將檢索受保護的共享密碼,使用密碼的salt和哈希值生成鹽漬哈希,解密受保護的共享密鑰,現在您已獲得原始主用戶密碼。

+1

嗨jadeters - 你錯過了要點...次要用戶必須「冒充」主要用戶才能獲得對該資源的訪問權限。沒有別的辦法。我試圖找出的是,密碼學中有沒有任何框架可以幫助我以一種不可讀的方式存儲主要用戶的密碼。請記住:當輔助用戶需要訪問它時,我必須將其提供給其他站點......可以設計出一些內容,以便只有在次要用戶登錄時我才能「存取」存儲的密碼,而不會直接由我? ...似乎不可能,不是嗎? :d – Steve 2009-09-17 18:02:42