HTTP有辦法實現相對安全的通信嗎?
估計很多隻愛看標題不愛看內容的人會立馬想噴。“都什麼年代了,https都爆出很多漏洞,更何況是http?”雖然小編很菜,但這個簡單的道理還是略知一二的,所以標題中也加了“相對”二字。
在大多數場景中,如何防止系統資料被非法篡改,比防止資料被偵聽會顯得更加重要。
在繼續討論之前,我們先看一下https的驗證過程:
圖中可以看到,在用戶端請求時,伺服器端會生成私密金鑰和公開金鑰,然後公開金鑰會返回給用戶端,用戶端再通過公開金鑰來加密一個隨機碼併發送給伺服器,
雖然無法做到https那樣的安全性,但借助線下密碼加線上密碼相結合的方式,還是能夠一定程度上提升安全性的。過程大概是這樣的:
圖中我們其實是用到了兩個密碼,口令A是只有使用者和伺服器知道的密碼,這個密碼主要用來加密和解密公開金鑰的,而另外使用者還有一個登陸密碼。在現實場景中,這是可以實現的。例如,群眾甲到前臺申請開通網上辦事功能的時候,前臺操作人在系統中隨機生成一個口令A及一個登陸密碼,然後列印或者發送一條手機短信給群眾甲。還可以指定口令的有效時間。群眾甲回到家裡,在首次登錄的時候要輸入口令A來解密公開金鑰,然後輸入使用者密碼並用公開金鑰進行加密,這個過程是在用戶端完成的(可通過JS實現)。登錄成功後,強制要求其修改口令A,這個過程同樣涉及到公開金鑰傳輸的加密的問題,可以繼續用口令A來進行對稱加密加密,修改完成後就可以用口令B取代之前的口令A了。這種方式基本上能夠保障使用者密碼傳輸的安全性,只是需要使用者輸入兩個密碼,會對使用者體驗有較大的影響,有點多此一舉的感覺。可以考慮將口令保存在本地Cookie來減少使用者輸入的步驟,只是這又涉及到安全性的問題了,需要根據實際情況衡量。在具體實現上,前端可以用jsencrypt(實現RSA加密)結合crypto-js(實現AES/SHA解密),後端則根據不同的程式設計語言選擇對應的演算法即可。類似的代碼網上有很多,就不粘出來了。
上述的方法只適用於登錄等少數環節的加密解密,只是一種基於http環境下的相對安全的實現方式,要真正提升安全,建議還是儘量上https吧,簡單省事,目前有免費的證書,收費的也已經比以前下降了很多。
圖中我們其實是用到了兩個密碼,口令A是只有使用者和伺服器知道的密碼,這個密碼主要用來加密和解密公開金鑰的,而另外使用者還有一個登陸密碼。在現實場景中,這是可以實現的。例如,群眾甲到前臺申請開通網上辦事功能的時候,前臺操作人在系統中隨機生成一個口令A及一個登陸密碼,然後列印或者發送一條手機短信給群眾甲。還可以指定口令的有效時間。群眾甲回到家裡,在首次登錄的時候要輸入口令A來解密公開金鑰,然後輸入使用者密碼並用公開金鑰進行加密,這個過程是在用戶端完成的(可通過JS實現)。登錄成功後,強制要求其修改口令A,這個過程同樣涉及到公開金鑰傳輸的加密的問題,可以繼續用口令A來進行對稱加密加密,修改完成後就可以用口令B取代之前的口令A了。這種方式基本上能夠保障使用者密碼傳輸的安全性,只是需要使用者輸入兩個密碼,會對使用者體驗有較大的影響,有點多此一舉的感覺。可以考慮將口令保存在本地Cookie來減少使用者輸入的步驟,只是這又涉及到安全性的問題了,需要根據實際情況衡量。在具體實現上,前端可以用jsencrypt(實現RSA加密)結合crypto-js(實現AES/SHA解密),後端則根據不同的程式設計語言選擇對應的演算法即可。類似的代碼網上有很多,就不粘出來了。
上述的方法只適用於登錄等少數環節的加密解密,只是一種基於http環境下的相對安全的實現方式,要真正提升安全,建議還是儘量上https吧,簡單省事,目前有免費的證書,收費的也已經比以前下降了很多。