? ? ? ? 近期在實(shí)現(xiàn)HTTP和SIP DIGEST認(rèn)證蓖议，對(duì)用戶登錄時(shí)密碼的傳輸與存儲(chǔ)問題有了疑問與思考。
? ? ? ? 根據(jù)之前的開發(fā)經(jīng)驗(yàn)讥蟆，密碼肯定是不能直接明文存儲(chǔ)在數(shù)據(jù)庫中的勒虾，一旦數(shù)據(jù)庫被攻破，不僅本網(wǎng)站的用戶信息面臨危險(xiǎn)瘸彤，根據(jù)用戶設(shè)置密碼的慣性修然，可能會(huì)導(dǎo)致用戶很多關(guān)聯(lián)網(wǎng)站的信息也被竊取。為此常用的做法就是使用SALT + HASH的方法质况，至于HASH算法的話常用的就是MD5/SHA256/SHA512愕宋，但是當(dāng)使用DIGEST認(rèn)證時(shí)，問題就出現(xiàn)了：
? ? DIGEST認(rèn)證主要是采用服務(wù)器端和客戶端生成的隨機(jī)碼以及一些額外信息和密碼做MD5摘要结榄，最終由終端生成response中贝，傳遞到服務(wù)器，服務(wù)器再同樣根據(jù)隨機(jī)碼等信息以及密碼進(jìn)行MD5摘要臼朗，和客戶端生成結(jié)果進(jìn)行比較雄妥，從而完成密碼校驗(yàn)（詳情可參照RFC 2617）。
? ? 根據(jù)上面的描述依溯，也許有人已經(jīng)想到老厌，關(guān)鍵問題就是：服務(wù)器完成DIGEST認(rèn)證時(shí)需要與客戶端的密碼一致。但是如果服務(wù)端不存明文密碼黎炉，而是采用SALT+HASH的方式存儲(chǔ)密碼枝秤，該如何實(shí)現(xiàn)呢？初步的解決思路有兩個(gè)：
? ? 1. 將SALT通知客戶端慷嗜，客戶端采用相同的HASH算法進(jìn)行密碼摘要后淀弹，使用結(jié)果作為DIGEST認(rèn)證的密碼，在進(jìn)行DIGEST RESPONSE計(jì)算庆械。
? ? 2. 服務(wù)器不使用不可逆的HASH算法存儲(chǔ)密碼薇溃，而是采用對(duì)稱加密的方式，對(duì)稱加密密鑰隨機(jī)生成缭乘，并與用戶名沐序、密碼分表或分庫存儲(chǔ)，從而保證安全性堕绩。
個(gè)人選擇方法2策幼，下面談一談方法一的缺陷
? -- 將存儲(chǔ)密鑰用的SALT通知到客戶端本身就是很不安全的行為，如SALT被截獲就大大增加了別人破解密碼的可能性
?-- 其次奴紧，由于這次做的產(chǎn)品本身屬于標(biāo)準(zhǔn)化產(chǎn)品特姐，登陸過程需支持標(biāo)準(zhǔn)DIGEST方式，無法限制其他客戶端的行為黍氮，如采用此方式唐含，必然在標(biāo)準(zhǔn)化測(cè)試與對(duì)接時(shí)面臨問題浅浮。
為此權(quán)衡再三，還是覺得使用方法2較為可靠一些捷枯，不知各位有沒有什么別的好想法滚秩？
其實(shí)就協(xié)議來看，DIGEST認(rèn)證本身就不是太安全铜靶，也很容通過字典攻擊等常見MD5破解方式完成密碼破解叔遂。為此為保證傳輸密碼安全，還是需要使用TLS争剿。
PS: 其實(shí)DIGEST認(rèn)證個(gè)人感覺在HTTP協(xié)議中用途并不廣已艰，有印象的只有以前路由器的登陸使用了該方式，SIP中DIGEST登陸貌似倒是挺多的蚕苇，但好像也逐漸被AKA認(rèn)證所取代哩掺，后續(xù)還是有必要分析一下SIP AKA和HTTP中的密碼傳輸與存儲(chǔ)問題進(jìn)一步研究一番。
