Cách không an toàn nhất để lưu trữ mật khẩu được sử dụng bởi tập lệnh là gì?


13

Tôi có một tập lệnh Bash tự động xác thực với một dịch vụ bằng tên người dùng và mật khẩu của tôi. Thông tin đăng nhập hiện được lưu trữ dưới dạng văn bản thuần túy trong tập lệnh.

Tôi nên thực hiện các biện pháp phòng ngừa nào để lưu trữ an toàn các thông tin đăng nhập này trong khi vẫn cho phép truy cập tập lệnh?

Điểm làm rõ:

  • Tôi hiểu rằng, nếu có sẵn, các phương pháp xác thực khác nên được sử dụng thay thế. Tôi vẫn muốn biết phải làm gì trong trường hợp xác thực mật khẩu là lựa chọn duy nhất.
  • Không lưu trữ mật khẩu là không phải là một câu trả lời chấp nhận được ở đây. Tôi đang hỏi về trường hợp tập lệnh phải có quyền truy cập không được giám sát vào mật khẩu.

2
không lưu trữ phần mật mã của thông tin đăng nhập, có lẽ?
Thomas Ward

Nó sẽ không hoạt động để truy cập Gnome keyring hoặc một cái gì đó tương tự?
Lửa

Có lẽ nếu bạn có thể lưu trữ nó dưới dạng băm mật mã (như SHA-1), điều đó sẽ rất tuyệt.
Ẩn danh

ROT13 sẽ che khuất nó, nhưng sẽ không bảo mật nó theo bất kỳ cách nào.
Ẩn danh

@Anonymous Nếu mật khẩu được lưu trữ dưới dạng băm mật mã, làm thế nào để bạn khuyên bạn nên truy xuất nó?
ændrük

Câu trả lời:


8

Những loại dịch vụ? Một số dịch vụ có các phương thức khác để xác thực, ví dụ: khóa SSH cho SSH kết hợp với tác nhân SSH.

Tôi sẽ lưu mật khẩu riêng biệt với tập lệnh và đảm bảo rằng tất cả các thành phần đường dẫn có quyền được đặt chính xác. Ví dụ, hãy chắc chắn rằng trong đường dẫn /path/to/file, /, /path/path/tođược sở hữu bởi một người dùng mà bạn tin tưởng ( root) và rằng đây là những không ghi được bởi một người không được phép để xem tập tin của bạn. Cuối cùng, các quyền được đề xuất cho filelà 600 hoặc 400.

Điều đó filecó thể trông như thế này:

PASSWORD='something that you cannot remember'

Trong tập lệnh của bạn, sử dụng mã dưới đây để nhập biến:

. /path/to/file

Đối với tập lệnh của bạn, hãy đảm bảo rằng nó không chứa các lỗ hổng có thể cho phép kẻ tấn công thực thi mã trong ngữ cảnh tập lệnh (ví dụ: môi trường không được kiểm soát có thể có bộ $PATHbiến tùy ý hoặc sử dụng không hợp lệ các tệp khác (ví dụ: cung cấp tệp có thể ghi trên thế giới) .

Đối với việc bảo vệ thực tế mật khẩu của bạn, bạn không thể. Nó phải có sẵn bằng cách nào đó cho các dịch vụ khác. Thay vào đó, bạn có thể mã hóa tệp / tập lệnh chứa mật khẩu bằng cách sử dụng opensslhoặc gpgdo đó bạn cần nhập mật khẩu trước khi thông tin đăng nhập được mở khóa. Điều này đặc biệt hữu ích nếu mật khẩu dịch vụ của bạn khó nhớ.


14

Thay vì mã hóa mật khẩu trong tệp, hãy lưu mật khẩu vào một tệp riêng và bảo vệ tệp ( chmod 700hoặc chmod 500) để chỉ người dùng được ủy quyền mới có thể truy cập.

Lấy mật khẩu cat /dir/to/file/with/.passwordthay vì đọc tệp và lưu trữ nội dung của nó vào một biến.


Một số công cụ thậm chí có một tùy chọn để đọc mật khẩu trực tiếp từ một tệp vì lý do chính xác này, chẳng hạn như --passphrase-filetùy chọn của gpg .

2
... và biến nó thành .dotfile (/dir/to/file/with/.password)
knb

2
chmod 400cho các tập tin (chỉ đọc). Tất nhiên, bạn phải bảo mật các thư mục hàng đầu (700 hoặc 500, hoặc thậm chí 100 nếu bạn bị hoang tưởng). Lưu ý rằng 400 (hoặc 500 cho thư mục) là đủ, các chế độ khác (100) có thể được coi là bảo mật thông qua che khuất , giống như ẩn tệp bằng cách đặt dấu chấm trước tên.
Lekensteyn

1

Tôi biết đây là một câu hỏi cũ nhưng tôi đã gặp phải vấn đề tương tự này và tôi đã sử dụng vòng khóa của Ubuntu để giải quyết nó. Đây là một giải pháp trên Ubuntu 18.04LTS Mở thiết bị đầu cuối Viết xuống keyring set {{service}} {{username}} ví dụ nếu bạn đang sử dụng điều này để ghi nhật ký mật khẩu của trường:

keyring set school mohamed

Nó sẽ đăng nhập cho bạn một mật khẩu nhập mật khẩu. Bây giờ mật khẩu bạn đã nhập được lưu trữ trong khóa Ubuntu.

Để lấy mật khẩu này, hãy viết trong terminal:

keyring get school mohamed

để sử dụng điều này trong ngữ cảnh của một kịch bản:

password=$(keyring get school mohamed)

Bây giờ mật khẩu chứa mật khẩu bạn đã nhập trước đó.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.