1、避免使用者多次輸入密碼
2、實現自動登陸
3、避免在終端直接儲存使用者的密碼
4、標示客戶端的請求是否合法
5、其他（暫時沒想到）
我們需要引入token機制，基於token的驗證流程一般是這樣的：
客戶端使用使用者名稱跟密碼請求登入
服務端收到請求，去驗證使用者名稱與密碼
驗證成功後，服務端會簽發乙個 token，這個token是與使用者名稱一一對應的，token一般可以儲存在快取或資料庫中，以方便後面查詢出來進行驗證。再把這個 token 傳送給客戶端
客戶端收到 token 以後可以把它儲存起來，比如放在 cookie 裡或者 local storage 裡
客戶端每次向服務端請求資源的時候需要帶著服務端簽發的 token
服務端收到請求，然後去驗證客戶端請求裡面帶著的 token，如果驗證成功，就向客戶端返回請求的資料
token存在過期時間，在token生成的時候可以打上乙個時間戳，驗證token的時候同時驗證是否過期，並告知終端。終端接收到token過期的返回後，則要求使用者重新輸入使用者名稱跟密碼，進行登入。
使用者的一些操作需要從新請求服務端下發token，如退出、修改密碼後重新登入。
在客戶端與伺服器進行互動時，必然涉及到互動的報文（或者通俗的講，請求資料與返回資料），如果不希望報文進行明文傳輸，則需要進行報文的加密與解密。
所以加密的主要作用就是避免明文傳輸，就算被截獲報文，截獲方也不知道報文的具體內容。
1、在客戶端與伺服器進行互動時，報文雖然加密了，但我們並不能確認這個報文是誰發過來的。例如，與第三方伺服器b進行互動時，我方收到了乙個已加密的請求，但我方並不能確認是伺服器b傳送的這個報文，此時我們可以用數字簽名的方式來進行驗證。
2、如果我方收到乙個b伺服器簽名的請求，那麼b伺服器也無法否認這個請求，因為帶有它的簽名，作用：抗否認性。
3、我方收到乙個b伺服器簽名的請求，但我方並不能確認這個請求是否被篡改過（雖然報文加了密，也可能被篡改），此時即可用簽名，驗證簽名中的報文與傳過來的報文是否一致。作用：保證了資料的完整性
遵循規則：公鑰加密，私鑰解密
總結：在實際開發工作中應該 先通過web filter 解密，解密後進行驗證簽名(返回資料時，過程反過來，先簽名再加密)；然後再springmvc的interceptor 中進行驗證token
2023年以前，所有的加密方法都是同一種模式：
甲方選擇某一種加密規則，對資訊進行加密；
乙方使用同一種規則，對資訊進行解密
由於加密和解密使用同樣的規則（簡稱「秘鑰」）,這種被稱為「對稱加密演算法」。這種加密模式有個最大的弱點：甲方必須把加密規則告訴乙方，否則無法解密。儲存和傳遞秘鑰成了最頭疼的問題。2023年，兩位美國計算機科學家whitfield diffie和martin hellman，提出了一種嶄新的構思，可以在不直接傳遞秘鑰完成加密，這個被稱為」diffie-hellman金鑰交換演算法」。這個演算法啟發了其他科學家。人們認識到，加密和解密可以使用不同的規則，這要這種規則直接存在某種對應的關係即可，這樣就避免了直接傳遞秘鑰。這種新的加密模式被稱為「非對稱加密演算法」：
乙方生成兩把金鑰（公鑰和私鑰）。公鑰是公開的，任何人都可以獲得，私鑰則是保密的。
甲方獲取乙方的公鑰，然後用它對資訊加密。
乙方得到加密後的資訊，用私鑰解密。
如果公鑰加密的資訊只有私鑰解得開，那麼只要私鑰不洩漏，通訊就是安全的。
2023年，三位數學家rivest、shamir 和 adleman 設計了一種演算法，可以實現非對稱加密。這種演算法用他們三個人的名字命名，叫做rsa演算法。從那時直到現在，rsa演算法一直是最廣為使用的」非對稱加密演算法」。毫不誇張地說，只要有計算機網路的地方，就有rsa演算法。這種演算法非常可靠，金鑰越長，它就越難破解。根據已經披露的文獻，目前被破解的最長rsa金鑰是768個二進位制位。也就是說，長度超過768位的金鑰，還無法破解（至少沒人公開宣布）。因此可以認為，1024位的rsa金鑰基本安全，2048位的金鑰極其安全。rsa是目前最有影響力的公鑰加密演算法，它能夠抵抗到目前為止已知的絕大多數密碼攻擊，已被iso推薦為公鑰資料加密標準。
（1）client提取訊息m的訊息摘要h(m)，並使用自己的私鑰對摘要h(m)進行加密，生成簽名s。
（2）client將簽名s和訊息m一起，使用server發過來的公鑰進行加密，獲得密文c，傳送給server。
（1）server接受到密文後，用自己的私鑰對其解密，獲得明文訊息m和簽名s。
（2）server使用client的公鑰解密數字簽名s，獲得訊息摘要h(m)。
（3）server使用相同的方法提取訊息m的訊息摘要h(m)與上一步解密得到的h(m)進行比較，如果相同則驗籤成功。
2. 雙擊執行bin目錄下的openssl.exe
3. 生成rsa私鑰命令：genrsa -out rsa_private_key.pem 1024
4. 生成rsa公鑰命令：rsa -in rsa_private_key.pem -pubout -out rsa_public_key.pem
5. 將rsa私鑰轉換成pkcs8格式：pkcs8 -topk8 -inform pem -in rsa_private_key.pem -outform pem -out rsa_private_key_pkcs.txt -nocrypt
注意上面提供的測試**私鑰是基於pkcs8格式的。
資料摘要就是對資料來源進行乙個演算法之後得到的乙個摘要，也叫資料指紋，不同的資料來源，摘要結果不一樣。
資料摘要演算法是一種能產生特殊輸出格式的演算法，其原理是根據一定的運算規則對原始資料進行某種資訊的提取，被提取的資訊稱為原始資料的資訊摘要。
常用的摘要演算法有rsa公司的md5演算法和sha-1演算法以及其大量的變體。
資料摘要的特點：
1. 無論輸入的訊息有多長，計算出來的訊息摘要的長度總是固定的。例如應用md5演算法摘要的訊息有128個位元位，用sha-1演算法摘要的訊息最終有160位元位的輸出。
2. 一般來說（不考慮碰撞的情況下），只要輸入的原始資料不同，對其進行摘要以後產生的訊息摘要也必不相同，即使原始資料稍有改變，輸出的訊息摘要便完全不同。但是，相同的輸入必會產生相同的輸出。
3. 具有不可逆性，即只能進行正向的資訊摘要，而無法從摘要中恢復出任何的原始訊息。
所謂書數字簽名就是為了解決上述兩個問題二產生，對非對稱加密技術和資料摘要技術的乙個具體應用。對訊息傳送者來說，首先要生成一對公私鑰，將公鑰發給訊息接收者。
使用方法：
1. 訊息傳送者要給訊息接收者傳送訊息，出了傳送原始資料外，還需要傳送原始資料的數字簽名
2. 對訊息接受者來說，它將收到兩個資料，原始資料和簽名資料，它需要判斷這兩個資料的合法信來確保通訊的可靠，那麼如何操作呢：
(1):對原始資料提取資料摘要，注意這裡使用的訊息摘要演算法和傳送方的一致；
(2):對附加的那段數字簽名使用預先得到的公鑰解密；
(3):比較前兩步所得到的兩段訊息是否一致。如果一致，則表明訊息是可靠的，否則訊息在傳輸過程中一定出現了問題，訊息不可信。
在加解密的**中已經提供了簽名和驗籤的操作，就不在闡述。使用過支付寶的sdk的朋友都知道，向支付寶介面提交訂單資訊是就需要對訂單資訊進行簽名，支付寶為了確保訂單資訊的可靠性就使用了簽名機制。
使用加解密為了保證資料的安全性，公鑰加密私鑰解密；私鑰加密公鑰解密。
簽名機制是為了保證資料通訊的可靠性,私鑰簽名公鑰驗籤。
簽名和加密
既然是加密，那肯定是不希望別人知道我的訊息，所以只有我才能解密，所以可得出公鑰負責加密，私鑰負責解密 同理既然是簽名，那肯定是不希望有人冒充我發訊息，只有我才能發布這個簽名，所以可得出私鑰負責簽名，公鑰負責驗證。這裡一共有 兩組四個 金鑰 a的公鑰 pub a a的私鑰 pri a b的公鑰 pub...
加密解密簽名
加密和解密 傳送方利用接收方的公鑰對要傳送的明文進行加密,接受方利用自己的 私鑰進行解密,其中公鑰和私鑰匙相對的,任何乙個作為公鑰,則另乙個 就為私鑰.但是因為非對稱加密技術的速度比較慢,所以,一般採用對稱 加密技術加密明文,然後用非對稱加密技術加密對稱金鑰,即數字信封 技術.簽名和驗證 傳送方用特...
php token 簽名 加密
在之前的工作中，總是接觸到這些概念，之前都是零散的理解，在此總結下，以方便以後查閱 一 token 1 避免使用者多次輸入密碼 2 實現自動登陸 3 避免在終端直接儲存使用者的密碼 4 標示客戶端的請求是否合法 5 其他 暫時沒想到 我們需要引入token機制，基於token的驗證流程一般是這樣的 ...