所謂加salt，就是加點「佐料」。當使用者首次提供密碼時（通常是註冊時），由系統自動往這個密碼裡加一些「salt值」，這個值是由系統隨機生成的，並且只有系統知道。然後再雜湊。而當使用者登入時，系統為使用者提供的**撒上同樣的「salt值」，然後雜湊，再比較雜湊值，已確定密碼是否正確。這樣，即便兩個使用者使用了同乙個密碼，由於系統為它們生成的salt值不同，他們的雜湊值也是不同的。即便黑客可以通過自己的密碼和自己生成的雜湊值來找具有特定密碼的使用者，但這個機率太小了（密碼和salt值都得和黑客使用的一樣才行）。
假設你的資料庫已經被黑客拿到了。比如 md5sum("123456") = "e10adc3949ba59abbe56e057f20f883e"
如果不用 salt ，直接 md5 的話，直接在你的資料庫裡搜尋後面那個值不就能找出所有密碼是"123456"的使用者了嗎？
要知道，黑客的目的其實並不是（或者說大多數時候不是）破解某乙個人的密碼，而是獲取大量的使用者名稱/密碼對。
好了，現在你加了鹽，但鹽是固定的，比如直接寫死在**裡的，這樣行不行呢？這樣也是不行的，因為黑客仍然可以通過預先計算的方式來做。比如黑客黑了你的伺服器，看到了你的**，知道了你的鹽是 *** ，於是他計算：
md5sum("123456***") = "e087dae60e744ea80722b785a75adbb7"
然後再到你的資料庫裡搜尋，又能得到大量密碼是 123456 的使用者了。
那該怎麼辦呢？
所以，不但要加鹽，而且每個使用者的鹽還得不一樣。我看到的一種做法是，直接用每個使用者的使用者名稱，或者使用者名稱的變形來做鹽。
兩者在原理上都是通過session token來實現的。當客戶端請求頁面時，伺服器會生成乙個隨機數token，並且將token放置到session當中，然後將token發給客戶端（一般通過構造hidden表單）。下次客戶端提交請求時，token會隨著表單一起提交到伺服器端。token，就是令牌，最大的特點就是隨機性，不可**。一般黑客或軟體無法猜測出來。
那麼，token有什麼作用？又是什麼原理呢？
token一般用在兩個地方:
然後，如果應用於「anti csrf攻擊」，則伺服器端會對token值進行驗證，判斷是否和session中的token值相等，若相等，則可以證明請求有效，不是偽造的。
不過，如果應用於「防止表單重複提交」，伺服器端第一次驗證相同過後，會將session中的token值更新下，若使用者重複提交，第二次的驗證判斷將失敗，因為使用者提交的表單中的token沒變，但伺服器端session中token已經改變了。
上面的session應用相對安全，但也叫繁瑣，同時當多頁面多請求時，必須採用多token同時生成的方法，這樣占用更多資源，執行效率會降低。因此，也可用cookie儲存驗證資訊的方法來代替session token。比如，應對「重複提交」時，當第一次提交後便把已經提交的資訊寫到cookie中，當第二次提交時，由於cookie已經有提交記錄，因此第二次提交會失敗。
不過，cookie儲存有個致命弱點，如果cookie被劫持（xss攻擊很容易得到使用者cookie），那麼又一次gameover。黑客將直接實現csrf攻擊。
所以，安全和高效相對的。具體問題具體對待吧。
Aandroid日常開發中應該注意的安全問題
應用資料備份問題 四大元件的匯出風險 android exported 是android中的四大元件 activity，service，contentprovider，broadcastreceiver 四大元件中都會有的乙個屬性。作用是 是否支援其它應用呼叫當前元件。預設值 如果包含有intent...
CSS framework日常開發的經驗總結
二 css框架的開發順序 1 格式化 reset.css 格式化css的真正好處是能夠快速啟動工作，你可以在新的html檔案裡引入框架，不用再處理重置padding 和 margins，實現統一的排版 瀏覽器下的相同表現。2 布局 layout.css 定義頁面是二欄還是三欄，是全屏還是1024 7...
安卓日常開發碰到的問題
radiogroup與textview對不齊 android layout height match parent scrollview套listview問題 貼 static class utility int totalheight 0 for int i 0 i listadapter.get...