網站前端打 API 時把密碼加密，有意義嗎？ - Huli's blog

[utterances-bot]

網站前端打 API 時把密碼加密，有意義嗎？ - Huli's blog

最近有人在臉書前端交流社群發了一則貼文，內容是他看到了一個問題：請問登入api傳賬號、密碼json明碼會有問題嗎?，想知道大家對這個問題的看法。 而底下的回答大部份都是覺得「有用 HTTPS 就好了，沒必要額外再實作一層加密，沒有什麼太大的意義」 老實說

https://blog.huli.tw/2023/01/10/security-of-encrypt-or-hash-password-in-client-side/

[gjlmotea]

剛好在想這個問題 讚讚，寫得很清楚

[aszx87410]

@gjlmotea 感謝留言，希望有幫助到你的思考

[dannypc1628]

舉例來說，假設我有個搶票 App 不想讓別人知道 API 怎麼呼叫，於是就實作了一個超複雜的加解密機制，儘管高手還是可以做逆向工程，寫出一個搶票機器人，但這個機制增加了他的時間成本以及對技術的要求。

我想了一下，若有個複雜的加解密機制，我也是寫成function，要用的時候就cell一下。對逆向工程的人來說，他們只要分析出 cell 那支 function 就好了。其實不用花時間了解我寫的又臭又長加解密機制…

[aszx87410]

@dannypc1628 這個倒是不一定，你說的狀況前提建立在「function 很好找到」以及「攻擊者最後是用同個環境」，以網頁為例好了，假設有一個叫做 sendRequest() 的 function 裡面會做一堆加密再送出，找到 sendRequest 以後攻擊者確實只要 call function 就好了。

但若是攻擊者想用 Python 或是 Go 寫攻擊腳本呢？就沒辦法了，甚至要用 JS 寫腳本可能也沒辦法，因為原本 sendRequest 裡面很有可能再去呼叫其他函式或是有其他依賴，不是複製出來貼上就可以用。如果要在其他環境執行相同動作，就是要把 sendRequest 的 code 重寫一遍，這重寫的過程基本上就是在了解加解密機制了

再者，這邊所說的「這個機制增加了時間成本」的比較基準其實比較像是跟直接 proxy 看封包來比較，若是沒加密的話，直接從 proxy 就可以看到 API 的每個參數跟名稱，快又方便。但如果有加密，攻擊者勢必要逆向工程並且找到 sendRequest 這個 function，光是要找到這個 function 所需的時間應該就比直接看封包多很多了

[Yen0422]

太感謝了，解決我思考好一陣子的問題

[M4n5ter]

在大陸高校內，校園WiFi會監控所有流量，一些人經常訪問被大陸遮蔽的網站時會被校園警察約談，這種情景下前端沒有加密的話，給人一種擔心的感覺

[fuergaosi233]

很好的文章， 再补充一个，在开启 HTTPS 后， 也要记得开启 HSTS/SSL Pin

[kaichii]

写得非常清楚，👍

[yoyo930021]

昨天研究了一下，現在其實不太推繼續用 SRP，建議改用 OPAQUE https://www.cryptologie.net/article/503/user-authentication-with-passwords-whats-srp/

[aszx87410]

@yoyo930021 感謝補充，這塊我還沒有仔細研究，已經先將參考資料加進文章裡面

[HowardCsie]

想補充一下，任意兩種 hash 組合過，有可能遇到 low entropy 的問題 https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html https://blog.ircmaxell.com/2015/03/security-issue-combining-bcrypt-with.html

[aszx87410]

@HowardCsie 感謝，已經補充進去文章

[game0416]

對了一下發文時間，應該是因為網銀去年中改規定推行，所以網銀都有實作。https://www.rootlaw.com.tw/LawArticle.aspx?LawID=A040390051065000-1110602&ShowType=Ref&FLNO=10000

[aszx87410]

@game0416 感謝提供資料來源，已經加進去文章裡面了

[Jeffrey0117]

2023的胡立大大文筆跟鬼一樣 清晰好懂 華文圈的驕傲 太扯太屌 學習了!!

[aszx87410]

@Jeffrey0117 感謝支持XD