[TOC]
首先恋昼，引用知乎用戶黃慧鵬的一段話账劲。](https://www.zhihu.com/people/huang-hui-peng)%E7%9A%84%E4%B8%80%E6%AE%B5%E8%AF%9D%E3%80%82)
加密的本質(zhì)是對原有內(nèi)容的混淆齿诉，目的是提高從表面結(jié)果反推達到目的的成本腮郊。在網(wǎng)頁提交（其實所有的通信都有這個問題）密碼這個問題上谆刨，需要有幾個維度來保證安全鉴逞，首先是切面的安全性，對于一次提交首先保護的是密碼本身偎痛，從最早的Base64到MD5或是SHA都可以做到這一點旱捧，但是Base64是可逆的，對于密碼本身的保護是很弱的踩麦，哈希算法解決了這個問題枚赡，將不同長度的數(shù)據(jù)轉(zhuǎn)換成統(tǒng)一長度的大數(shù)字，而理論上這個數(shù)字對應(yīng)無窮多解谓谦，但限于密碼的輸入有限制贫橙，其實是可逆的，所以從1次混淆的MD5變成了3次混淆的SHA反粥，但是隨著現(xiàn)代計算機技術(shù)的進步卢肃，逆運算的成本不斷降低，人們不得已要使用更大的數(shù)字來提高這個難度才顿，但是為了向成本和發(fā)展妥協(xié)践剂，人們不得已使用統(tǒng)一的算法，在CS時代由于很難侵入到CS兩端娜膘，所以相對的雙方使用的算法是保密的逊脯，破解難度相對比較大，BS由于為了保證開放性竣贪，特別是js本身就是明文算法军洼，所以其實只能說防君子不妨小人，所以就有了安全控件演怎，控件的唯一目的是用2進制代碼來隱藏加密的算法匕争，不知道算法，也就很難破解原文爷耀。第二維度就是時間甘桑，如果密碼一樣加密結(jié)果也會一樣，那么在不使用原文的情況下，可以使用加密過后的數(shù)據(jù)來模擬用戶登錄的動作也是可以的跑杭，所以純粹對密碼的加密其實不能解決這個問題铆帽，所以有了鹽值，讓同一個數(shù)據(jù)在不同情況下結(jié)果依舊不一致德谅，但是鹽值需要約定爹橱，總會被人找出規(guī)律，只是成本又高了點窄做，所以還是不安全愧驱，這就引發(fā)了通訊安全的問題。所以出現(xiàn)了https使用非對稱加密來保護數(shù)據(jù)通路上的安全椭盏，讓通訊變得不可窺視组砚。但是還有個東西叫木馬，所以人們在輸入上繼續(xù)做文章掏颊，包括混淆輸入惫确，就是軟鍵盤，好的控件不會把明文存在內(nèi)存里蚯舱，這很重要，以前的VB掩蛤、Dephi密碼控件都僅僅看不到枉昏，實際內(nèi)存里面都是明文，很容易被病毒和木馬利用揍鸟，所以一般來說現(xiàn)在最安全的bs系統(tǒng)使用控件保護輸入兄裂，隱藏自己的HASH算法，用HTTPS保護通訊阳藻。但是ssl都有漏洞被爆出晰奖，所以好的系統(tǒng)加上用戶自己勤換密碼才是保護自己的不二法則，不過腥泥，太累了匾南，所以使用硬件ukey吧，成本稍高

cookie和session的安全性

1 用戶密碼存放于cookie蛔外，每次請求都帶上蛆楞。

安全性
密碼存放在cookie中，非常不安全夹厌。即使對密碼進行加密豹爹，但是其他人只要盜竊了cookie，就算他不知道密碼矛纹，也可以使用加密后的密碼進行登錄臂聋。

2 用戶信息存在session中，cookie中存放sessionid

安全性
很不安全，cookie被盜竊孩等，拿到sessionid艾君，就可以獲得用戶身份。
開始httponly后瞎访，雖然無法使用腳本盜竊cookie腻贰，但是請求的數(shù)據(jù)在傳輸過程中可能被截獲，也會導(dǎo)致cookie被盜扒秸。
具體可以參考cookie和session泄露與防范

session放在url中傳遞播演，服務(wù)器使用url重寫。

很不安全啊伴奥，不要用這種方式写烤，發(fā)明這種方式的人簡直腦子有坑啊。

cookie和session泄露與防范

sessionid固定問題

攻擊者使用一些方法拾徙，讓用戶使用給定的sessionid進行登錄洲炊，服務(wù)器就會把這個sessionid與會話綁定。攻擊者就可以使用這個sessionid偽裝用戶尼啡。
不得不說暂衡，會出現(xiàn)這種問題，服務(wù)器的開發(fā)者是個弱智崖瞭】癯玻客戶端的用戶信息非常不可靠，竟然還是用客戶端傳過來的sessionid綁定书聚，你是有多懶唧领？
解決:登錄成功后，刷新sessionid雌续。

除了sessionid外斩个，添加其他驗證標識

例如，ip驯杜，User-Agent, 服務(wù)器收到用戶請求時受啥，把額外標志放到session中，用戶的下一次請求對額外標志與session中的額外標志進行對比鸽心，如果不一致腔呜，就彈出層讓用戶輸入密碼。
當然再悼，這個方法并不是完全可靠的核畴，如果用戶在使用代理軟件，那么ip隨時可能變化冲九。另外谤草，在局域網(wǎng)中跟束，多個用戶對服務(wù)器來說使用同一個外網(wǎng)ip，那么局域網(wǎng)內(nèi)的session盜竊是不能用這個方法防范的丑孩。

添加token

使用隨機秘鑰對sessionid進行加密冀宴，生成token， 這樣身份標識就增加到了3個:sessionid User-Agent token温学。
但是既然盜竊者可以拿到sessionid略贮，那么他就可以輕易的同樣拿到user-agent 和 token，這樣來看仗岖，token并沒有為盜竊者增加難度逃延。
所以，我們可以使用不同的方式來傳輸轧拄，sessionid放在cookie中揽祥，token放在get或者post參數(shù)中。
當然檩电，這些手段拄丰，雖然看起來增加了一些安全性，然而俐末，無法避免在傳輸過程中料按，請求被攔截，然后進行盜竊卓箫。
事實上载矿，像前面這幾種方法，就算你添加100個用戶標識丽柿，也是然并卵，除了增加服務(wù)器負擔魂挂，沒有帶來多少安全性的提升甫题。

在http下，如何對用戶登錄密碼進行加密

有人認為http下涂召，在客戶端對用戶密碼加密是多此一舉坠非，攻擊者總是可以獲得加密后的信息，進行重復(fù)登錄果正。
其實不然炎码，只需要在登錄時，添加上一個隨機碼秋泳，就可以保存密碼的安全潦闲。
登錄前，服務(wù)器向客戶端發(fā)送一個隨機碼迫皱，客戶端歉闰，使用用戶名，密碼，隨機碼和其他信息和敬，進行Hash加密凹炸，服務(wù)器收到請求后，從數(shù)據(jù)庫去除用戶信息昼弟，用同樣方式進行hash加密啤它，若相同，則驗證通過舱痘，同時隨機碼失效变骡。
攻擊者即使獲取到加密后的信息，也無法進行重復(fù)攻擊衰粹，因為隨機碼已經(jīng)失效锣光。
其實不僅僅是隨機碼，隨便一個可變的數(shù)據(jù)铝耻，都可以用戶加密密碼信息誊爹。比如時間戳。

這種方法可以保證http下密碼的安全性瓢捉，但是這僅僅對登錄有用频丘，其他的數(shù)據(jù)傳輸還是要靠sessionid來辨別用戶身份，sessionid被盜泡态，還是不安全搂漠。

想要真正的安全性，還是要靠HTTPS來保證某弦。

或者使用token驗證

用戶在注冊登錄和身份驗證中的安全性問題和處理方法

1 注冊和登錄時桐汤，密碼在傳輸過程中不能是明文
2 防止攻擊者拿到密文后，進行重放攻擊
3 數(shù)據(jù)庫保存密碼不能是明文

總之靶壮，可以采取的方案如下：
1怔毛、服務(wù)器端，用戶注冊時腾降，客戶端提交（密碼M+驗證碼N進行可逆的方法加密）=密文O拣度，服務(wù)器端，保存有驗證碼N螃壤，故而抗果，可以逆向運算獲得密碼M （隨機碼A） 和 （密碼B+隨機碼A進行MD5加密）密文C。雖然密文O是可逆的運算奸晴，但是冤馏，在提交過程中是不包括驗證碼N的，加上比較獨特的加密算法寄啼，基本可以保證安全了宿接。
2赘淮、提交注冊或登錄信息時，客戶端先從服務(wù)端獲得隨機碼A睦霎，然后提交（隨機碼A） 和 MD5（MD5（密碼B）+ 隨機碼A）=密文C梢卸，服務(wù)端組合后進行MD5加密，與數(shù)據(jù)庫驗證副女。
3 另外蛤高，可以采用類似https的方式，比如非對稱加密 + 隨機碼(防重放)碑幅。

在http環(huán)境下戴陡，沒有任何方法是安全，只能放君子不防小人沟涨，這些方法也只是增加破解的復(fù)雜度恤批。