阿北能不能看到我在豆瓣的賬戶對應的密碼？

01-05

沒人能看到。登錄密碼從2005年上線開始就是加密存儲的。當時的考慮很樸素：這個責任太大了，沒有理由和必要給用戶帶來明碼存儲的風險。

其實 @林建入的答案里B方案並不如A方案（這麼說不代表同意A方案的做法：））

在客戶端做HMAC是存在問題的，評論里 @李道兵多次提到這個問題，但是一直沒得到正面答覆。

HMAC需要一個私有的Token才能完成，而1樓方案里使用伺服器端生成的隨機數，傳到客戶端做Token，其實已經把Token泄露了，和普通哈希演算法沒區別。

B方案是可以防止重放攻擊。但在談論重放攻擊的前提是已經存在中間人了。在沒有HTTPS保護下，中間人都可以把你的返回頁面篡改了，把用戶輸入的明文密碼竊取，還談什麼防重放攻擊..

綜上，單獨的客戶端HMAC不如HTTPS + 客戶端哈希演算法。並且客戶端HMAC方案中，每次驗證生成一次隨機token的做法實現起來是非常複雜的。

完全可以。（9月15日在文末補充了針對一些質疑的回應）

無圖無真相。我們先來看看豆瓣登錄界面。

豆瓣的登錄位置有好幾個，在哪登錄都無所謂。問題是當你點擊登錄按鈕後，你的登錄密碼未經任何變換，直接以明文提交到伺服器上的。為了證明這一點，我們嘗試登錄，然後用fiddler捕獲一下請求過程，如下圖。

當然，因為我輸入的是假的密碼，所以登錄失敗了。但是從 fiddler 上我們可以清楚的看到密碼 12345678 就這麼乖乖的躺在那裡。

這意味著什麼？

這意味著只要豆瓣願意，它可以在服務端記錄下你的原始密碼。不管最終它是否會將你的密碼以哈希或加密方式存儲，但至少，豆瓣有機會知道用戶登錄密碼的明文。

豆瓣為什麼要這麼做？

首先，對於豆瓣來說，你的帳戶的所有信息，它都可以在不需要密碼的情況下進行任意的修改，所以豆瓣對用戶的密碼其實並不感興趣。其次，豆瓣確實會將用戶的密碼哈希變換後再存入資料庫，用於一定程度上防範黑客直接獲取到用戶的明文密碼。

但是由於問題問的是「阿北能不能看到我在豆瓣的賬戶對應的密碼？」，阿北回答不能。通過上面的分析我們知道，不是不能，只是不願意而已。如果豆瓣需要，隨時可以拿到活躍用戶的明文密碼。

如何改進？

在進行下面的討論之前，我們必須提醒大家，豆瓣在登錄驗證的部分已經採用SSL加密來保護了，上面描述的問題並不是在暗示大家「豆瓣不安全」（安不安全是另外一個問題了），這裡要討論的是，雖然阿北聲稱無法看到用戶的明文密碼，但是我們通過簡單的技術分析已經可以明確阿北在技術上依然可以輕鬆的看到用戶的密碼，並且用戶無法知道。

我現在想知道的是，到底有沒有一種辦法，可以讓阿北可以坦蕩的向用戶拍胸脯保證絕對看不到用戶的明文密碼，並且在技術上來說這種保證是可靠的——任何人都可以在客戶端進行驗證確保其沒有作弊？

事實上這樣的方案是存在的。並且不止一種，例如一種最廣為人知的方案就像下面這樣：

方案 A：基於哈希+HTTPS

當用戶註冊和登錄時，用戶的密碼不會被通過網路直接發送明文，而是先經過哈希後再發送，並且發送時採用 HTTPS 加密。這種方案的核心在於，哈希運算是在客戶端完成的，因此服務端接收到的用戶密碼都不是明文，阿北確實可以拍著胸脯說不會看到用戶密碼。由於中途通信加密了，安全性看起來還不錯。

