[java] : Hoe sleutel encrypted properties file opslaan?

[quodlibet]

Voor een webapplicatie ontwikkeld in java is het nodig om verbinding te maken met een sap server.
Momenteel zijn de gegevens nodig om verbinding te maken (ip, username, password) met deze server opgeslagen in een properties file op de J2ee server.

Dit bestand staat dus in plain text op het filesystem van de webserver. Het is niet beschikbaar via het web, maar deze file unencrypted opslaan op het filesysteem is volgens mij ook niet veilig genoeg.

De voor de hand liggende oplossing lijkt mij dus dit bestand te encrypten.
Dat levert echter een heel ander probleem op : waar en hoe slaan we de encryptiesleutel voor dat bestand op?
Wanneer we deze als plaintext opslaan op het filesysteem zitten we terug met hetzelfde probleem als voorheen.
Deze sleutel mag enkel bekend zijn door de administrator die het properties bestand aanmaakt/wijzigt en de applicatie zelf.

Sommige j2ee servers voorzien in deze functionaliteit, de SAP Webas bijvoorbeeld heeft hiervoor een "Destination Services Api".
We willen echter dat onze applicatie op elke j2ee server kan worden deployed, dus specifieke oplossingen gebruiken voor specifieke servers is niet gewenst.

Zijn er hier tweakers die hiermee ervaring hebben? Zijn er tips hoe ik dit probleem best aanpak?

<edit>
ter info : Ik ben geen ervaren java ontwikkelaar en ben meer thuis in de sap wereld.
</edit>

Alvast bedankt,

Dries

[ Voor 3% gewijzigd door quodlibet op 22-10-2010 11:50 ]

[Onno]

Als je applicatie verbinding moet kunnen maken met een wachtwoord kan een kwaadwillende dat per definitie ook als hij toegang heeft tot het systeem waar de applicatie op draait. Het wachtwoord versleutelen maakt het geheel niet wezenlijk veiliger, het voorkomt hooguit dat je het wachtwoord per ongeluk ziet en onthoudt als je als beheerder het bestand eens bekijkt.

Ik zou dus eerder inzetten op het goed afschermen van het bestand waarin het wachtwoord staat dan daar encryptie aan toe te voegen.

[Salandur]

De beste oplossing is om alleen het wachtwoord geencrypted op te slaan in het propertiesbestand. Het is niet nodig om het hele bestand te encrypten. De encryptiesleutel zul je op een andere manier op moeten slaan. Hiervoor heb je 3 keuzes: op het bestandsysteem, in een database of hardcoded in je programma. Ik zou zelf voor optie 1 gaan en dan een andere (vaste) locatie kiezen waar dit bestand opgeslagen wordt. Meer security kan je niet toepassen, hooguit aan SAP vragen of er een andere inlogmethode gekozen kan worden waardoor het wachtwoord niet meer als plain text opgeslagen hoeft te worden.

[Niemand_Anders]

Heeft java geen isolated storage (container)? In .NET kun je IsolatedStorageScope op Application zetten en dan kan alleen de applicatie bij het bestand.

Ik gebruik isolated storage containers om licenties (X.509 certificaten met custom attributes) in op te slaan. Alleen dan gebruik ik de scope Assembly zodat alleen de licentie module bij de geïnstalleerde licenties kan.

[Macros]

Wat Niemand_Anders beschrijft is ongeveer hetzelfde als een properties file op een *nix systeem waarbij de file access op van het properties file op 400 of 600 staat. Meer dan dat heb je niet nodig.

[xos]

Salandur schreef op vrijdag 22 oktober 2010 @ 12:54:
De beste oplossing is om alleen het wachtwoord geencrypted op te slaan in het propertiesbestand. Het is niet nodig om het hele bestand te encrypten. De encryptiesleutel zul je op een andere manier op moeten slaan. Hiervoor heb je 3 keuzes: op het bestandsysteem, in een database of hardcoded in je programma. Ik zou zelf voor optie 1 gaan en dan een andere (vaste) locatie kiezen waar dit bestand opgeslagen wordt. Meer security kan je niet toepassen, hooguit aan SAP vragen of er een andere inlogmethode gekozen kan worden waardoor het wachtwoord niet meer als plain text opgeslagen hoeft te worden.

Er is nog een andere methode om bij het starten van de applicatie de beheerder een wachtwoord op te laten geven. Met behulp van dit wachtwoord kan je dan een key afleiden.

[Verwijderd]

xos schreef op zondag 24 oktober 2010 @ 18:31:
[...]

Er is nog een andere methode om bij het starten van de applicatie de beheerder een wachtwoord op te laten geven. Met behulp van dit wachtwoord kan je dan een key afleiden.

En waar sla je dat wachtwoord dan op?

[ACM]

Verwijderd schreef op zondag 24 oktober 2010 @ 19:46:
En waar sla je dat wachtwoord dan op?

Nergens, als het niet klopt dan komt er geen geldig propertiesbestand uit de decryptie.

Grootste nadeel van die aanpak is dat opstartprocedures van serversoftware helemaal niet ingericht is op het in moeten voeren van een wachtwoord. Dus je kan het al niet doen als onderdeel van het opstarten, want dan is de kans groot dat je je applicatie uberhaupt niet fatsoenlijk te starten is (of dat het wachtwoord onderdeel van het opstartscript wordt...). Na dat ie opgestart is een foutmelding geven net zo lang tot je het wachtwoord hebt ontvangen is ook niet praktisch, zeker niet als het een applicatie is die veelvuldig door andere gebruikers dan de beheerder wordt bekeken.

Hoe je het ook wendt of keert, het is een lastig probleem waar vziw geen goede oplossing voor is. Afschermen van het bestand is in ieder geval een makkelijke oplossing die al wat scheelt. Maar als iemand admin-toegang tot je systeem krijgt, of via de applicatieserver een willekeurig bestand in kan laten lezen, dan helpt dat je alsnog weer niet veel.

[quodlibet]

Alvast allemaal bedankt voor de antwoorden. Ik ben er nog niet helemaal uit, maar als ik dat ben zal ik het hier zeker laten weten.