frombase認證

基於表單的認證方法並非在HTTP協議中定義的。客戶端會向服務器上的web應用程序發信息（Credential），按登陸信息的驗證結果認證。

根據web應用程序的實際安裝，提供用戶界面認證方式也各有不一樣

多數狀況下，輸入已事先登陸的用戶ID（一般是任意字符串或郵箱地址）和密碼等登陸信息後，發送web應用程序，基於認證結果來肯定認證是否成功

認證多半爲基於表單認證

因爲使用上的便利性及安全性問題，http協議標準提供的BASIC認證和DIGEST認證幾乎不怎麼使用，另外，SSL客戶端認證雖然具備高度的安全等級，但由於導入及維護費用等問題，還還沒有普及。

好比SSH和FTP協議，服務器與客戶端之間的認證時合乎標準規範的，並知足了最基本的功能需求上的安全使用級別，所以這些協議的認證能夠拿來直接使用。可是對於web網站的認證功能，可以知足其安全使用級別的標準規範並不存在，因此只要使用web應用程序各自實現基於表單的認證方式。

不具有共同標準規範的表單認證，在每一個web網站上都會有各自不一樣的實現方式。若是是全面考慮過安全性能而實現的表單認證，那麼就可以具有高度的安全等級。但在表單認證中存在問題的Web網站也是家常便飯。

session管理及cookie應用

基於表單認證的標準規範還沒有有定論，通常會使用Cookie來管理Session（回話）

基於表單認證自己是經過服務器端的web應用，將客戶端發送過來的用戶ID和密碼與以前的登陸過的先作匹配進行認證的。

但鑑於http是無狀態協議，以前認證成功的用戶狀態沒法經過協議層面保存下來。既，沒法實現管理狀態管理，所以即便當該用戶下一次繼續訪問，也沒法區分他與其餘的用戶。因而咱們就是要cookie來管理session，以彌補http協議中不存在的狀態管理功能。

步驟1 ：客戶端把用戶ID和密碼等登陸信息放入報文的實體部分，一般以POST方法把請求發送給服務器，而這時，會使用https通訊來進行html表單畫面的顯示和用戶輸入數據的發送。

步驟2： 服務器會發放用以識別用戶的Session ID。經過驗證從客戶端發送過來的登陸信息進行身份認證，而後把用戶的認證狀態與Session ID綁定後記錄在服務器.

客戶端返回響應時，會在首部字段Set-Cookie 內寫入Session ID。

你能夠把SessionID想象成一種用以區分不一樣用戶的等位號。

然而，若是Session ID被第三方盜走，對方就能夠假裝成你的身份進行惡意的操做。所以必須防止Session ID被盜，或被猜出，爲了作到這點，Session ID應使用難以推測的字符串，並服務器也須要進行有效期的管理，保證安全性。

另外，爲了減輕跨站腳本攻擊（XSS）形成的損失，建議事先在cookie內加上httponly屬性。

步驟3： 客戶端接受到從服務器端發來的Session後，會將其做爲cookie保存在本地。下次向服務器發送請求時，瀏覽器會本身發送cookie，因此Session ID也隨之發送到服務器。服務器端可經過驗證接收到的Session ID 識別用戶和其認證狀態

除了以上簡介的應用實例，還有應用其餘不一樣方法案例

一般，一種安全的保存方法是，先利用給密碼加鹽（salt）的方式增長額外信息，在使用散列（hash）函數計算散列值後保存。可是咱們常常看到直接保存明文密碼的作法，這樣的作法具備致使密碼泄露的風險。

 salt 其實就是由服務器隨機生成的一個字符串，可是要保證長度足夠長，而且是 真正隨機生成的。而後把它和密碼字符串相鏈接（先後均可以）生成散列值。當 兩個用戶使用了同一個密碼時，因爲隨機生成的 salt 值不一樣，對應的散列值也將 是不一樣的。這樣一來，很大程度上減小了密碼特徵，攻擊者也就很難利用本身手 中的密碼特徵庫進行破解。——譯者注