Ẩn mật khẩu kho khóa/mật khẩu JKS khi chạy quy trình Java

Question

Tôi có một số ứng dụng Java kết nối với các ứng dụng và dịch vụ khác thông qua các kết nối được bảo mật bằng SSL. Trong quá trình phát triển, tôi có thể chỉ định keystore/truststore để sử dụng và mật khẩu bằng cách sử dụng JVM args:

-Djavax.net.ssl.trustStore=certificate.jks 
-Djavax.net.ssl.trustStorePassword=mypassword 
-Djavax.net.ssl.keyStore=certificate.jks 
-Djavax.net.ssl.keyStorePassword=mypassword 
-Djavax.net.ssl.keyStoreType=jks 

Điều này hoạt động hoàn hảo. Tuy nhiên, có một yêu cầu khi đi sản xuất để ẩn mật khẩu, bằng cách sử dụng JVM args có nghĩa là bất cứ ai nhìn vào danh sách quy trình sẽ có thể nhìn thấy mật khẩu trong văn bản rõ ràng.

Có cách nào đơn giản để giải quyết vấn đề này không? Tôi đã xem xét việc nhập các chứng chỉ vào tệp lib/security/cacerts của JRE, nhưng sự hiểu biết của tôi là điều này sẽ vẫn yêu cầu mật khẩu. Một tùy chọn là lưu trữ mật khẩu, mã hóa, trong một tệp và sau đó nhận các ứng dụng để đọc và giải mã khi đang di chuyển, nhưng điều này sẽ liên quan đến việc thay đổi và phát hành lại tất cả các ứng dụng (có một vài trong số đó). thà tránh điều này nếu có thể. Thư viện javax.net.ssl ​​có bất kỳ hỗ trợ được xây dựng sẵn cho mật khẩu được mã hóa (ngay cả khi nó đơn giản như chỉ base64encoding hay bất kỳ thứ gì làm cho mật khẩu không rõ ràng) không?

Mọi đề xuất được đánh giá cao.

Answer 1

Thứ nhất, bạn có thể xem xét giấu đầu ra ps từ những người dùng khác, xem những câu hỏi này:

• I don't want other users see my processes in ps aux. I have root. It's Debian. How to use grsec?
• Hide processes from other users based on groups (under Linux)?
• How to make a process invisible to other users?

Thứ hai, nhập khẩu giấy chứng nhận của bạn (giả sử với khóa riêng) vào lib/security/cacerts sẽ là vô nghĩa: đó là kho lưu trữ mặc định, nhưng không phải là kho khóa mặc định (fo) r mà không có giá trị mặc định).

Thứ ba, bạn không bao giờ có thể "mã hóa" mật khẩu sẽ được ứng dụng của bạn sử dụng (ở chế độ không tương tác). Nó phải được sử dụng, vì vậy nếu nó được mã hóa, khóa mã hóa của nó sẽ cần phải được làm sẵn có trong một số điểm rõ ràng. Do đó, nó là một chút vô nghĩa.

Mã hóa cơ sở 64, như bạn đề xuất, chỉ là mã hóa. Một lần nữa, nó là vô nghĩa vì ai cũng có thể giải mã nó (ví dụ: based64 -d). Một số công cụ, như Jetty, có thể lưu trữ mật khẩu ở chế độ bị xáo trộn, nhưng không có nhiều khả năng chống lại mã hóa cơ sở 64. Sẽ rất hữu ích nếu ai đó đang nhìn qua vai của bạn, nhưng đó là nó.

Bạn có thể điều chỉnh ứng dụng của mình để đọc mật khẩu từ một tệp (bằng văn bản thuần túy hoặc bị xáo trộn). Bạn chắc chắn sẽ cần phải chắc chắn rằng tập tin này không thể đọc được bởi các bên trái phép.

Điều thực sự quan trọng là đảm bảo rằng tệp kho khóa chính nó được bảo vệ khỏi người dùng không có ý định đọc nó. Mật khẩu của nó có nghĩa là để bảo vệ các container trong trường hợp nó sẽ được đọc bởi những người khác hoặc khi bạn muốn bảo vệ quyền truy cập trong chế độ tương tác. Vì bạn thực sự không thể tránh sử dụng mật khẩu rõ ràng trên máy tính ở chế độ không giám sát, nên có rất ít điểm có mật khẩu khó, thay vào đó điều quan trọng hơn là phải tự bảo vệ tệp. (Nó không rõ ràng cho dù các ứng dụng của bạn có tương tác hay không, nhưng tôi đoán ít người dùng nên được nhập -Djavax.net.ssl....=... tương tác.)

Nếu bạn không thể điều chỉnh mã của mình để đọc từ tệp, hãy thay đổi mật khẩu khóa và mật khẩu khóa thành mật khẩu mà bạn không để lộ "ABCD" và đảm bảo bạn bảo vệ quyền truy cập đọc từ tệp kho khóa này : đó là điều thực sự quan trọng cuối cùng. Việc đọc mật khẩu từ tệp phụ chỉ đơn thuần là trì hoãn vấn đề bằng một bước, vì tệp mật khẩu và tệp kho khóa có thể được lưu trữ bên cạnh một tệp khác (và được sao chép bởi một bên không được ủy quyền).