但是我們也注意到，如果沒有 HTTPS 的保護，這種方案非常容易遭受重放攻擊。之所以這麼提出來，是因為後面討論的方案 B 能做到無需 HTTPS 保護，也能阻止重放攻擊。

這一方案在業內可以說已經算常識了。大多數稍微有點安全意識的開發人員都知道。不過這種方案也有它的缺點，因為 採用 HTTPS 並不是免費的。因此所有鼓吹 HTTPS 的人當真的決定採用 HTTPS 時才會發現，掏錢的時候到了。並且密鑰長度越長，價格越高。（儘管目前有免費的 HTTPS 證書頒發機構，但為數不多且並未受到廣泛支持，而且存在其他限制）

我個人強烈建議商業機構優先選擇類似 HTTPS 這樣的成熟方案。不過既然是討論，我們也應該開拓思路，試著尋找一下其他的方案。新的方案必須滿足：1、免費；2、能夠安全的完成身份驗證；3、阿北確實看不到我們的明文密碼。

好消息是，這樣的方案確實存在：

方案 B：基於 HMAC（Hash-based Message Authentication Code）

用戶登錄時，並不會將原文發送到伺服器。而是由伺服器發送一小段隨機的數據過來，然後客戶端基於這段隨機的數據以及用戶輸入的密碼，通過約定好的哈希演算法生成一段摘要值。客戶端把生成好的摘要發送到服務端，由於服務端只收到摘要，因此並不知道用戶輸入的密碼是什麼，為了夠判斷用戶密碼是否正確，它需要自己也做一次計算，把隨機數據以及資料庫中存儲的用戶密碼的哈希值都取出來，也做一次哈希運算，然後將自己計算出的摘要與客戶端發來的摘要進行比對，如果一致，則通過。整個過程也沒有明文發送給服務端，所以服務端還是無法知道用戶的明文密碼。

這種方案沒有涉及 HTTPS，因此它是免費的。並且，客戶端每次發給服務端用於驗證的哈希值都不同。這一點很重要，即使遭到黑客竊聽，黑客也無法通過重放攻擊偽造用戶身份登錄。（如果要進一步阻斷中間人攻擊，這種方案還需擴展）

方案是多種多樣的，無論是採用方案 A 還是方案 B，阿北都可以拍著胸脯向大家保證不會看到用戶的明文密碼。並且我們只需要簡單的檢查其客戶端的編程情況就可以驗證他的說法。

順帶一提，HMAC 並不是什麼新東西。96 年的時候就出現了，早已應用於 SSL，IPSec 等實踐領域。但是大多數程序員對它知之甚少。我在這裡提出來，只是拋磚引玉。

如果大家還有什麼疑問，如果是密碼學方面的，不妨翻翻各類著作，查查論文資料，相信都能獲得權威而滿意的答案。問我，一定不是最好的方式。我並非專業的密碼學領域研究人員，只不過做過一些擦邊的工作，深知自己知識貧乏。

---------------------------------------------

9月15日補充

對 @Ivony 提出的質疑的幾點回應：

引入第三方認證是比 HMAC 更好的解決方案？

Ivony 認為採用第三方認證的方式，比 HMAC 方案更好。理由是，瀏覽器內的頁面邏輯，服務端隨時可修改，依然存在隱患，而憑藉第三方認證，能夠解決這一問題。

但 Ivony 並未解釋，如何解決所有第三方認證普遍存在的信任鏈的可靠性不足問題。如何相信認證方不會將用戶密碼轉移給豆瓣？這可並不僅僅是一個技術問題（技術上採用 OAuth2 之類的協議即可），而更涉及到現實世界企業與企業之間的商業關係。

