> Am 19.12.2017 um 06:56 schrieb Andrus Adamchik <[email protected]>: > >> A disadvantage of this approach, though, is it puts the username/password >> on the command-line and/or the process list, plus potentially exposes it in >> command-line history, too. > > It doesn't if you are careful. Nothing prevents you from putting these in a > startup script of your app (this is what I was kind of alluding to when I > defined credentials as exported vars). From there you have lots of options > depending on how paranoid you are: > > * restricting access to the script with UNIX permissions. > * storing it on an encrypted drive. > * creating the script dynamically on startup and then deleting when the app > is started. > > The point is that with properties you have an easy mechanism separating your > security solution away from your Java app.
As long as those parameters end up as part of the java command line because the shell resolves them and puts them there literally, they will still be discoverable from the process list at runtime for every other user on the machine. The java process itself could redact them from there, but of course it doesn't. The credentials would need to live in a separate file with locked down permissions, with that file being referenced by name in the java command line. Maik
