我看到它的方式（不將密碼存儲在Git（或其他版本控制）中）是一種慣例。我想一個人可能會決定不以各種結果來強制執行它，但是這就是為什麼人們對此一無所知的原因：

1. Git使您難以從源代碼歷史記錄中刪除密碼，這可能會給人以錯誤的印象認為密碼已在當前版本中刪除。
2. 通過將密碼置於源代碼管理中，您基本上決定與可以訪問該存儲庫的任何人（包括將來的用戶）共享密碼。這會使在開發人員團隊中建立角色（可能具有不同的特權）變得複雜。
3. 源代碼控制軟件往往變得非常複雜，尤其是“多合一”系統。這意味著該系統可能最終會受到威脅，從而導緻密碼洩漏。
4. 其他開發人員可能不知道密碼已存儲，並且可能會錯誤處理存儲庫-源中包含密鑰意味著要格外小心共享代碼時（即使在公司內部，也必須這樣做；這可能需要加密通道）。
ol>

我不能說與infosec相關的每個模式都是好的，但是在破壞它們之前，最好考慮一下威脅模型和攻擊媒介。如果這個特定的密碼洩露了，攻擊者使用它來傷害公司會有多困難？

首先，非安全性原因：

密碼更改工作流程

密碼更改獨立於軟件應用程序代碼。如果DBA更改了數據庫密碼，那麼開發人員必須更新代碼，重新構建並發佈到生產環境並嘗試安排所有時間是否有意義？密碼是運行時配置工件，而不是開發工件。應該通過配置文件，環境變量或您使用的任何配置範例注入它們。

授權範圍

通常，版本控制系統提供授權控制因此，只有授權用戶才能訪問它。但是在存儲庫中，權限通常是讀/寫或只讀的，或者可能像GitHub提供的一樣。您不太可能找到允許開發人員獲取源代碼的安全約束，而不是密碼。如果可以克隆存儲庫，則可以克隆存儲庫。期。在許多環境中，開發人員無法完全訪問生產。有時他們具有對生產數據庫的只讀訪問權限，有時沒有訪問權限。如果開發人員通常確實具有訪問權限，但是您不希望所有實習生，新員工等都具有訪問權限，該怎麼辦？

環境

如果您有多個環境，例如開發環境，QA環境，登台和生產，該怎麼辦？您會將他們的所有密碼存儲在版本控制中嗎？該應用程序如何知道要使用哪個？該應用程序將需要一種了解環境的方法，最終將其作為配置設置。如果可以將環境名稱設置為配置設置，則可以將數據庫密碼設置為配置設置（以及連接字符串，用戶名等）。

歷史記錄

正如其他人提到的那樣，版本控制旨在保留歷史記錄。因此，較舊的密碼仍然可以檢索，這可能不是最好的選擇。

妥協

在某些產品的源代碼洩露給全世界的新聞中，我們看到過多少次頭條新聞？源代碼是版本控制中的任何內容。這可能是不將密碼放入版本控制中的首要原因！

但是...

也就是說，密碼需要存儲某個地方。上面提到的這些隱患不一定意味著它們根本不應該存儲在版本控制中，而是應該不存儲在版本控制中的產品的源代碼存儲庫中。為配置管理，操作等使用單獨的存儲庫是非常合理的。關鍵是要在安全性憑證方面將操作與開發分開，而不必完全避免版本控制。

此外，對於非生產環境，我將用於外部系統的密碼和API密鑰存儲在產品源代碼中的默認配置文件。為什麼？為了使開發人員在簽出代碼時不費吹灰之力，他們只需構建並運行它即可，而不必獲取額外的配置文件。這些憑證很少更改，不會導致任何商業秘密。但是我永遠不會用生產機密來做到這一點。

所以最重要的是……這取決於。

切記，必鬚根據您的用例量身定制建議，這始終很重要。例如，美國國家安全局（NSA）為保護他們在下雨天所停留的所有零日時間而採取的安全措施應比為保護貓圖片張貼站點上的投票所採取的安全措施嚴格得多。在一個極端情況下，我可以考慮一個示例，將密碼/令牌/等保存在私有git存儲庫中可能是合理的：

如果該存儲庫只能由一個人訪問並且應用程序不存儲任何存儲空間任何值的信息。

在這種情況下，請前往城鎮！只需記住@ d33tah在回答中所說的內容-從git存儲庫中清除內容可能會非常困難（畢竟，要永遠保留所有內容的歷史記錄），因此，如果您決定繼續前進，與更多的人合作，但是不希望他們獲得對您所有系統的完全訪問權限，那麼您的頭上會有些頭疼。

這就是真正的問題。至。您的代碼存儲庫在某種程度上是“公共的”，即使僅與協作者共享。僅僅因為您想與某人合作並不意味著要向他們授予對您的基礎結構的完全訪問權限（實際上，這是將密碼/令牌放入代碼存儲庫時發生的情況）。很容易想到“是的，但是我信任與我合作的人！”，但是出於多種原因，這只是看待情況的錯誤方法：

