達人專欄今天再來跟大家聊個跟帳號安全相關的議題吧。
。在木馬程式面前，密碼再強大都沒用？
從 2000 年到大約 2015 年，這個年代對於網路使用者而言，最大的惡夢應該就是「木馬程式」了。在那個免洗手遊尚未崛起的 PC 線上遊戲顛峰時期，我們都可能曾經遇過在朋友家登入楓之谷帳號僅僅玩個十分鐘，回到家就發現角色的裝備已經被移到自由市場脫光光的尷尬狀況。
對於應該要如何設計自己的密碼，我們在先前講網站密碼外洩的主題已經談過。像是剛才提到的楓之谷，我們可以設一個比如「服務名稱後四碼 + 固定的隨機六碼 + 生日年份」這樣的組合字串作為密碼，像是「toryTy^a5Z1997」。
我們還說過，如果要做得更加極致，可以選擇一個可以信任的密碼管理服務來專門儲存你所有服務的密碼，並且把密碼設得更加隨機、更加複雜，甚至到難以記憶的地步。
這樣的密碼如果只考慮到「伺服器密碼外洩的時候不會波及到你使用的其他服務」、「不會被人用暴力破解或字典攻擊猜出來」這兩點，確實是非常安全的。然而現在問題來了，這裡所謂的安全也僅僅是建立在「你的電腦環境也非常安全」的狀況下——你能保證你正在使用的電腦裡沒有任何木馬程式正在監視你的一舉一動嗎？
木馬程式是可怕的。它們時常偽裝成各種好用的免費程式，趁著你安裝的時候偷偷注入一份供駭客使用的後門到你的系統裡，每次開機的時候就默默地執行，過程總在渾然不覺。通常一個駭客設計木馬程式的時候，可以有以下的做法：
1. 側錄滑鼠和鍵盤，把你每個按過的按鍵順序記錄下來傳送到他的伺服器上
2. 側錄剪貼簿，把你曾經複製過的字串傳送到他的伺服器上
3. 竄改你的環境，例如讓電腦顯示釣魚網站騙你輸入密碼，傳送到他的伺服器上
這會造成一個結果：即使你把密碼設得再長、再複雜，你最後總要透過鍵盤輸入密碼或是利用剪貼簿把那串超長的密碼複製到密碼輸入欄上面，那你的密碼對駭客來說仍然和 123456 沒有什麼不同。
。動態密碼技術的演變
為了解決這樣的問題，我們需要使用動態密碼的技術。其實不管你願不願意，你一定曾經使用過動態密碼。在網路上註冊帳號的時候，服務提供者通常會傳送驗證碼到你的手機上面，當你輸入了正確的驗證碼，才能夠向網站充分證明你確實是本人。
當然上面這種一次性的驗證碼還算是易於理解。以前你可能曾經為了保護帳號而向遊戲廠商買過動態密碼卡：
首先廠商印製並儲存成千上萬張這樣的卡，每一張卡的序號跟表都不一樣。在你購買了這張卡之後，到官方網站申請實裝。比如說，廠商會要求你輸入卡片的序號跟其中的第 29 組密碼，那你輸入了 15677789611 和 4779，廠商經由比對而知道你確實買了這張卡，並且幫你的遊戲帳號「上鎖」。
從此之後，當你要登入遊戲帳號時，登入畫面隨機指定要你輸入表上的第 X 組密碼，只有在你輸入了表上正確的密碼，你的登入行為才是有效的。這樣一來，駭客即使知道了你的帳號密碼，也就更難直接登入你的帳號。
但是這樣的設計有個誤區：如果駭客經由側錄得知了你表上的其中一組密碼呢？這張表只有 64 組密碼，那麼駭客透過這張表上的其中任一組密碼成功登入帳號的機率，就高達 1/64。也就是說，只要他從早到晚不斷嘗試，他總能成功至少一次。所以一般這樣的機制，通常會搭配「短時間多次嘗試登入則暫時封鎖 IP 地址」的配套防護措施。
我們可以在較早期的遊戲看得到這樣的設計，例如 2004 年在臺灣開始營運的亂 Online 所提供的「守護卡」服務。
這種密碼表的基礎經過拓展之後，就成了遊戲橘子的 GAMAOTP 防護機制。遊戲橘子的做法是先產生一個隨機數作為種子，存到手機的 App 裡面，安裝到手機裡面之後在手機裡用這組固定下來的隨機數和系統隨機要求的編號來計算出動態密碼。
這種做法當然就比較靈活，因為它不像實體的密碼表一樣了不起只能放個幾十組，而是可以設計成想要幾組就有幾組。以遊戲橘子的 GAMAOTP 來說，它可以提供大約一億組，所以相較之下安全性就會高出許多。
每次登入的時候系統要求你輸入的密碼都不一樣，這就是我們平常在講的 OTP（一次性密碼，one-time password）了，你也可以說它是一種兩步驟驗證（2FA，two-factor authentication，即雙因子認證）的實作。
。現代的兩步驟驗證技術
無論是上面提到的這種守護卡，還有遊戲橘子的 GAMAOTP，兩者都有缺點。例如，守護卡本身是實體的，不環保又占空間；GAMAOTP 的演算法是獨有而無法和其他服務互通的，為了一個遊戲帳號而獨立安裝一個手機 App，用起來有點麻煩。
於此，世界上有了一個被廣泛使用的 OTP 業界標準：RFC 6238。
這個標準所利用的素材就是「時間」。RFC 6238 的做法非常簡單，首先網站服務產生一組作為種子密鑰的英文字串，讓使用者自行保存。
接著依序做以下的固定步驟：
1. 把密鑰字串經過 base32 解碼（註 1），轉換成一串數字，為 k
2. 取得目前的 Unix 時間（註 2），除以 30，然後無條件捨去，為 t
3. 利用 k 和 t 作為素材，以雜湊函數 HMAC-SHA1 計算得到一組雜湊值 h
4. 把 h 的一部分抽出來，經過處理得到一個 0~4294967295 範圍的數字 n
5. 把 n 除以 1000000，得到一個 0~999999 範圍的餘數，即為驗證碼
註 1：base32 編碼可以把一組由 A~Z、2~7 組成的字串轉換成一組 byte array
註 2：Unix 時間指的是從 1970-01-01 00:00:00 起經過的總秒數
簡單來說就是透過密鑰和現在的時間，用固定的算法得到一個六位數。因為第二步驟是把總秒數除以 30 後無條件捨去，所以這個六位數驗證碼每隔 30 秒就會變換一次，在這 30 秒期間驗證碼不會變動。
採用這個方案的服務當中，最廣為人知的就是 Google Authenticator。既然這個演算法是公開的、所有人都可以使用的，那麼所有的遊戲廠商、網站業者通通都可以利用這個方法，以極低成本簡單地建置出一個 OTP 的系統。
假設我是網站的業者，我希望讓你能夠幫你的帳號加上一層動態密碼鎖，那我只要產生一組合規的隨機字串給你，我們兩邊同時把這組字串保存下來。在這之後當你想登入帳號，就使用上面的步驟計算出驗證碼，隨著帳號密碼一起傳送過來。只要我們算出來的驗證碼結果一樣，就說明你輸入的驗證碼是有效的了。
當然前提是你的時間是準確的。只要能確保計算的素材一致，算出來的結果也就會相同，自然也就不需要憑靠任何網路連線了。
。採用 RFC 6238 的業者
非常多。我們生活中常常用到的服務諸如 Discord、Dropbox、Facebook、Google、Microsoft、Twitter……這些網站都可以啟用兩步驟驗證的服務，而且可以直接使用 Google Authenticator 這樣的 App 來即時計算出驗證碼。
巴哈姆特同樣也適用這項標準。我們只要打開小屋的帳號安全設定頁面，就可以啟用兩步驟驗證，讓帳號的安全性提升一百萬倍。不過像是 Garena 跟 Steam 就比較可惜，他們採用的驗證碼是遵循自家標準，使用的時候就得額外安裝他們自己開發的 App，我個人覺得這種獨立方案很擾民。
其實這個技術早在 2005 年就已經正式發布了。得益於智慧型手機的發展和 QR code 技術的普及，現在人人都可以輕易地把這串密鑰存到手機裡，自行產生驗證碼。有些業者會直接給你純文字形式的字串，有些業者則是會先把這個字串轉成 QR code 的形式，讓你能夠只憑手機鏡頭存下密鑰而省下手動輸入到手機裡的麻煩。
不過，使用兩步驟驗證的時候也要注意，取得這份 QR code 或密鑰字串的同時，最好也找一個安全的地方把它備份下來，畢竟你的手機總有無預警損壞的風險。要是手機損壞導致你遺失了這份種子密鑰，那就反而會成為一件麻煩事。
就我的網站使用習慣來說，除了使用至少 20 位的大寫英文 + 小寫英文 + 數字 + 特殊符號的隨機組合作為登入密碼以外，我還會把所有能綁的帳號全都加上兩步驟驗證，至少到目前為止還沒遇過被盜用帳號的情形。如果擔心網站帳號被盜用，不妨替自己的帳號加上兩步驟驗證的保護措施吧。