另外，就本質來說，HMAC 是一種兩方之間的安全認證過程，Ivony 並未繼續探討兩方之間如何找到比 HMAC 更好的方案，而是而是把問題擴展到了三方模型下來討論。這樣的擴展是很好的，是思路的擴展和解決方案的探索。但是由於解決方案的概念背景已經發生了質的變化，再進行簡單的優劣比較已經毫無意義。我無法認同第三方認證是比 HMAC 更好的方案——因為這兩種方案根本不在一個領域內。而且 HMAC 也可以用在第三方認證過程中。

另外 Ivony 談到我對 HMAC 的解釋不是很清楚。很抱歉，我的描述可能太粗略了。但是 HMAC 並不是我提出的。如果需要了解細節，google 上有豐富的資料足夠弄清來龍去脈。

HTTPS 證書很便宜？

首先，針對 HTTPS 證書價格的問題，不知道你採用的是何種方案？如果你是小型站點，並且願意將站點託管到國外例如 Godaddy 等服務商出，那麼你是有機會以優惠價格獲得基礎型 SSL 證書的。價格高低，每個人心裡的評價不同。但是計算時，別忘了證書費用是以年為單位付費的。無法買斷。另外通常還要和你的 IP 進行綁定，你的 IP 數目越多，價格還要另算。更別說證書是分類型的，保護級別不同，價格更是差別巨大。這樣說來，便宜不便宜，需要針對具體的情況來討論，我不能說總是貴的，但是也沒有誰能說總是便宜的。

更何況，國內稍微大一點的商業站點（面向國人為主的），大多數都不會將站點託管到境外。而購買 SSL 證書，更是會挑選服務質量較好的機構。大家不妨自己去下面的證書機構查查價格（證書的頒發機構不同，價格差別也較大）：

GeoTrust - 亞洲誠信

GlobalSign 數字證書認證中心

證書巴士|ssl證書

例如，以Thawte（首個向美國以外的地區頒發SSL證書的公司）為例，最便宜的域名型 SSL，每年的價格為 1150 元起。而最便宜的企業型 SSL 則為 2150 元起。如果你想要實現綠色瀏覽器欄的效果，那麼需要購買增強 EV 型企業 SSL，價格為 4650。

在這樣的價格體系下，一個普通的企業，購買 5 年的 Thawte 證書，需要 21500 元人民幣。便宜不便宜，就看你怎麼想了。

反對排名第一的 @林建入的答案。

該答案理論知識豐富，但很可惜，答主似乎沒有互聯網的一些常識。

比如說HTTP證書的價格，事實上一年的費用和域名的差不多。卻被說成是什麼昂貴的。

還有免費的方案也是含糊不清，並未說明是何種方案，也沒有說明是什麼限制。

該答案引用了大量的專業知識來向大家展示了一些血淋淋的事實。比如說密碼是以明文發送到網站伺服器端的，即使是採用了HTTPS加密，對於伺服器端而言，也是毫無保留的。HTTPS能保障的只是傳輸過程中不被惡意者竊取或是篡改。

然後給出了兩個基於客戶端的方案。。。。

而在有點互聯網常識的人看來，會發現這個答案是可笑的。對於一個網站而言，什麼是客戶端？瀏覽器？

事實上瀏覽器完全是被網站內容提供商，即網站伺服器端控制的。網站伺服器既可以指令瀏覽器在客戶端計算哈希或是採取別的加密措施發給自己，也可以要求瀏覽器以明文形式發送給自己。

所以事實上，伺服器完全有能力拿到密碼明文，這也是一個願不願意的問題，而不是能不能的問題。

所以很少有網站會做客戶端哈希後再發送給伺服器這種費力不討好的事情。這有幾個原因：

1、伺服器端完全有能力隨時要求客戶端發送明文密碼而無需通知用戶，所以這一做法除了自縛手腳並沒有帶來實質性的安全提升。

