驗證碼的三個罕見破綻和修復辦法。本站提示廣大學習愛好者：（驗證碼的三個罕見破綻和修復辦法）文章只能為提供參考，不一定能成為您想要的結果。以下是驗證碼的三個罕見破綻和修復辦法正文
把驗證碼存儲在Cookie中
普通來講，我們會把驗證碼的值用Session存儲起來，經由過程比較用戶提交的驗證碼和Session中的驗證碼，便可以曉得輸出能否准確。因為Session會占用辦事器資本，我已經想過能否可以把驗證碼的值加密後存儲在Cookie中。不外現實證實，這只是想入非非而已。
假定驗證碼的值是a，經由過程sha1加密後獲得的值為b = sha1(a)，而且把b存儲在Cookie中。而用戶提交的驗證碼值為c，經由過程斷定sha1(c)能否與b相等，可以曉得輸出的驗證碼能否准確。但是，Cookie是受客戶端掌握的。假如用戶事前經由過程肉眼看到驗證碼的值是a，又從Cookie中得知此時的加密值為b，那末，他只需在提交前把Cookie的值修正為b，提交的驗證碼值為a，便可以永久經由過程驗證。
沒有停止非空斷定
這類情形可以直接用代碼來講明：
if (Request["captcha"] == Session["captcha"] as string)
{
// 驗證經由過程，持續操作
}
假定用戶繞過了體系供給的表單直接提交數據，此時驗證碼還沒生成，Session["captcha"]為空。用戶不提交驗證碼時，Request["captcha"]也為空。因而，驗證經由過程了。
要處理這個成績，其實只需加個非空斷定便可以了：
if (!String.IsNullOrEmpty(Request["captcha"]) &&
Request["captcha"] == Session["captcha"] as string)
{
// 驗證經由過程，持續操作
}
沒有實時燒毀驗證碼
應用驗證碼要遵守一個准繩，在一次比對以後，不管用戶輸出准確與否，都要連忙將驗證碼燒毀。
假如不如許做，便可以湧現以下情形：
假定用戶輸出毛病，且驗證碼沒有從新生成，那末他便可以一向測驗考試，直到准確為止。固然機械對圖片的一次性辨認率比擬低，然則，假如統一張圖片你給它無窮次機遇的話，它照樣可以辨認出來的。
假定用戶輸出勝利，且驗證碼沒有燒毀，那末在Session過時之前，他便可以一向用這個驗證碼經由過程驗證。
