應該把API的祕密加密了嗎？

Question

這可能聽起來像一個愚蠢的問題，因爲密碼當然需要被散列並且永遠不會存儲原始密碼。

但是，對於API機密，通常我會在註冊時看到它們以清晰的方式顯示。

例如，如果我轉到google api控制檯並查看我的憑證頁面，我可以查看我的客戶端密碼，與twitter相同。

當然api鍵和密碼一樣敏感嗎？

僅僅是因爲從提供者方面，您可以確信生成了足夠強大的密碼？ 如果是這樣的話，那麼這不會提供任何保護是您的數據庫被泄露。

或者，也許是因爲如果你使用基於令牌的認證，你要麼做密碼授權類型，這需要你發送你的憑證以及客戶端ID和密碼，或刷新令牌，所以用戶會已經不得不妥協了？

Answer 1

我可以想像一些可能的答案是：

• 在某些情況下，可能需要讓服務器有明文API密鑰的持久存儲，以滿足可用性需求（谷歌和Twitter作爲例子）。
• 在某些情況下，API密鑰本身並不足以完成很多工作 - 另外需要擁有一個經過身份驗證的帳戶 - 因此API密鑰本身的價值有限（因此密碼的價值較低） 。
• 在許多情況下，API密鑰在客戶端應用程序中硬編碼（特別是移動應用程序，它幾乎總是這樣做），因此在相同標記可以在服務器端添加額外保護時沒有意義從客戶端瑣碎地提取。
• 安全行業尚未成熟。也許一旦黑客開始傾銷API密鑰，這樣的想法可能會更加嚴肅。

順便說一句，我對最後一點非常認真。事實是，許多好的想法只有在他們背後有大量的支持時纔會成爲現實。舉例來說，我曾經在一篇相關話題 - protecting user confidential information by hashing it in the database上發表了博文，但是以合法用戶登錄時可以恢復的方式發佈。我使用Ashley Madison作爲例子 - 在這種情況下，黑客更多地使用電子郵件地址，電話號碼和物理地址，而不是密碼。因此，當黑客搶走數據庫時，他們立即擁有了他們想要的東西，並且他們可以不太關心bcrypt編碼的密碼（事實上，一些較舊的密碼只用MD5編碼！）。不幸的是，這樣的概念沒有足夠的推動他們成爲現實。即使是零知識網絡設計在現實世界中也很少。