# 如何兼具人性與安全的管理密碼？

###### tags: `問題討論` `專題發表` `密碼` `會員系統` `資訊安全`

## 所謂「安全的密碼」？
若從資訊安全的角度，會建議取的密碼「愈複雜愈好」：
- 除了常見的**長度**(**至少8字元**，甚至允許的話[**拉得更長更安全**](https://www.techbang.com/posts/78988-experts-tell-you-that-even-setting-the-password-to-jk8vge4d-is-still-not-secure))、**包含英數大小寫，甚至特殊符號**(**!@#$之類的**，但部分平台因避免惡意程式碼注入等考量不允許)
- [比起嚴格要求大小寫與符號的亂數組合，拉長字數且有語意的密碼，會比短的亂數符號組合好記憶，但也不至於容易被猜出](https://buzzorange.com/techorange/2017/08/10/strong-password-useless/)
- 但愈長愈複雜的密碼，理論上還是愈難破解而相對安全([圖表示意](https://3c.ltn.com.tw/news/48218))
- [若以記憶性來看，密碼主體可以考慮用特殊意義的英文句子](https://www.techbang.com/posts/78988-experts-tell-you-that-even-setting-the-password-to-jk8vge4d-is-still-not-secure)
- 且最好**不包含帳號文字與個人資訊**(姓名、身分證字號、生日等容易取得用來猜測組合的字詞)，也盡量**避免明顯常用語句(如"I love xxx"之類的)等規則**可循
- **甚至每組帳號對應的密碼皆不同**(避免其中一組外洩後，被輕易在其他網站服務上也盜用)
- 此外，如果擔心密碼記不住，或是必須與他人(內部團隊)共用，而**需要以明碼紀錄的話，也需注意避免被外人竊取**，常見記錄方式：
- **紙本**實體：**便條**、紙張甚至**筆記本(多組的話)**
- 妥善收好別亂放的話，幾乎不會被盜取
- **數位**軟體：獨立的**密碼管理器**，或**瀏覽器內建的密碼記錄**功能
- 現代更常見與便利的方案，甚至能自動產生與填入
- 只要確保密碼管理紀錄的軟體本身安全即可
- **若要更進一步加強安全性，甚至還得定期更改密碼**，可讓外泄的密碼因時效性降低風險(高機敏的帳密較常被要求)
- [一些看似有考慮安全，但做得不夠其實NG的範例](https://www.ithome.com.tw/news/144249)
- 細節可參考[台灣教育部的資安文宣建議](https://isafe.moe.edu.tw/sites/default/files/03_%E5%AF%86%E7%A2%BC%E8%A8%AD%E5%AE%9A%28%E4%B8%80%E8%88%AC%E6%B0%91%E7%9C%BE%29.pdf)
- 或是[更進階的密碼設定與保存建議](https://iqmore.tw/create-hacker-resistant-password)
- 其他：**搭配額外手段**(如二階段/兩步驟驗證**2FA**或動態密碼**OTP**)，甚至改採**生物識別/辨識（Biometric）**(如指紋或臉部)或**實體金鑰**(如U2F)，能避免或繞過只用密碼而被盜的風險

## 使用者的角度：安全與便利的平衡點？
### 密碼使用的惰性難以抵抗...
- 使用大量的安全措施，其實**違反人性與人類記憶能力**...
- [誤用安全規則或理解不夠的話](http://n.sfs.tw/content/index/14777)，反而可能搞出[人類難以記憶卻容易被電腦破解的「**偽安全**」密碼](https://www.ithome.com.tw/news/116127)
- 理想上每組密碼應該要不一樣，但實際上除非註冊使用的服務很少，不然**不可能全部直接記住**...
- 因密碼難以記憶而用外部的管理器或紙本等工具，反而又會受制於工具，等於**你自己也不知道密碼**，甚至工具因漏洞或保存不當外洩時，無法在第一時間得知與處理...
- 至於定期更改密碼，既使因要求而執行，實際上卻可能**怕麻煩而沒有徹底更改**(如只變動一小部分)，更別提可以不用改還**懶得改**的情況，效果因而大打折扣...
- 另外，若加上2FA、生物識別、U2F等額外手段搭配驗證，不僅開發與維持服務的**成本上升**，用戶也需要**更多的硬體**搭配...
- 題外話，如果網站服務有忘記密碼重設功能，對總是忘記(或不想記)密碼的人來說，算是變相的OTP...？
### 可能的折衷思路：公、私鑰的區分與結合
- **受非對稱式加密啟發**
- 比起固定的密碼，自訂[固定的密碼**規則**](https://alittlepro.com/522/how-to-create-a-safity-rememberable-and-different-password-for-every-single-login/)更重要
- 試圖兼具人性與安全，在二者之間求平衡，且保留取捨的調整性質
- 將個人取密碼的策略調整成**二個字串的組合**，
- 類似非對稱式加密區分**公私鑰**的方式，
- 公鑰：**對應**註冊服務的**名稱**
- 簡易的作法，直接取服務名稱的英文版，或網頁的網域名稱
- 進階的話則用英文服務明再進一步變化(搭特定規則改寫)
- 因為**看到服務名稱可直接聯想到**，甚至是直接挪用，因此算是「公鑰」
- 私鑰：以**安全規則**設的密碼
- 遵守本文第一段「安全的密碼」所設置
- 沒信心的話，可以到[這個網站測試得花幾年破解](https://www.security.org/how-secure-is-my-password/)
- 因為這組密碼**理論上只有你(或少數人)知道**，因此算是「私鑰」
- 實際密碼的產生組合：將密碼的公鑰與私鑰部分，用特定規則放在一起
- 因為在個別服務註冊的每組密碼，都有根據服務名稱變化的公鑰，**可以達成最基本的帳號密碼不重複要求**
- 基本版：除公私鑰的先後放置順序，也可以在二者之間**加上特殊符號區隔**(較為直觀好用)
- 舉例：如在Facebook使用"!4f6#6JL5@facebook"、Google使用"!4f6#6JL5@google"
- 上述為私鑰(!4f6#6JL5)+特殊符號(@)+公鑰(facebook/google)的組合
- 進階版：將公鑰或私鑰的**部分穿插**在另一部分，甚至實際使用的是公私鑰**組合後再加密或雜湊**的結果(更能保障安全但也繁瑣，願意隨時準備產生密碼需要的工具的話)
- 限制：仍不改密碼的本質
- 儘管這招較容易產生好記可變化且算安全的密碼，也不是絕不可能外洩或被猜出(儘管機會很低)
- 仍需要妥善保管密碼，且真有高機敏必要的話仍需再加上定期更改、配合額外驗證方式或生物辨識/實體金鑰等常規方式加強安全

## 應用服務的角度：應如何處理使用者密碼？
### 前端(Client)：格式的提示與檢查

- 以表單(form)下`type=password`的`<input>`標籤輸入送出
- 關於設置密碼的規則與建議
- 如果強調安全性，可以將[上述常見的密碼規則敘述](#%E6%89%80%E8%AC%82%E3%80%8C%E5%AE%89%E5%85%A8%E7%9A%84%E5%AF%86%E7%A2%BC%E3%80%8D%EF%BC%9F)加到註冊頁面的提示
- 甚至實作密碼強度驗證，避免使用者設置明顯不安全的密碼
- 如最短長度、是否兼具數字與大小寫，甚至必用特殊符號
- 建議在前端以JS實作(可用[正規表達式](https://developer.mozilla.org/zh-TW/docs/Web/JavaScript/Guide/Regular_Expressions)檢查格式)，而非發給後端處理再等回傳結果，可節省網路流量與等待時間
- 但除非有特殊需求或限制，否則某些額外的密碼字元與長度硬性限制，反而讓使用者無法依照個人習慣設密碼
- 像是長度上限(資料大小限制？)、不能使用特殊符號(防止惡意程式碼注入？)、只能用大/小寫或數字(PIN碼)......
- 可能讓使用者無法使用習慣的安全密碼規則，得額外記憶或只能交給密碼管理器
- 註冊的部分，通常會加上重複輸入密碼的驗證，強調密碼的重要性和協助確認、記憶(尤其沒提供其他登入方式甚至重設功能是)，也是在前端以JS實作效能體驗較佳
- 送出密碼時，切忌以明碼的方式傳輸，且需要一定的加密，否則很容易洩露機密資料！！！
- 以web的概念HTTP method(請求方法)來說，得使用POST而非GET
- POST可將資料藏在body，GET傳輸的資訊會直接顯示在URL
- 加密的部分，只要發送時使用HTTPS即有一定的安全性，可不用特別處理
- 有特殊需求的話，再另外使用其他加/解密方案(但不能用不可逆的雜湊)
### 後端(Server)：雜湊化儲存與驗證
- 既有帳號驗證 VS 暴力破解
- 由於註冊必須告知帳號名稱是否被使用，可能讓駭客透過洩露的帳號名稱在其他網站服務猜出攻擊目標
- 登入功能最好加上錯誤次數限制，避免被用電腦[窮舉所有字串組合暴力破解](https://zh.wikipedia.org/wiki/%E8%9B%AE%E5%8A%9B%E6%94%BB%E5%87%BB)
- 以不可直接還原的雜湊(hash)儲存使用者密碼
- 除非你想在背後做壞事(X)，否則資料庫直接被駭客侵入的話密碼會直接洩露
- 正常的網站服務其實不知道確切的使用者密碼，而是透過雜湊值與輸入的密碼比對來驗證身分
- 因此網站不能主動從資料庫得知使用者密碼明文(能告知密碼的網站反而危險要小心！！！)
- 至於重設密碼的功能，則是透過註冊時綁定的通訊方式(如電子郵件或手機號碼)，確認身分後暫時給予登入狀態來修改密碼(另類OTP的概念？)
- 即註冊時使用程式自動產生的複雜密碼(可不用記住)，每次登入時都選忘記密碼來重設，等於每次都靠email或手機號碼取得登入權限，然後再隨機產生新的密碼
## 補充
### 補充1：OTP與2FA
- OTP(一次性驗證登入)
- 簡單來說就是透過綁定身分的通訊方式給予一次性授權的密碼，使用後即失效
- 除非產生後即被攔截，否則更難暴力破解
- 概念細節可參考[維基百科的簡介](https://zh.wikipedia.org/wiki/%E4%B8%80%E6%AC%A1%E6%80%A7%E5%AF%86%E7%A2%BC)
- 2FA(雙重/兩步驟認證)算是MFA(多重要素驗證)較常見的例子
- 常見方式如以帳號密碼/第三方平台登入後，仍需要OTP再度驗證
- 可避免帳號被破解後馬上被更改篡奪，相當於多一道鎖
- 概念細節可參考[維基百科的簡介](https://zh.wikipedia.org/wiki/%E5%A4%9A%E9%87%8D%E8%A6%81%E7%B4%A0%E9%A9%97%E8%AD%89)

### 補充2：社群平台等第三方帳號登入
- 串接常見的社群帳號(如Facebook、Google)，其登入狀態可用於直接註冊新帳號，之後登入也可不用輸入帳密
- 若應用程式的開發為前後端分離，前端與後端的開發人員須溝通好串接的服務與方式
- 前端部分點擊後前往第三方平台的登入頁面，首次使用還會有授權確認，授權後即自動註冊帳號並登入
- 後端實作可使用基於OAuth 2.0的套件，如Laravel的Socialite和Express.js的Passport
- 第三方登入建立的帳號若無特別設計，其實沒有帳戶對應的密碼(或使用者不知道)，無法也使用傳統帳密登入
- 若考慮讓同一組帳號能使用不同方式登入，則需要讓第三方登入註冊的使用者能另訂密碼，甚至還能綁定其他的第三方帳號

### 補充3：重點摘要與問題討論
- 本文首次於2022.02.17的Monosparta Tech Day發表
- 當日參與者有另外整理摘要筆記，以及分享會後的討論紀錄
- 連結：[https://hackmd.io/52E3iLFaRm2g9eUpHIG66Q?view](https://hackmd.io/52E3iLFaRm2g9eUpHIG66Q?view)