# 敏感資料 - 傳輸與存放
今天心得這篇分享源自 [OWASP A02:2021 - Cryptographic Failures](https://owasp.org/Top10/A02_2021-Cryptographic_Failures/)，對於極度機密或者是敏感的資料在傳輸上缺乏加密機制，抑或是敏感資料的存放未加密和使用一些過時的演算法。

會列出其中的一些項目，佐以實例說明，做些探討與反思。

## Data transmitted in clear text
我們目前與網站之間的連線大多都為 https 與 http 連線的差異在於過程中的 message body 是有經過加密的，而每家 browser 都會在上頭加上對應的顯示，如果你的網站還在使用 http 或者是過時的加密演算法，上頭的鎖頭都會有警示，讓 end user 知道你的網站並不安全。

如果資訊傳輸的過程中沒有加密，任何攔下你封包的人都可以輕易閱讀其中的訊息，想像一下如果今天有一個服務的登入系統需要輸入帳號、密碼，而登入方式為以下這樣

http://timm.com/login?username=timm&password=timm_password

看到這邊你如果還沒有倒抽一口氣，算你厲害！
如果你認為沒有人是這樣在傳遞帳號、密碼的話，讓我找給你看看～
[米瑟奇簡訊](https://www.message.com.tw/api_manual.php)

建議不要使用帳號、密碼的方式作為 API 參數，改以 token 或者是 service account 來限制權限範圍，並且要設定時限內過期，以 https POST 包裹 request body 的機敏資料。
## Deprecated hash function
在開發過程中，常會使用到一些雜湊的演算法，e.g. `MD5` 大家一定都不陌生，但是加密、雜湊的演算法百百種，你知道哪些是目前容易被破解，哪些又是足夠安全的方法嗎？

有這種困擾的時候，就可以參考 [Clavister - cryptographic algorthms recommendation](https://www.clavister.com/services/resources/cryptographic-algorithms-recommendations/)
先找出自己打算採用的演算法，對照目前是否推薦使用（足夠安全），若不夠安全，則可以考慮後方建議的演算法替代。
## Sensitive data not encrypted
哈！這個最好玩了
不知道大家都是不是有設計過會員系統，或者是類似需要做帳號登入的服務。
身為一個 Backend Engineer 不免需要設計資料庫，和 CRUD 的功夫，所以看到下方這樣的 table 見怪不怪
| column | type |
| -------- | -------- |
| id | int |
| name | varchar |
| password | varchar |
| address | varchar |

但不同的是，系統新註冊了一位使用者
name: `timm`, password: `timm_password`, address: `台北市信義區富豪路168號66樓`
你會選擇怎麼樣去把這筆資料放進 table 中，將資料敏感層級簡單分為三級（low、medium、high）
name (**low priority**)
password (**high priority**)
address (**medium priority**)

根據資料的敏感層級不同，越高級的資料，儲存的方式應該更小心，在存放進去的時候需要先經過加密。所以要可以存取到原始資料的人，必須要有資料庫、加密金鑰，兩者缺一不可才有辦法解讀。

但其中以密碼的性質尤其特殊，對資料加密，只要有金鑰還是能將訊息解開來，但如果我們對資料用途只有需要做一個 equals 的比對呢？這個時候就可以考慮只儲存資料的 hash value，這個過程無法像是加密一樣可逆，也就是你無法得知在這個訊息背後原始的訊息樣貌。

接著一定大家就會好奇了，我們怎麼知道對方是如何存放資料的呢？其實從某些地方可以觀察得出來

案例分享 - 老四川線上購物

當你輸入手機號碼，按下“寄送密碼”的同時

手機簡訊會收到你自己的 “密碼”，這樣就起碼知道了一件事，對方只要有心，他可以知道你的密碼原始樣貌。
也就是為何這麼多平台的忘記密碼，都只是寄送一組更新過後的隨機密碼或者是重新設定密碼的連結給你，而不是寄送原始密碼，因為他們根本無法還原這樣的雜湊資料。

###### tags: `blog` `security`