前言
相信大家在開發中都遇到過,有些隱秘信息需要做加密傳輸的場景.
A:你就把 XXX 做一下base64加密傳過來就行
這些問題相信大家都遇到過,那么在實際開發中我們應該如何選擇加密方法呢?
加密
這里我就直接拋出來幾個加密規則
-
AES對稱加密,雙方只有同一個秘鑰key -
RSA非對稱加密,生成一對公私鑰.
首先要明確一點, 即使做了加密也不能保證我們的信息就是絕對安全的,只是盡可能的提升破解難度,加密算法的實現都是公開的,所以秘鑰如何安全的存儲是我們要重點考慮的問題.
關于這兩種加密算法大家可以網上查一下原理,這里我不介紹原理,只介紹給大家特定場景下如何選擇最優的加密規則,以及一些小Tips.
AES
對稱加密,很好理解,生成唯一秘鑰key,雙方本別可以用key做加密/解密.是比較常用的加密首段,AES只是一種加密規則,具體的加密還有很多種,目前主流使用的是AES/GCM.
RSA
非對稱加密,生成一對秘鑰,public key/private key,
加解密使用時: public key加密, private key解密.
簽名驗證時 : private key簽名 , public key 驗簽
這里說一下實際案例:
某某公司,2B的后臺支付接口,突然有一天一個商家反饋為什么我賬戶里錢都沒有了,通過日志一查發現都是正常操作刷走了.而某公司并沒有辦法證明自己的系統是沒問題的.理論上這個接口的
key下發給商戶,但是某某公司也是有這個key的,所以到底是誰泄漏了key又是誰刷走了賬戶里的錢,誰也無法證明.
這里我們要想一個問題,我們要怎么做才能防止出現此類問題后,商戶過來說不是我刷的錢,尋求賠償的時候, 拿出證據打發他們?
這個問題就可以利用RSA來解決,在接入公司生成APP key 要求接入方自己生成一對RSA秘鑰,然后講 public key上傳給我們, private key由接入方自己保存, 而我們只需要驗證訂單中的簽名是否是由private key簽名的,而非其他阿貓阿狗簽名的訂單. 如果出現了上訴問題,那么說明接入方的private key泄漏與我們無關,這樣我們就能防止接入方抵賴.
完整性校驗.防串改
很多情況下我們需要對數據的完整性做校驗, 比如對方發過來一個文件, 我們怎么知道這個問題件就是源文件, 而非被別人惡意攔截串改后的問題?
早些年大家下載程序的時候應該會看到,當前文件的md5值是XXXXX,這個就是為了防止文件被修改的存在的.早期我們都是用md5/sha1來做完整性校驗,后來由sha1升級出現了sha256.大家可能不知道應該如何選擇.
下面是一個經典故事
Google之前公開過兩個不同的PDF,而它們擁有相同的sha1值
兩個不同的文件擁有相同sha1值,這意味著我們本地使用的程序sha1是源文件非串改后的,但實際上可能早已偷梁換柱.這是很可怕的.
所以推薦大家在用完整性校驗時要使用sha256,會更安全些.