2、這可以降低用戶密碼泄漏的可能，因為雙方的通信被不法分子竊聽，那麼將不會泄漏密碼明文。但事實上不法分子竊取了哈希值也就足夠偽造用戶身份了，要不要明文已經不重要。何況HTTPS協議已經提供了非常強壯的通信保護協議。

當然。可能會有人說，雖然HTTPS協議可以保證密碼在傳輸過程中不被人竊取。但這並不可以防止伺服器被黑客劫持時密碼明文被泄漏，而哈希傳輸則可以避免這一點。

請仔細想想這是真的么？！如果伺服器被劫持了，那麼完全可以要求客戶端直接發密碼明文來就可以了么，別忘了客戶端是被伺服器端控制的。

那麼，真的不存在一個方案，可以讓網站的負責人可以用比發誓更好的方式證明自己絕對沒有可能比其他人更方便的獲得用戶的密碼嗎？

當然不是！

其實這個方案非常之簡單，很多網站都在使用，其實是現代互聯網非常至常見的一種方式。各位看官不妨猜一下。

在揭曉答案之前，我想說兩句題外話。事實上任何一個有節操的互聯網公司都已經盡了最大的努力避免用戶的隱私泄露。而絕大多數用戶信息的泄漏，都是因為用戶自己電腦上的木馬，或是註冊一些奇怪的論壇填寫的資料。像CSDN密碼門（我可以說CSDN是個沒節操的互聯網公司么？）這種事件，實在是少數中的少數。

安全的問題遠比普通用戶想的要複雜的多，可以攻擊的點也非常的多。絕大多數時候，網站的運營者根本沒有興趣故意去竊取用戶的隱私，反而，盡一切可能保護用戶的隱私不會因為自己的疏漏和問題導致泄漏才是這些網站運營者考慮的事情。更大的威脅來自於黑客和網站對於安全的不重視，而不是特權。

最後揭曉答案：

第三方身份驗證！

很簡單，如果用戶不需要在我的網站輸入密碼，那麼我就絕對沒有可能比其他人更接近用戶的密碼。如果你不在豆瓣註冊賬戶，而是使用第三方身份驗證（不知道豆瓣是否支持，建議豆瓣儘快支持，這樣阿北才不用發誓也能讓大家相信他，XD），那麼豆瓣也就沒有任何可能接觸到你的密碼了。

使用第三方身份驗證的安全小貼士：

請注意，目前所有的第三方身份驗證平台（包括Microsoft ID、Google Account、QQ等等），全部採用了HTTPS協議的登錄頁面，所以用戶在進行第三方身份驗證時，一定要注意檢查自己填寫密碼的頁面必須滿足：

1、當前請求是HTTPS請求，這個在現代瀏覽器都會用非常明確的方式標出，例如金黃色或者綠色的小鎖。

2、當前網站的證書是正確的，例如用Microsoft ID登錄的網站證書必須是Microsoft公司的，域名也必須是http://live.com的，同理Google Account的必須是Google公司的，域名同樣是http://google.com的。如果可能，建議檢查證書路徑，應當是直接從根證書頒發機構如VeriSign和直屬證書頒發機構頒發的。如果證書路徑中出現一些諸如CNNIC這樣的流氓，就有問題了，（事實上這也是HTTPS證書需要收費的原因。因為證書頒發機構需要進行一些必要的驗證確保證書不會被用來欺騙用戶）。

最後，無論如何，儘快將CNNIC從受信任的根證書頒發機構中刪除，具體方法一搜一大把，不再贅述。無良的證書頒發機構是HTTPS安全體系中最薄弱的一環。

============================針對回應的補充=========================

其實補充的回應更進一步的暴露了僅僅只是理論豐富而已。

首先說SSL證書，不論何種SSL證書，都至少包含一個公鑰/私鑰對，在整個HTTPS加密過程中，只有這個東西是和加密有關係的。所以不論何種價格，何種用途的SSL證書，至少數據傳輸安全方面是差不多的（因為密鑰長度還有區別，但幾乎可以忽略，目前頒發的證書最短密鑰128bit已經足夠）。不同的價格檔次主要是認證資料的不同（企業信息還是個人信息？認證域名還是認證IP？可否用於其他應用的加密？如郵件等）。

