Các chiến lược bảo mật để lưu trữ mật khẩu trên đĩa

Question

Tôi đang xây dựng bộ công việc theo lô yêu cầu quyền truy cập thường xuyên vào cơ sở dữ liệu, chạy trên máy Solaris 10. Do ràng buộc thiết kế (không thể thay đổi), chúng tôi được yêu cầu sử dụng một chương trình nhất định để kết nối với nó. Giao diện được yêu cầu yêu cầu chúng tôi chuyển mật khẩu thuần văn bản qua dòng lệnh để kết nối với cơ sở dữ liệu. Đây là một thực hành an ninh khủng khiếp, nhưng chúng tôi đang mắc kẹt với nó.

Tôi đang cố gắng đảm bảo mọi thứ được bảo mật đúng cách. Vì quá trình xử lý được tự động hóa (nghĩa là chúng tôi không thể nhắc mật khẩu) và tôi không thể lưu trữ bất kỳ thứ gì bên ngoài đĩa, tôi cần một chiến lược để lưu trữ mật khẩu của mình một cách an toàn.

Dưới đây là một số quy tắc cơ bản hệ thống

1. có nhiều người dùng.
2. Chúng tôi có thể giả định rằng các quyền của chúng tôi được thực thi đúng cách (ví dụ: nếu tệp có mã chmod'd thành 600, tệp đó sẽ không thể đọc được công khai)
3. Tôi không quan tâm đến bất kỳ ai có quyền truy cập siêu người dùng lưu trữ mật khẩu

đây là những gì tôi đã có cho đến nay

• lưu trữ mật khẩu trong password.txt
• $ chmod 600 password.txt
• Process đọc từ password.txt khi cần thiết
• đệm ghi đè bằng số không khi nó không còn cần thiết

Mặc dù tôi chắc chắn rằng có một cách tốt hơn.

Answer 1

Đây không phải là giải pháp cho mật mã. Không có vấn đề gì về mật mã được sử dụng, khóa sẽ có thể truy cập ngang bằng với kẻ tấn công. Cyrpto không giải quyết được mọi vấn đề.

chmod 400 là tốt nhất, điều này làm cho nó chỉ đọc. chmod 600 được đọc viết, có thể hoặc có thể không phải là một yêu cầu. Ngoài ra hãy chắc chắn rằng nó chown'ed bởi quá trình cần nó. Đây thực sự là điều tốt nhất bạn có thể làm. Ngay cả khi bạn đang chia sẻ máy với những người dùng khác, họ không thể truy cập nó. Hy vọng rằng đây là một máy chuyên dụng, trong trường hợp đó không có nhiều mối đe dọa. SELinux hoặc AppArmor sẽ giúp tăng cường hệ thống từ các cuộc tấn công chéo/xử lý chéo người dùng.

Chỉnh sửa: Shread là công cụ bạn cần xóa an toàn tệp.

Chỉnh sửa: Dựa trên nhận xét của Moron/Mike lệnh unix ps aux sẽ hiển thị tất cả các quy trình đang chạy và lệnh được sử dụng để gọi chúng. Ví dụ, lệnh sau sẽ được hiển thị cho tất cả người dùng trên hệ thống: wget ftp://user:password@someserver/somefile.ext. Một giải pháp thay thế an toàn là sử dụng thư viện CURL. Bạn cũng nên vô hiệu hóa lịch sử vỏ của bạn. Trong bash bạn có thể thực hiện việc này bằng cách đặt biến môi trường export HISTFILE=

Answer 2

Bạn không xa cách tiếp cận tốt nhất do những ràng buộc của bạn. Bạn có hai vấn đề cần giải quyết. Đầu tiên là lưu trữ mật khẩu. Thứ hai là sử dụng mật khẩu một cách an toàn.

Xử lý vấn đề thứ hai trước - bạn có vấn đề lớn trong việc sử dụng chương trình dòng lệnh.Sử dụng các tùy chọn cho lệnh 'ps', người dùng có thể thấy các đối số được sử dụng trong việc chạy chương trình dòng lệnh. Từ những gì bạn đã viết, điều này sẽ chứa mật khẩu ở dạng văn bản thuần túy. Bạn đề cập đến đây là một giao diện không thể thay đổi. Mặc dù vậy, như một lập trình viên đạo đức, bạn nên nêu vấn đề. Nếu đây là một ứng dụng ngân hàng xử lý các giao dịch tài chính, bạn có thể xem xét việc tìm việc khác thay vì là một phần của giải pháp phi đạo đức.

Chuyển sang lưu trữ mật khẩu an toàn, bạn không đề cập đến ngôn ngữ bạn đang sử dụng cho các tệp lô của bạn. Nếu bạn đang sử dụng một kịch bản lệnh shell, thì bạn có ít sự truy đòi hơn là mã cứng mật khẩu trong kịch bản lệnh shell hoặc đọc nó trong văn bản thuần từ một tệp. Từ mô tả lưu trữ mật khẩu trong một tệp riêng biệt, tôi hy vọng rằng bạn có thể đang viết một chương trình bằng ngôn ngữ được biên dịch. Nếu có, bạn có thể làm tốt hơn một chút.

Nếu sử dụng ngôn ngữ được biên dịch, bạn có thể mã hóa mật khẩu trong tệp và giải mã trong chương trình của mình. Chìa khóa để giải mã sẽ nằm trong chương trình để nó không thể đọc dễ dàng. Bên cạnh đó, tôi sẽ

• chmod 400 file để ngăn chặn những người dùng khác từ việc đọc nó
• thêm một dấu chấm prefix ('') vào file để ẩn nó từ thư mục bình thường niêm yết
• đổi tên tập tin để làm cho nó ít thú vị hơn để đọc.
• cẩn thận không lưu khóa trong chuỗi đơn giản - lệnh 'chuỗi' sẽ in tất cả các chuỗi có thể in từ hình ảnh thực thi unix.

Sau khi thực hiện những việc này, các bước tiếp theo sẽ là cải thiện việc quản lý khóa. Nhưng tôi sẽ không đi xa đến khi vấn đề 'ps' bị xóa. Có rất ít cảm giác đặt chốt cửa thứ ba ở cửa trước khi bạn định mở cửa sổ.

Answer 3

Không điền bộ đệm mật khẩu bằng số không, điều này là vô nghĩa. Nhân có thể quyết định hoán đổi nó đến một vị trí tùy ý trong tập tin hoán đổi hoặc nói sau khi cấp phát bộ nhớ nào đó hạt nhân sẽ di chuyển các bảng trang quanh, dẫn đến các bảng trang khác chứa mật khẩu trong khi bạn chỉ có quyền truy cập vào bản sao mới.

Bạn có thể prctl (2) với PR_SET_NAME để thay đổi tên quy trình khi đang di chuyển. Thật không may, hiện tại tôi không thể nghĩ ra cách nào khác ngoài việc tiêm một số mã vào quá trình chạy qua ptrace (2), có nghĩa là các quá trình của đối phương sẽ chạy đua để đọc danh sách quy trình trước khi bạn có cơ hội thay đổi tên quy trình mới:/

ngoài ra, bạn có thể lấy các bản vá lỗi grsecurity hạt nhân, và bật CONFIG_GRKERNSEC_PROC_USER:

Nếu bạn nói Y ở đây, người sử dụng không phải root sẽ chỉ có thể xem quá trình riêng của họ, và hạn chế chúng từ xem thông tin liên quan đến mạng, và xem biểu tượng hạt nhân và mô-đun thông tin.

này sẽ ngừng ps từ việc có thể để xem các lệnh chạy, như ps đọc từ /proc/<pid>/cmdline

giao diện Said đòi hỏi chúng ta phải vượt qua một mật khẩu plain-text trên một lệnh dòng để kết nối với kho dữ liệu. Điều này là một thực hành an ninh khủng khiếp, nhưng chúng tôi đang mắc kẹt với nó.

Nó chỉ là thực hành bảo mật kém do các sự cố trong kiến ​​trúc O/S. Bạn có mong đợi những người dùng khác có thể chặn các syscalls của bạn không? Tôi sẽ không đổ lỗi cho một nhà phát triển rơi vào cái bẫy này.