CZ 🔶 Binance on Twitter

那個accesskey是真的很複雜啦⋯⋯

借轉

跟複不複雜無關，這類的 id-key pair （等同於帳號與密碼）都是隨機產生的，而且大部分產生這個 key pair 的流程設計都只有在產生當下才能看到完整的 id/key，之後遺失就只能產生新的（通常舊的就會刪除），基本上是靠這個流程維護安全性。

這次資料流出的事件，是在於有人直接在自己的文中中把這個 key-pair 貼出來，等於是把帳號密碼詔告天下。

喔喔喔喔OAO!

應該要講一下這類 key pair 的用途 XD。我們一般登入網站服務都是使用者與網站互動式 (interactively) 的輸入帳號密碼做認證。但是很多時候我們需要把這個動作程式化、自動化，就需要一個有別於使用者帳號密碼（但是意思差不多）的東西來跟服務認證，因此才會需要產生這個 key pair。

像是噗浪機器人也是使用在這個頁面產生的 api key 做認證，而不是使用者帳號密碼：

Plurk sign in - Plurk

文件：
Plurk API 2.0

原來如此！

這樣應該就可以進一步解釋一下他們犯的錯在哪裡。這個使用情況，可能就是比如說在 A 主機跑的服務，會需要這個 key pair 去跟 B 主機上面跑的另一個服務要資料。我們在實務上會透過一些別的方式讓在 A 主機跑的程式從別的安全的地方讀取這個 key pair，盡可能避免把這個 key pair 寫死在程式裡面。

很明顯的：
1. 有人把這個資訊寫死在程式裡面，可能是沒有概念，又或者是偷懶、偷工
2. 沒有人在 code review 上發現或認為這是一個問題

這都是非常嚴重的錯誤。阿里巴巴也犯過類似的錯，還把程式碼發布到 GitHub 上，幸好裡面的 key 只是測試用的，所以沒有造成太嚴重的後果。

這邊就有好人會巡水田四處提醒：

yihong0618 on Twitter

真是好人XDDDDDDD