很顯然的，更完善的認證資料需要更多的手續以及證書頒發機構需要承擔更大的責任，自然價格就高了。一個普通的僅僅認證域名的SSL證書價格不過區區幾百塊。再一次提請注意的是，這些價格懸殊的證書之間，數據傳輸安全方面幾乎沒有區別。

不過真正令人大跌眼鏡的說法是：

如何解決所有第三方認證普遍存在的信任鏈的可靠性不足問題。如何相信認證方不會將用戶密碼轉移給豆瓣？這可並不僅僅是一個技術問題（技術上採用 OAuth2 之類的協議即可），而更涉及到現實世界企業與企業之間的商業關係。

其實我一直不想使用誅心論，即揣摩知乎用戶提供答案的動機。

但是這段文字一出，我實在無法理解一個擁有如此多專業背景的人拋出了一個現實世界的什麼商業關係，試圖把問題引出數據安全領域。

我來指出這個擔憂的可笑之處吧。

事實上細心的看客應該可以發現在我的答案中反覆使用了一種羅嗦的說法：

可以讓網站的負責人可以用比發誓更好的方式證明自己絕對沒有可能比其他人更方便的獲得用戶的密碼

這種羅嗦的說法的原因就是，密碼的安全其實不僅僅是技術和密碼學範疇的問題。例如阿北可以通過勾引用戶的女朋友，或者在用戶上廁所的時候給用戶電腦裝木馬，又或者派出女間諜勾引用戶，再或者簡單直接的用槍指著用戶來獲取密碼。

注意到上面這些方式的共性了么，是的，所有這些方式，既可以是阿北來付諸實施，也可以是阿東、阿南或者阿西等。

所以這個問題的本質是，阿北作為豆瓣網站的運營者有沒有可能比其他非特定對象更簡單一點點的獲得用戶的密碼。這是個簡單的是非題，是可以解答的。

就像我們說一個密鑰的安全性的時候，是指不能通過比暴力破解更簡單的方案來獲得密鑰。因為事實上除了一次一密的方案，已知的任何加密方式的密鑰都可以通過暴力破解來獲得。如果不存在比暴力破解更簡單的方案，那麼我們認為這個方案就是安全的。

所以，如果阿北去動用商業關係獲取用戶的密碼，那阿北就不再是阿北，因為可以通過非技術途徑獲得用戶密碼的，阿北並不具備什麼特殊性，甚至直接說美國總統動用政治關係去獲取用戶密碼好了，或者中國政府希望把提問者抓起來。而這些與提問者在豆瓣上註冊了賬號有半毛錢關係么？

最後說說信任鏈。

這根本就不是一個信任鏈的問題。在所有第三方登陸過程中，信任是建立在用戶和第三方身份驗證系統，以及目標網站與第三方身份驗證系統之間的。

也就是說這是個樹狀結構：

用戶 --信任-&> 第三方身份驗證機構

網站 --信任--------^

用戶在第三方身份驗證機構驗證自己的身份，而身份驗證機構將身份送交給網站。由始至終，第三方身份驗證機構完全不需要信任網站，鏈從何而來？

也正是因為在整個體系中，第三方身份驗證機構完全不信任網站，所以用戶與網站之間並未建立任何的信任關係（除非是用戶授權網站通過第三方身份驗證機構獲取用戶資料，但這不是第三方身份驗證的範疇內，而且也與密碼無關）。

從而在這個體系中，網站並不會比其他任何人更靠近用戶的密碼，因為用戶從始至終都無需信任網站。

一般來說，密碼都是以MD5之類加密存儲在伺服器端，沒法被看到。

