
筆者發現滿多開發者對於 PKCS1 的機制不夠理解,導致以此來做身份驗證的時候產生漏洞,本篇將說明如何安全地透過 PKCS1 進行驗證。
身份驗證機制

身份驗證本身是做數位簽章,將原文 TBS、Hash 演算法丟到自然人憑證,會得到簽章值、公鑰憑證、卡號。
驗簽方式則為,後端取得原文、Hash 演算法、公鑰憑證、簽章值,將簽章值以公鑰解密,比對是否等於原文的 Hash。
弱點清單
弱點一、只識別前端傳過來的卡號
我們可以在前端取得卡號,並傳送到後端,但由於前端傳到後端卡號是明文,有可能被篡改,因此不能將傳到後端的卡號來識別使用者。
弱點二、TBS 由前端傳過來
後端用來驗證的資料為 TBS、簽章值、憑證,由於相同 TBS 簽章完的簽章值是固定的,如果 TBS 由前端產生,代表後端沒有機制檢查 TBS 產生的機制。駭客若取得任一組 TBS 與簽章值,就有機會登入該系統。因此驗證機制的 TBS 應由後端產生。
弱點三、TBS 由後端產生,但規則固定
如果 TBS 由後端產生,但是規則固定,就有可能被駭客利用,以此規則產生 TBS,並架設釣魚網站取得使用者的簽章值,就可以盜取帳號。TBS 應由後端亂數產生較為安全,且驗簽的時使用後端存的 TBS。
弱點四、以 SessionID 當作 TBS
通常 SessionID 都會受到 HTTP Only 保護,如果將 SessionID 當作 TBS,將會導致 SessionID 外洩。
弱點五、未比對憑證鏈
當我們取得憑證時,需要先檢查該憑證是否屬於自然人憑證的憑證鏈,避免憑證被偽造或竄改。憑證中的序號、姓名、身分證末四碼都有機會被修改。憑證鏈驗證需要將使用者憑證與內政部憑證管理中心的中繼憑證進行驗證,不能只檢查 issuer 欄位。
弱點六、未比對憑證廢止清冊
憑證都有廢止清冊,如果未比對廢止清冊,可能導致掛失的卡仍被使用。
弱點七、未比對憑證的姓名與身分證末四碼
憑證中有包含使用者的姓名與身分證末四碼,需要先檢查這些資訊是否符合該使用者的資訊。
弱點八、未檢查憑證是否過期
憑證是否使用期限的,為檢查期限,可能導致過期的憑證仍可以使用。
弱點九、同名同姓、同身分證末四碼
由於憑證中只有姓名、身分證末四碼,當有兩人這些資訊完全相同時,是沒辦法識別兩人的,只能透過後端儲存憑證來避免冒名。
最佳實踐
建議的方式為 TBS 由後端產生,且需要亂數產生。Session 要有辦法識別目前使用者的 TBS,驗證的時候使用後端的 TBS,而非前端傳來的 TBS。接著依後端是否有儲存憑證分為:
方法一、使用者先註冊憑證,登入時前端只傳來簽章值
使用者先透過註冊流程來註冊憑證,註冊流程中要檢查憑證鏈、廢止清冊、姓名、身分證末四碼、使用期限,並將憑證儲存在資料庫。
當使用者登入後,由前端傳送簽章值到後端,以資料庫的憑證與後端的 TBS 來驗證簽章值。
方法二、使用者不需註冊憑證,登入時前端傳來簽章值與憑證
如果沒有註冊流程,則需要每次登入時由前端傳來簽章值與憑證,也需要先驗證憑證的憑證鏈、廢止清冊、姓名、身分證末四碼、使用期限,再與後端的 TBS 進行驗簽。但當有人同名同姓、同身分證末四碼則沒辦法識別。