Ukryj hasło magazynu kluczy JK/zaufanych certyfikatów podczas uruchamiania procesu Java

Question

Mam wiele aplikacji Java, które łączą się z innymi aplikacjami i usługami za pośrednictwem połączeń zabezpieczonych przy użyciu protokołu SSL. Podczas rozwoju, mogę określić kluczy/magazynu zaufanych certyfikatów do użycia i hasło za pomocą args JVM:

-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 

Działa to doskonale. Istnieje jednak wymóg, aby przejść do produkcji, aby ukryć hasło, używając argumentów JVM oznacza, że ​​każdy, kto patrzy na listę procesów, będzie mógł zobaczyć hasło w postaci zwykłego tekstu.

Czy istnieje prosty sposób obejścia tego? Rozważałem zaimportowanie certyfikatów do pliku lib/security/cacerts środowiska JRE, ale mam świadomość, że będzie to wymagało hasła. Jedną z opcji byłoby przechowywanie hasła, zaszyfrowane, w pliku, a następnie pobieranie aplikacji do odczytywania i odszyfrowywania w locie, ale wymaga to zmiany i ponownego wydania wszystkich aplikacji (jest ich sporo), więc wolałbym tego uniknąć, jeśli to w ogóle możliwe. Czy biblioteka javax.net.ssl ​​ma wbudowaną natywną obsługę zaszyfrowanych haseł (nawet jeśli jest to coś tak prostego, jak tylko kodowanie base64), czy coś, co powoduje, że hasła nie zawierają czystego tekstu?

Wszelkie sugestie bardzo doceniane.

Answer 1

Po pierwsze, można rozważyć ukrycie wyjście ps od innych użytkowników, zobacz te pytania:

• 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?

drugie, importowania certyfikatów (zakładając, ze klucze prywatne) do lib/security/cacerts byłoby bezcelowe: jest to domyślny magazyn zaufanych certyfikatów, ale nie domyślny plik kluczy (fo r którego nie ma wartości domyślnej).

Po trzecie, nigdy naprawdę nie można "zaszyfrować" hasła, które ma być używane przez aplikację (w trybie nieinteraktywnym). Musi być użyty, więc jeśli był zaszyfrowany, jego klucz szyfrowania musiałby zostać udostępniony w pewnym momencie. Dlatego jest to trochę bezsensowne.

Kodowanie w standardzie 64, zgodnie z sugestią, jest po prostu kodowaniem. Ponownie, jest to zupełnie bezcelowe, ponieważ każdy może je zdekodować (np. based64 -d). Niektóre narzędzia, takie jak Jetty, mogą przechowywać hasło w trybie zaciemnionym, ale nie jest ono dużo bardziej odporne niż kodowanie podstawowe 64. Przydaje się, gdy ktoś patrzy ci przez ramię, ale to już wszystko.

Możesz dostosować swoją aplikację do czytania haseł z pliku (w postaci zwykłego tekstu lub zaciemnionego). Z pewnością należy upewnić się, że plik ten nie jest czytelny dla nieautoryzowanych stron.

Ważne jest, aby sam plik magazynu kluczy był chroniony przed użytkownikami, którzy nie powinni go czytać. Jego hasło służy do ochrony kontenera w przypadkach, w których mógłby być odczytany przez innych lub w celu ochrony dostępu w trybie interaktywnym. Ponieważ tak naprawdę nie można uniknąć użycia hasła na maszynie w trybie nienadzorowanym, nie ma sensu posiadanie trudnego hasła, ale ważniejsze jest, aby chronić sam plik. (Nie jest jasne, czy twoje aplikacje są interaktywne czy nie, ale myślę, że niewielu użytkowników powinno interaktywnie wpisać -Djavax.net.ssl....=....)

Jeśli nie możesz dostosować kodu do odczytu z pliku, zmień hasło pliku kluczy i kluczy na hasło, którego nie masz nic przeciwko wyświetlaniu, np. "ABCD", i upewnij się, że chronisz dostęp do odczytu z tego pliku kluczy : to na prawdę ma znaczenie. Odczytywanie samego hasła z pliku pomocniczego powoduje jedynie odkładanie problemu o jeden krok, ponieważ plik haseł i plik magazynu kluczy mogą być przechowywane obok siebie (i kopiowane razem przez nieautoryzowane strony).