你的登入介面真的安全嗎？

大家學寫程式時，第一行**都是hello world。但是當你開始學習web後台技術時，很多人的第乙個功能就是寫的登入（小聲：別人我不知道，反正我是）。但是我在和很多任務作經驗較短的同學面試或溝通的時候，發現很多同學雖然都有在簡歷上寫：負責專案的登入/註冊功能模組的開發和設計工作，但是都只是簡單的實現了功能邏輯，在安全方面並沒有考慮太多。這篇文章主要是和大家聊一聊，在設計乙個登入介面時，不僅僅是功能上的實現，在安全方面，我們還需要考慮哪些地方。

偽**如下：

# 密碼字典
password_dict = 
# 登入介面
login_url = ''
def attack(username):
for password in password_dict:
data = 
content = requests.post(login_url, data).content.decode('utf-8')
if 'login success' in content:
print('got it! password is : %s' % password)

那麼這種情況，我們要怎麼防範呢？

偽**如下：

fail_count = get_from_redis(fail_username)
if fail_count >= 3:
if captcha is none:
return error('需要驗證碼')
check_captcha(captcha)
success = do_login(username, password)
if not success:
set_redis(fail_username, fail_count + 1)

這樣確實可以過濾掉一些非法的攻擊，但是以目前的ocr技術來說的話，普通的驗證碼真的很難做到有效的防止機械人（我們就在這個上面吃過大虧）。當然，我們也可以花錢購買類似於三方公司提供的滑動驗證等驗證方案，但是也並不是100%的安全，一樣可以被破解（慘痛教訓）。

那這時候又有同學說了，那我可以直接限制非正常使用者的登入操作，當它密碼錯誤達到一定次數時，直接拒絕使用者的登入，隔一段時間再恢復。比如我們設定某個賬號在登入時錯誤次數達到10次時，則5分鐘內拒絕該賬號的所有登入操作。

偽**如下：

fail_count = get_from_redis(fail_username)
locked = get_from_redis(lock_username)
if locked:
return error('拒絕登入')
if fail_count >= 3:
if captcha is none:
return error('需要驗證碼')
check_captcha(captcha)
success = do_login(username, password)
if not success:
set_redis(fail_username, fail_count + 1)
if fail_count + 1 >= 10:
# 失敗超過10次，設定鎖定標記
set_redis(lock_username, true, 300s)

umm，這樣確實可以解決使用者密碼被爆破的問題。但是，這樣會帶來另乙個風險：攻擊者雖然不能獲取到**的使用者資訊，但是它可以讓我們**所有的使用者都無法登入！攻擊者只需要無限迴圈遍歷所有的使用者名稱（即使沒有，隨機也行）進行登入，那麼這些使用者會永遠處於鎖定狀態，導致正常的使用者無法登入**！

那既然直接針對使用者名稱不行的話，我們可以針對ip來處理，直接把攻擊者的ip封了不就萬事大吉了嘛。我們可以設定某個ip下呼叫登入介面錯誤次數達到一定時，則禁止該ip進行登入操作。

偽**如下：

ip = request['ip']
fail_count = get_from_redis(fail_ip)
if fail_count > 10:
return error('拒絕登入')
# 其它邏輯
# do something()
success = do_login(username, password)
if not success:
set_redis(fail_ip, true, 300s)

這樣也可以一定程度上解決問題，事實上有很多的限流操作都是針對ip進行的，比如niginx的限流模組就可以限制乙個ip在單位時間內的訪問次數。但是這裡還是存在問題：

那難道就沒有乙個比較好的方式來防範嗎？　當然有。　我們可以看到近些年來，幾乎所有的應用都會讓使用者繫結手機，乙個是國家的實名制政策要求，第二個是手機基本上和身份證一樣，基本上可以代表乙個人的身份標識了。所以很多安全操作都是基於手機驗證來進行的，登入也可以。

1.當使用者輸入密碼次數大於3次時，要求使用者輸入驗證碼（最好使用滑動驗證）

2.當使用者輸入密碼次數大於10次時，彈出手機驗證，需要使用者使用手機驗證碼和密碼雙重認證進行登入

偽**如下：

fail_count = get_from_redis(fail_username)
if fail_count > 3:
if captcha is none:
return error('需要驗證碼')
check_captcha(captcha)
if fail_count > 10:
# 大於10次，使用驗證碼和密碼登入
if dynamic_code is none:
return error('請輸入手機驗證碼')
if not validate_dynamic_code(username, dynamic_code):
delete_dynamic_code(username)
return error('手機驗證碼錯誤')
success = do_login(username, password, dynamic_code)
if not success:
set_redis(fail_username, fail_count + 1)

我們結合了上面說的幾種方式的同時，加上了手機驗證碼的驗證模式，基本上可以阻止相當多的一部分惡意攻擊者。但是沒有系統是絕對安全的，我們只能夠盡可能的增加攻擊者的攻擊成本。大家可以根據自己**的實際情況來選擇合適的策略。

中間人攻擊(man-in-the-middle attack, abbreviated to mitm)，簡單一點來說就是，a和b在通訊過程中，攻擊者通過嗅探、攔截等方式獲取或修改a和b的通訊內容。

舉個栗子：小白給小黃發快遞，途中要經過快遞點a，小黑就躲在快遞點a，或者乾脆自己開乙個快遞點b來冒充快遞點a。然後偷偷的拆了小白給小黃的快遞，看看裡面有啥東西。甚至可以把小白的快遞給留下來，自己再打包乙個一毛一樣的箱子發給小黃。

那在登入過程中，如果攻擊者在嗅探到了從客戶端發往服務端的登入請求，就可以很輕易的獲取到使用者的使用者名稱和密碼。

防範中間人攻擊最簡單也是最有效的乙個操作，更換https，把**中所有的http請求修改為強制使用https。

為什麼https可以防範中間人攻擊？https實際上就是在http和tcp協議中間加入了ssl/tls協議，用於保障資料的安全傳輸。相比於http，https主要有以下幾個特點：

在https之外，我們還可以手動對敏感資料進行加密傳輸：

除了上面我們聊的這些以外，其實還有很多其它的工作可以考慮，比如：

現在國家不斷的出台各種法律，對使用者的資料越來越看重。作為開發者，我們也需要在保護使用者資料和使用者隱私方面做更多的工作。後面我也會和大家聊一聊，我們在資料安全方面，做了哪些工作，希望可以給到大家一點點幫助。