Sterowniki JDBC vs hasła otwartym tekstem

Sytuacja wygląda tak:

• jest aplikacja w Javie, która korzysta z gołego"JDBC i zaczytuje hasła z pliku konfiguracyjnego, w którym wszystko jest otwartym tekstem, a następnie buduje z tego "connection stringa" (autorzy przyznają, że "logika nawiązywania połączenia jest dość mocno rozsmarowana w kodzie źródłowym", czyt. "wielka qpa")
• brak realnych możliwości ingerowania w aplikację ("zmienimy, ale zajmie to dużo czasu i na pewno nie będzie w tym roku, bo dbamy o jakość produktu i potrzebujemy czasu na testy" :P)
• OS: Linux
• klient nie chce haseł otwartym tekstem

Cel:

• przechowywanie hasła w formie, która nie jest otwartym tekstem

Jakieś pomysły jak wprowadzić warstwę bezpieczeństwa, która uniemożliwi odczyt pliku osobom postronnym / wprowadzi przezroczyste deszyfrowanie?
Szukam jakiegoś rozwiązania dla leniwych, najlepiej istniejącego pudełka, a nie pisanie własnego wrappera.

Jak do tej pory rozważam:

• chmod 600 plik_z_hasłami - proste zabezpieczenie, ale zbyt proste
• SE Linux i ograniczenie open() per konkretny użytkownik i konkretny proces użytkownika
• wprowadzenie jakiegoś wrappera na system calle (LD_PRELOAD) i tam szyfrowanie/deszyfrowanie w locie (minus - zmieni się coś w strukturze konfiguracji -> wrapper leży)

Może ktoś słyszał o jakimś wrapperze na sterownik JDBC ? np. ładujemy oryginalny sterownik do osobnego class loadera, a podmieniamy "gotowiec", któremu hasła można by podawać z innego źródła?

A brałeś pod uwagę Jasypt lub coś podobnego? Z tego co kojarzę pozwala np. zaszyfrować hasła w application.properties i obsłużyć wszystko "pod spodem", powinien dać sobie radę z hasłem do bazy. Niby integruje się np. ze Spring / Spring Boot czy Hibernate, a dla JDBC jakoś nic nie znalazłem, ale powinno się dać go samemu ręcznie skonfigurować i spiąć sznurkami jak trzeba ;)

Zamiast:

bla.bla.bla.password=pwd12345

Wygląda to mniej-więcej tak:

bla.bla.bla.password=ENC(ndfiug3hbadlib432ihyb5463fr)

Cośtam o konfiguracjach w application.properties

Macie klasę Javową na odczyt tego hasła z konfiguracji? W sensie klasę która służy do odczytu? Jeżeli tak to wydzielcie z niej interfejs, do pobrania instancji (o ile nie macie singletona) użyjcie fabryki zamiast wywoływania jakiegoś dzikiego new. Jak będziecie mieli fabrykę + interfejs to następnie tylko będziecie musieli podmienić implementację na odczytującą hasła np. ze zmiennych środowiskowych i viola.

Edit (uwaga autoreklama!)
O coś takiego u was w kodzie zaimplementować: https://github.com/matadini/sysmusic/tree/master/sysmusic-server/src/main/java/pl/matadini/sysmusic/server/application/configuration

Możesz nawiązywać połączenie używajac certyfikatu klienta SSL - nie wiem jaki masz rodzaj bazy - Oracle i MySQL wspieraja. Certyfikat trzymasz w pliku (keystore).
Albo możesz w tym keystore trzymać hasło (jako tekst).
Wada : i tak musisz gdzieś haslo do keystore trzymać ;-) , ale generalnie tak się robi.
Hasło (do keystore lub db) jest trzymane w jakiś skryptach systemowych i podawane do aplikacji przez -D lub podobnie. Programiści jak się uprą to znajdą / wyciągną -> zawsze. Ale tak po chamsku nie leży wtedy to hasło nigdzie.

@jarekr000000: +1 za słuszną metodę, ale w magicznym produkcie jest qpa typu:

     String url = "jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=maszynka)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=foobar)))";
     Driver driver = new oracle.jdbc.OracleDriver();
     Properties props = new Properties();

     ...
     // ustawianie properties, w tym host/port/user/password/...
     ...

     Connection conn = driver.connect( url, props );

Taka "logika" jest wszędzie tam, gdzie potrzebują połączenia do bazy. W configu nawet nie ma urla, którego można by zmodyfikować i wymusić nieinwazyjnie dodatkowe properties...

Przez chwilę myślałem, że idealne byłoby coś w stylu "JDBC Proxy Server", które można postawić niezależnie od procesu JVM i tam nadpisać usera/hasło/inne.
Tylko, że to tylko przeniesienie problemu w inne miejsce.

Dochodzę do wniosku, że to sytuacja beznadziejna i trzeba naskarżyć wewnętrznie na słaby produkt, a nie męczyć się z naprawianiem cudzych błędów.

Są proxy drivers. Ale musisz spróbować czy którykolwirk pasuje.