伺服器管理員只能看到單向加密後的值，無法反推密碼。（但簡單密碼仍容易被暴力遍歷庫反查出來，更好的辦法是給密碼加一段固定字元串再加密，即」加鹽「）

不過，也爆出過CSDN使用明文密碼被拖庫的嚴重事件，難說一些早期、較爛開發的系統裡面，仍然使用明文存儲。

對 @林建入給出的方案b不認同。

方案b

這個方案在登錄操作的時候可以，但是在接下來的其他請求中無法保證安全。因為網站只會對登錄的時候生成隨機數來驗證，其他時候是通過cookie來驗證的。

看標題時覺得只是豆瓣以及阿北躺槍的節奏，看完林某的講解... 這個怎麼講呢，好像把問題搞高深了，暫不提對錯但邏輯組織很亂。

首先，所有的討論矛頭直指的是我們所謂的「端到端安全」，而一段密碼是這麼從前端漂流到後端的。（學過網路知識的自行跳過）

----------------------

A 在客戶端側

1 用戶鍵盤/虛擬鍵盤輸入

2 輸入框自驗證非法字元（依賴js）

3 客戶端頁面在傳輸前做加密處理(有自欺欺人用js的，一般是專門的安全插件，網盾U盾)

B 在網路途中

由http https等夾帶著登陸請求的相關信息，通過了若干網路節點，抵達目標ip地址的伺服器

C 在伺服器側

1 需要經過1級或多級的http分流伺服器

2 來到實際登錄驗證業務處理的核心伺服器

3 驗證伺服器有個處理的子線程開始對其進行驗證

在這個驗證過程中通常需要讀取用戶賬號資料庫來進比對

--------------------

其次，輸入、傳輸、處理、存儲的過程，都是可以明文的，所以在不計一切後果的前提下，純技術上講只要網站開發者願意隨時都可以把網站改成最不安全的狀態，這和你隨時可以自殺是一個道理，所以理論上阿北的確能，但你能毫無顧忌的殺死自己么，我不能也不想，阿北如是。

最後，不管是高級黑客還是阿北都只可能在ABC這3段中下手

A 客戶端側

輸入級攔截，這事歸你本機的病毒監控軟體管是360的事，不然誰也就救不了
除非你深諳反攔截技巧，利用滑鼠複製粘貼密碼片段導致其木馬程序不知道粘貼時滑鼠坐標對應的插入點位置而無從計算正確序列(因為木馬程序一般無法得知當前的輸入框在屏幕具體位置，最終他只能知道有多少個片段的組合，這是反間諜級別的知識吧)
安全沒它的事，它一般只是保證你無法輸入中文或特定的符號
這塊細說下

僅客戶端網頁自己的hash密碼，比如用JS：如果分欄位很明顯且那hash值將變成猶如新密碼的存在只要攻擊者知道它就是密碼，如果再加層JS byte級的混淆，那攻擊者必須先破解混淆方式才能知道這個hash怎麼用，總之能拖延下，但嚴格來看治標不治本。

客戶端網頁結合伺服器段傳送來的動態欄位進行hash加密：那麼在那個動態欄位的失效(包括按次及按時長)之前，此段hash碼可當密碼用。如果被攔截到但沒有及時被使用就是安全的。（這應該是林所提到的方案2）
數字簽名：高訴後台系統這是經過授權的客戶端可提供高許可權操作（比如付款交易）
U盾，他是真的有自己密匙並且會自己算的傢伙，且其可能發送的消息應該不是http而是私有消息格式。這就是說就算被攔截到的，你幾乎是沒可能看懂那消息格式的，更別提裡面的加密過的密碼了。
安全插件，多數是了讓瀏覽器整合數字簽名和U盾並夾帶更多信息而存在，他本身對於密碼安全性的貢獻不算大（我不確定哦！請自行參見為什麼支付寶使用用戶體驗欠佳的、PayPal 不使用的安全控制項？）

