首先mysql的密碼許可權儲存在mysql.user表中。我們不關注鑑權的部分，我們只關心身份認證，識別身份，後面的許可權控制是很簡單的事情。
在mysql.user表中有個authentication_string欄位，儲存的是密碼的兩次sha1值。
你可以用下面的語句，驗證和mysql.user表中儲存的是一致的。
select sha1(unhex(sha1(『password』)))
以上就是服務端關於密碼的儲存，接下來是認證過程。
mysql採用的是一種challenge/response(挑戰-應答)的認證模式。
第一步：客戶端連線伺服器
第二步：伺服器傳送隨機字串challenge給客戶端
第三步：客戶端傳送username+response給伺服器
其中response=hex(sha1(password) ^ sha1(challenge + sha1(sha1(password))))
第四步：伺服器驗證response。
伺服器儲存了sha1(sha1(password)))
所以可以計算得到sha1(challenge + sha1(sha1(password))))
那麼sha1(password)=response^ sha1(challenge + sha1(sha1(password))))
最後再對sha1(password)求一次sha1和儲存的資料進行比對，一致表示認證成功。
我們分析它的安全性：
抓包可以得到response，但是每次認證伺服器都會生成challenge，所以通過抓包無法構造登陸資訊。
資料庫內容被**，資料庫記錄的是sha1(sha1(password))，不可以得到sha1(password)和明文密碼，所以無法構造response，同樣無法登陸。
當然如果被抓包同時資料庫洩密，就可以得到sha1(password)，就可以仿冒登陸了。
這種認證方式其實是有乙個框架標準的，叫做sasl(****** authentication and security layer )，專門用於c/s模式下的使用者名稱密碼認證。原理就是伺服器傳送乙個challenge（質詢）給客戶端，客戶端返回的response證明自己擁有密碼，從而完成認證的過程，整個過程不需要密碼明文在網路上傳輸。
基於sasl協議有很多實現，mysql的就是模仿的cram-md5協議，再比如scram-sha1協議，是mongdb、postgresql使用的認證方式。
在jdk中專門有一套sasl的api，用於實現不同的sasl認證方式。
web網頁劫持是如何做到的
按照劫持的方法不同，我將劫持分為下面兩類 為了區分哪些是第三方給予導流過來的，通常會在url位址增加類似source from之類的引數，或者進入頁面之前通過 中間頁 種cookie。這樣，當使用者輸入乙個正常 的時候，劫持方會在網路層讓其跳轉到帶分成或者渠道號的 中間頁 或者帶渠道號的頁面。這樣使...
MySQL 到底是如何做到多版本併發的？
目錄 我們知道，讀未提交會造成髒讀 幻讀 不可重複讀，讀已提交會造成幻讀 不可重複讀，可重複讀可能會有幻讀，和序列化就不會有這些問題。那 innodb 到底是怎麼解決這些問題的呢？又或者，你有沒有想過造成髒讀 幻讀 不可重複讀的底層最根本的原因是什麼呢？這就是今天要聊的主角 mvcc multi v...
如何保障登陸安全 http協議
假設你的web伺服器沒有申請https證書，那麼涉及到重要機密的操作 比如登陸 就有可能被中間者輕鬆竊取。tips 阿里雲可以申請付費https證書 土豪們的選擇 也可以申請到免費https證書 貧窮百姓的無奈 但是免費證書 安全隱患 幾個字格外耀眼。以登陸為例 1 向伺服器申請乙個rsa公鑰 2 ...