起因

帖子：盼大佬解答，前端加密到底是不是脫褲子放屁？

問(wèn)題

問(wèn)題：HTTPS環(huán)境下，前端在傳輸密碼時(shí)，是否有必要進(jìn)行加密？

觀點(diǎn)

有必要
1 、防止無(wú)意泄露和二次傷害。（打 debug 日志無(wú)意間把用戶輸入打到日志）
2 、隱私合規(guī)問(wèn)題，參差不齊的員工可以拿到密碼加用戶手機(jī)號(hào)，登錄任何設(shè)置此密碼的網(wǎng)站。

無(wú)必要
1 、https + 后端加密入庫(kù)足夠安全。
2 、后端需要驗(yàn)證密碼復(fù)雜度（業(yè)務(wù)場(chǎng)景）
3 、增加開(kāi)發(fā)成本，沒(méi)必要。
4 、加密后導(dǎo)致密碼強(qiáng)度的下降(因?yàn)槊芪牡男畔㈧叵陆盗?

討論

1、實(shí)際項(xiàng)目中，確實(shí)遇到過(guò)對(duì)接口訪問(wèn)的路徑/入?yún)⑦M(jìn)行打印的情況，而且是默認(rèn)全局的，沒(méi)有做好數(shù)據(jù)脫敏；
2、觀點(diǎn)二屬于數(shù)據(jù)管理問(wèn)題，
3、確實(shí)有部分項(xiàng)目，甲方要求在回傳password時(shí)不能使用明文

結(jié)論

數(shù)據(jù)脫敏、數(shù)據(jù)管理等問(wèn)題無(wú)法通過(guò)單一手段進(jìn)行加固，需要完善安全管理，更建議采取2FA等方式。

不推薦的做法

1、前端在HTTPS下實(shí)現(xiàn)自己的對(duì)稱/非對(duì)稱加密，重復(fù)實(shí)現(xiàn)HTTPS所做的工作
2、前端采用不安全的摘要算法進(jìn)行數(shù)據(jù)處理，例如md5

常規(guī)的做法

1、前端回傳明文，后端使用sha256crypt/sha512crypt/bcrypt等摘要算法保存摘要結(jié)果，結(jié)果中包含了隨機(jī)添加的salt
3、每次請(qǐng)求時(shí)讀取salt進(jìn)行hash計(jì)算，進(jìn)行摘要結(jié)果匹配，以判斷password正確性

在有合規(guī)需求時(shí)的做法

1、前端使用“用戶名+自定義字符串”作為自定義鹽，添加至原有的password
2、前端使用sha-256/sha-512等足夠安全的摘要算法，將hash后的結(jié)果傳遞給后端
3、后端拿到前端結(jié)果后，使用傳統(tǒng)的 sha256crypt/sha512crypt/bcrypt 處理后保存

關(guān)于自定義salt

“用戶名+自定義字符串”：

• 前者對(duì)于每個(gè)用戶都是不同的，不同系統(tǒng)下可能是相同的，
• 后者對(duì)于所有用戶都是相同的，但是在不同系統(tǒng)下必須是不同，

這樣生成的鹽，在每個(gè)用戶的每個(gè)系統(tǒng)下都是不同的，增加了彩虹表攻擊的難度，能在一定程度上減少用戶被撞庫(kù)的風(fēng)險(xiǎn)。