B 網路傳輸中

上面所提及的所有攔截，都是說的這各階段的所謂MINM(Man in the Middle attack)的中間人攻擊。

當黑客所操控設備與你同處於一個網路（最好是同一區域網），他就有機會監聽到所有那個網路流出網數據包，並在捕獲後進行解碼分析，或者是攔截後篡改內容再轉發。

Https一般會阻撓上述過程，它既加密傳輸，同時也讓消息被篡返回後，提示用戶，從而使得MINM化解
密碼安全學裡，也有諸多針對這個校驗方法，不過我都忘的差不多了就不說

C 伺服器側

如果前端分流伺服器被劫持，那http部分是有可能被篡改的：這時原網站內部的安全鏈路會做調整以防止其改寫內容，當然改域名也可以，手法很多
如果核心的業務伺服器被劫持，這是得有內鬼吧...已經黑到內網了：多數會暫停當前主伺服器業務，或啟用另一個集群另一套網路環境下的備份伺服器；黑客要是到了這裡，一般都是儘力的偽裝一切依舊正常，因為寶藏近在咫尺呀，誰會去改你的登陸業務邏輯
如果資料庫都被黑進去了, 相信能走到這一步的人肯定不2，他知道那些各種hash過的密碼串自己多半是反解不開的，還是撈點別的實惠的東西吧

無聊碼字，講的不對的地方不必太深究，我不是安全人士，只是普及點菜鳥知識

現在除了12306這種奇葩之外，大部分網站都是密碼加密存儲。

不能在回復里貼圖，只能修改答案了

這是我的一個12306的賬戶登錄截圖。如果12306不記錄密碼，怎麼每次我登錄都提醒我安全級別較低

另一個賬戶就不會這樣：

以下的回答可能會偏題，因為越往深究，我越認為，這不是簡單的能與不能的問題。

首先從豆瓣的重度用戶角度，我相信 @楊勃 (阿北) 自己的回答和其中表達的意願。

沒人能看到。登錄密碼從2005年上線開始就是加密存儲的。當時的考慮很樸素：這個責任太大了，沒有理由和必要給用戶帶來明碼存儲的風險。

但是，作為一名經歷過CSDN密碼泄露安全事件的開發+運維人員，我卻非常懷疑這種個人承諾對於互聯網服務中，用戶密碼安全的真正「效力」。

例如，開發人員中，會不會有一位勤奮的員工，因為嘗試理解生產環境中的數據模型，而下載了部分用戶註冊資料庫，然後又不經意間放在了一個公用U盤上？會不會有一位疲憊的運維員工，看錯了標籤，從資料庫伺服器磁碟陣列上，換下來一塊其實是無故障的，攜帶用戶數據的硬碟，然後流落到了硬體回收公司的手上？

回顧當時的CSDN事件，同時爆出消息的還有各家服務提供商，郵件服務、社區服務，不一而足（參考 CSDN密碼泄露，為毛會導致多玩網貓撲人人網也密碼泄露呢？至於為什麼國內的互聯網大型服務商都這麼巧合的犯了一個安全設計中的低級錯誤，則又是另外一個問題了。參考 CSDN 為什麼會用明文存儲密碼？是意外還是故意的？）。在各家的資料庫泄露文件中看到我的密碼明文，只能讓我目瞪口呆和憤怒。

所以我的建議是：

為了你真正重要的服務的系統安全（例如交易系統、個人郵箱、工作郵箱、伺服器管理員許可權等），請在豆瓣上使用獨立的密碼。
請不要讓阿北同學的責任比現在更大，請使用獨立的密碼。

關於最後的建議，補充些材料：

Secure Salted Password Hashing 很好奇，不知道豆瓣做到了哪一步。
Password Best Practices 如何管理好的你的密碼。
個人密碼安全策略主旨內容就是前一個鏈接的中文翻譯。

