Làm xáo trộn mật khẩu được lưu trữ trong bash

Question

Tôi có một tập lệnh bash mà tôi cần phải viết mật khẩu của mình để chạy một chương trình. Những người khác có thể nhìn thấy nó. Có cách nào để viết mật khẩu theo cách không quá rõ ràng không? Ngay cả khi anh ta có thể thực hiện lệnh tương tự trong bash và lấy mật khẩu, anh ta không thể đọc nó trong văn bản.

Hôm nay tôi làm điều này:

PASSWORD="1234567" 
program --pass=$PASSWORD 

Tôi muốn làm điều này

PASSWORD="10101001001010010101010100101" #binary or other code 
NEW_PASS=`decrypt $PASSWORD` 
program --pass=$NEW_PASS 

Bất kỳ ý tưởng?

Answer 1

Điều bạn đang yêu cầu không chỉ là điều ác - nó đơn giản là sẽ không hoạt động.

Tất cả người dùng đã làm để xem mật khẩu của bạn là chạy bash -x your_script và đầu ra sẽ bao gồm

+program '--pass=decrypted-password-here' 

... không có vấn đề hiệu quả như thế nào obfuscation có thể có được.

Chương trình thực sự bạn đang cố gọi là cần mật khẩu là gì? Bạn có thể ẩn mật khẩu của bạn đằng sau một wrapper setuid, chẳng hạn như các wrapper có thể đọc các tập tin mật khẩu ngay cả khi người dùng chạy nó không thể? Bạn có thể (mượn đề xuất của DigitalRoss) thiết lập tài khoản người dùng có bản sao mật khẩu đã lưu trữ (hoặc tốt hơn, chứng chỉ hoặc cặp khóa), chỉ định cấu hình để có thể chạy tập lệnh của bạn và không có gì khác trên SSH và cung cấp người dùng sẽ có thể chạy quyền của tập lệnh cho SSH như người dùng đó (hoặc sudo cho người dùng đó chỉ cho một lệnh duy nhất, v.v.)?

Vv

Tóm lại: Nhằm mục đích bảo mật thực sự, không làm xáo trộn.

---

Bây giờ, nếu bạn đã muốn obfuscation - cách tiếp cận truyền thống là ROT-16:

obfuscated_password="qrpelcgrq-cnffjbeq-urer" 
real_password="$(tr a-zA-Z n-za-mN-ZA-M <<<"$obfuscated_password")" 

... nhưng nếu đó là một mật khẩu mà bạn thực sự quan tâm đến bất cứ điều gì, không obfuscate - sử dụng một trong các phương pháp được đưa ra ở trên để tránh lưu trữ mật khẩu theo cách có thể đọc được.

Answer 2

A "không phải là quá khó khăn" Cách thứ nhất là sử dụng ROT13:

PASSWORD=cnffjbeq 
REAL_PASSWORD=`echo $PASSWORD | rot13` 

Nếu bạn không có một chương trình rot13, sử dụng tr a-z n-za-m tác phẩm chỉ là tốt.

Hãy nhớ rằng điều này cung cấp hoàn toàn không có bảo mật nào. Tuy nhiên, nó có thể là đủ cho mục đích "xem thường xuyên" của bạn.

Answer 3

Bạn có thể sử dụng uuencode and uudecode, thường được cài đặt (và luôn có sẵn dễ dàng qua gói) trên hệ thống Unix. Vì mã hóa sẽ vô nghĩa nên nó có thể ngăn người quan sát dễ dàng ghi nhớ mật khẩu, tức là, stealing the password via shoulder-surfing. Nhưng mật khẩu văn bản rõ ràng ngẫu nhiên được lựa chọn tốt sẽ hoàn thành về cùng một điều mà không có ảo giác về bảo mật giả.

Vấn đề chính xác này phải đối mặt với everyone in DevOps những ngày này vì việc quản lý cấu hình tự động ngày càng cần thiết.

Dưới đây là một số giải pháp tốt hơn:

• có một bí mật tập tin trên hệ thống kịch bản của bạn chạy trên. Kịch bản có thể đọc bí mật của nó khi chạy trong tệp. Bằng cách này, bạn có thể kiểm tra tập lệnh trong điều khiển mã nguồn mà không cần phát mật khẩu và bạn có thể sử dụng quyền của người dùng để bảo vệ tệp bí mật. Bạn có thể sử dụng lại tập lệnh mà không cần truyền mật khẩu.

• sử dụng không-cụm từ mật khẩu ssh nào xác thực chủ chốt để có được hệ thống từ xa

• sử dụng một sự kết hợp của các phương pháp trên với một người sử dụng vai trò hạn chế. Tôi thường tạo một người dùng trên hệ thống đích mà không thể làm bất cứ điều gì ngoại trừ những gì kịch bản muốn làm. Phiên bản hiện đại của ssh trợ giúp với điều này, vì họ có thể bỏ qua lệnh đến (xem forcecommand trong sshd_config hoặc sử dụng something like ssh-forcecommand) và luôn luôn làm một điều cụ thể.

• xác thực ứng dụng khách đại lý quản lý thông qua chứng chỉ được ký bởi máy chủ. Các hệ thống quản lý cấu hình thực như Puppet và Chef sẽ làm điều này cho bạn.

• nếu bạn đang kết nối với trang web, bạn vẫn có thể tạo người dùng bị hạn chế vai trò hoặc ít nhất một người đó có thể sử dụng được. Có lẽ bạn có thể đăng nhập bằng tay một lần và thiết lập một phiên kiên trì. Curl có thể sử dụng cookie và hợp tác với phương pháp này.

Answer 4

Đưa khóa dưới thảm cửa không phải là bảo mật. Nhưng thực tế là 'chương trình' cần phải vượt qua ..... có nghĩa là bất cứ ai làm 'ps -ef' đều có thể thấy nó. Nếu 'chương trình' có một biểu mẫu có thể đọc mật khẩu từ một đường ống, thì bạn nên sử dụng nó thay thế. ví dụ: chương trình --pass = - ... < /home/me/.something và làm cho tệp chỉ đọc được cho bạn.