1. 在實際操作中，很大一部分數據洩漏始於內部參與者（合作者，員工）。根據一項研究，大約有43％的數據洩露是由內部參與者發起的。其中有一半是故意的，有一半是偶然的。
2. 最後一點很重要，為什麼這不僅僅與信任有關。大約20％的數據洩露是偶然的，是內部人員造成的。我很聰明，知道我不夠聰明，無法始終保持一切正常。如果我公開我的存儲庫以為一些有趣的集成工具騰出空間，而忘記了我的證書怎麼辦？如果我有一個忘記加密的備用硬盤驅動器從辦公室走了怎麼辦？如果我的密碼之一泄露了，有人用它來猜測我的git存儲庫（咳嗽 gentoo github存儲庫咳嗽）中的帳戶密碼怎麼辦？ 我可能會發生許多意外錯誤，這可能會導致我的git存儲庫暴露出來，如果發生這種情況，並且我在其中和找到他們的人知道他們在看什麼，我很可能會被抓住。這聽起來很像和，但事實是，這就是違規行為的發生方式。
3. 即使我信任某人，也並不意味著我必須付出他們完全可以使用所有內容[插入俗氣的有關電源如何損壞的報價]。同樣，將憑據放入git存儲庫意味著我有可能將所有基礎架構的全部訪問權限授予所有協作者。總是有可能您不認識您，也不如您想像的那樣，他們可能會決定做一些本不該做的事情。即使您親自認識並信任每個協作者中的每個人，但這並不意味著他們不會犯上述錯誤（或我沒有提到的無盡選擇）中的一些意外釋放您的代碼。
ol>

簡而言之，良好的安全性是關於分層防禦的。大多數黑客之所以發生，是因為黑客在一個區域發現了漏洞，從而使他們可以利用另一個領域的弱點，從而導致了其他地方的困境，最終使他們獲得了大收益。確保您的情況有意義的盡可能多的安全保護措施可以確保整個過程的安全。這樣，當備份硬盤驅動器走出您的辦公室時，您意識到它沒有被加密，您不必問“這是否是有針對性的攻擊，我現在是否必須更改我到處都有的每個憑據，因為它們都在備份驅動器上的git存儲庫中嗎？”。同樣，根據您的情況，這可能不適用於您，但是希望這可以幫助您說明在什麼情況下這可能很重要。

保持與源代碼分離的機密（密碼，證書，密鑰）可以根據不同的策略管理源和機密。就像所有工程師都能閱讀源代碼一樣，只有直接負責生產服務器的人員才能訪問這些機密。

這使開發人員的工作更加輕鬆，因為他們不受嚴格的安全策略約束。需要保護秘密。可以使源代碼控制策略更加方便。

與許多其他安全“最佳做法”一樣，此約定是一種確保不會因不良習慣或例行公事而出錯的簡便方法。

如果您始終記得您的敏感密碼在版本控制系統中，並且如果，您從不授予不應訪問該存儲庫密碼的人，並且如果存儲您的存儲庫這些秘密所要求的一樣安全，並且如果，您的部署過程同樣安全，受到保護並不受未經授權的人員的保護，並且如果，您可以確保存儲庫的所有備份和副本是，並且...您可能還可以添加更多特定於上下文的“ if”。

...然後，您可以將密碼很好地存儲在版本控制系統中。

在大多數情況下，這些“如果”中的至少一個不完全符合您的條件，或者超出您的控制範圍。

例如，在許多設置中，開發人員應該無權訪問生產數據庫。或者將備份系統外包給另一個部門。或將您的構建過程外包到雲中。

這就是為什麼通常不將密碼存儲在版本控制系統中的最佳做法，可確保您不會落入這些陷阱之一，因為您沒有考慮它們。比起在版本控制下安全存儲密碼所需滿足的一長串條件而言，“ git中沒有密碼”更容易記住。

其他答案很好，但也要考慮備份問題。如果代碼存儲庫備份不包含有關如何訪問服務器或管理員帳戶的敏感信息，則可以更靈活地存儲代碼存儲庫備份的位置，方式和時間。

從另一個更高的安全性-集中的角度來看，只是您的代碼備份可能是您業務中不道德競爭者的有趣目標。根據您的業務，“法治”國家/地區中的大多數競爭對手都不會碰它。密碼 密碼備份將成為對您的用戶數據感興趣或對勒索您的公司感興趣的任何犯罪組織的目標。

由於違反代碼存儲庫而造成的損害是出於類似原因，請使用密碼。您是要竊取和發布源代碼，還是讓所有用戶遭受身份盜竊，可能因無法保護其私人數據而對您提起訴訟甚至刑事訴訟（例如GDPR）？

“當我們遠離文明生活時，為什麼直接將鑰匙直接放在大門上真的有那麼糟糕？”

因為想做壞事的人會做事容易，為他們努力的代價不是太高。隨身攜帶鑰匙，不要靠近門。常識。

私人回購？有多少人可以下載它？多少人連接到其計算機？然後……他們都擺脫了危險嗎？

這也取決於源代碼控制系統。

Git的態度是源代碼控制系統應為您提供可靠的項目歷史記錄。擁有一個不錯的態度。但是，結果是，如果您將密碼簽入git，很難將其從存儲庫中刪除。

為此，Perforce有一個“ obliterate”命令。如果您簽入了密碼，或者有人簽入了8 GB未壓縮的視頻文件，或者有人簽入了某些侵犯他人版權並且永遠都不應被簽入的第三方代碼，或者被解雇了許多色情內容，他們上班的最後一天，您可以“抹去”它。它已完全從存儲庫和歷史記錄中刪除。