微思探索沒有使用https，但是筆者認為已足夠安全。
這麼說的原因有以下幾點：
1.未登入場景比如登入，注冊，忘記密碼等，我們采取了足夠的安全措施，比如阿裡雲滑塊保護，非對稱秘鑰協商，短信檢驗碼認證等
2.登入後的所有後端接口都受token保護，請參考筆者的前一篇文章“賬号系統有了cookie，為什麼還需要token”
首先說一下登入前的場景，以注冊為例，阿裡雲滑塊為各個接口的保護提供了基礎，由于未登入前不知道是哪個使用者在操作，有可能是程式直接刷我們背景接口，舉個例子，如果沒有滑塊保護，發送短信接口直接暴露給使用者，有可能就被使用者狂刷，那後果可想而知。有人說即使滑塊也不是安全的，比如騰訊的滑塊就被人破解過，這我隻能說它設計的還不夠好，現在我選擇了阿裡雲的滑塊，一方面滑塊滑動的過程以及軌迹讓程式不容易模拟，另一方面是滑塊滑完後，使用者還需選擇某個漢字，又加了一重安全保障。是以我選擇相信阿裡雲的滑塊，以它為基礎，為其它接口提供保護。
以下是注冊的流程：
1.滑塊校驗通過後傳回的p-code作什麼用？p-code是一次性code，對後續接口調用作保護，使用者無法僞造，無論接口調用成功還是失敗，都會傳回p-code,也就是說，後續所有接口調用都在p-code的保護之下；
2.p-code保護秘鑰協商接口，為什麼要作秘鑰協商？這是參考了https的機制，在沒有https保護的情況下，我們需要類似的非對稱加密算法來作對稱秘鑰的協商，非對稱加密的最終目的是能協商出一個對稱秘鑰，然後使用這個對稱秘鑰對使用者密碼作加密處理，這樣密碼是絕對安全的；
3.對稱秘鑰協商完後，後續的發送短信還有最後的注冊接口，都是在p-code的保護之下，是以也是安全的；
4.針對p-code我們也會有限流，對各個接口作限流保護。
5.注冊接口的所有參數，都會使用對稱秘鑰作hmac sha256簽名，同時對密碼作AES加密，保證所有參數受到保護。
p-code如何起到保護作用?首先p-code是一次性的随機碼，再者p-code會跟使用者的一些資訊綁定（雖然使用者還未登入），針對這些使用者資訊作限流。p-code總是放在http header中，你要知道，隻要在http header中随便放一個頭，就能有效防止CSRF跨站僞造攻擊。
秘鑰協商時為什麼要前端生成對稱秘鑰？由于作非對稱秘鑰協商需要公鑰和私鑰，私鑰儲存在伺服器，公鑰直接儲存在js，前端生成對稱秘鑰的原因是：使用公鑰對對稱秘鑰作rsa加密的結果也隻有伺服器才能解密，就算請求被人攔截，由于不知道私鑰，也無從解密。反過來說，如果對稱秘鑰由後端生成，後端用私鑰加密的結果并無安全性可言，因為公鑰在js，每個人都可以輕而易舉擷取公鑰，使用公鑰就能将其解密。
在對稱秘鑰被有效保護的情況下，再通過對稱秘鑰來對密碼作AES加密，這樣就可以有效地保護使用者輸入的密碼，以及對各個參數作hmac sha256簽名，可以有效地保護各個參數不被篡改，不被重放，不被僞造。
綜上，微思探索借鑒了https的機制，再加上hmac簽名機制，以及AES加密機制，保證了在http的情況下，也是安全的。
文章已經收錄在此：