現在應該很少的密碼是明文存儲了吧。這樣多不安全啊。寫個演算法加密下也不是什麼難事。至於阿北能不能看見你的密碼，那太輕鬆了，想看的話就能看見。看見又如何？如果想修改你的數據，直接操作資料庫就ok，而不需要登錄你的賬號。其實不管如何加密，產品是他開發的，他的有辦法弄到。

@林建入說了這麼多只是提供了不讓 @楊勃 (阿北) 看到用戶的明文密碼的解決方案，無論 A 方案還是 B 方案都是這個目的，而在不是站在討論解決實際中的安全問題的這個角度。如果提問者只是關心他的密碼是否是明文的形式存在豆瓣的資料庫中，那這些回答都是鑽牛角尖了。林的回答嚴重跑題。

@楊勃 (阿北) 說豆瓣不存明文密碼，也就是說如果直接被拖庫，密碼別人是看不到的。 @林建入拿 Fiddler 截個圖，這個太唬人了，這隻能說明豆瓣沒在客戶端加密（改變）用戶密碼，然後說明通過 HTTPS 將原始密碼提交到豆瓣伺服器，這個時候你要是抓個包，再截個圖，還能看到密碼就牛逼了。把 HTTPS 看成是一個通道，原始密碼經過這個通道傳到了豆瓣的伺服器上，也就是給了豆瓣記錄原始密碼的機會。既然是"機會"，也就是說如果豆瓣從沒有記錄你的原始密碼，然後你從此不用你的用戶名密碼登錄豆瓣了，那麼@楊勃 (阿北) 就應該看不到你的密碼，因為你不給阿北看你密碼的機會。

反對@林建入的答案。這位同學羅列了一大串安全知識，卻沒有把重點放在問題本身上。

阿北能看到用戶的明文密碼的前提是豆瓣保存了用戶的明文密碼。如果豆瓣想要保存用戶的明文密碼，那他在用戶註冊的時候就可以辦到。難道有人會在註冊時把密碼加密保存，然後在用戶登陸的時候再把用戶的明文密碼偷偷地存到另一個地方？這顯然不符合邏輯。即然@楊勃 (阿北)承諾了沒有明文保存密碼，那我覺得可以相信豆瓣沒有明文保存密碼。

當然有另一種風險，比如某個員工私自修改了登陸的入口來收集用戶的明文密碼。這種風險也很容易規避，那就是靠公司制度：涉及安全或隱私的關鍵代碼，做出變更上線前隨機安排員工做代碼review。像登陸這種介面，需要做修改的機率其實是比較小的。這一點，小的公司可能實施起來比較難，但像豆瓣這種規模的公司，應該肯定不會有問題。

我相信豆瓣是不會給運營看到用戶的明文密碼的，但開發者拿到明文並不是難事（非攻城師，這部分算是猜測）。

而模擬訪問你的賬戶，非常有可能，「換位思考」是解決大部分用戶問題最直接有效的方式。

印象中，如果你是萬網的代理商，你就可以看到你客戶的所有賬戶密碼，明文的。（08/09年）

要做到用戶信息的安全，不僅要針對可能存在的外部攻擊，比如登錄時候使用ssl鏈接，內部保存要進行加密。在內部也要執行一套嚴格的安全制度，內部也要有安全控制才行。儘可能少的人擁有用戶隱私信息的許可權，並且需要有專門的安全部門長期檢查內部於外部的安全問題，用戶信息的使用必須符合法律與道德的要求。

這樣也才能保證基本的信息安全。畢竟在任何時候，國家都有權利從公司提取出用戶的隱私信息的。不論在美國還是中國都是一樣。

雖然阿北看不到你的密碼明文，卻可以用密文訪問你的賬戶，而且根本不用費那個事，湊合著看資料庫也行。

網站完全可以可以看到用戶的密碼，就像現在不能用qq郵箱來進行用戶註冊一樣，容易泄露了qq號。