LJ & Axton; Sorry for the quite delayed THANKS - I caught that cold/flu bug and was down for about a week - then was in catch-up mode...
LJ - I thought about storing the login info/etc in a Remedy form - however, the conundrum is you have to 'login to get the login info'... for some customers this is OK - example is to use an Archive server which consolidates all "Login / Server / Job Schedule Info"... Axton - I'll be digging into the Blowfish code sometime soon. THANKS AGAIN - sorry for the delayed response ;~( Robert On Mon, Jan 19, 2009 at 1:25 PM, Axton <axton.gr...@gmail.com> wrote: > ** It depends on the nature/use of the program. For server side stuff, I > typically store the password in an encrypted format in a config file, set > the file ownership, and restrict the file permissions. There are lots of > good packages in java for such things. Blowfish is the cipher I've opted > for in the past (it's free, fast, and readily available). > > Axton Grams > The opinions, statements, and/or suggested courses of action expressed in > this E-mail do not necessarily reflect those of BMC Software, Inc. My > voluntary participation in this forum is not intended to convey a role as a > spokesperson, liaison or public relations representative for BMC Software, > Inc. > > On Mon, Jan 19, 2009 at 12:49 PM, Robert Molenda <robert.mole...@gmail.com > > wrote: > >> ** >> Hello Listers; >> >> Hopefully this post finds you well - Thanks in advance for feedback... >> >> I have written several ARS 7.x Java API based utilities, which all run >> just fine - and this weekend when I was doing the documentation for them - >> in the "Security Section" - I obviously mentioned all the normal "Remedy >> Security" topics (group permissions, etc)... >> >> Then I got stuck on the "Login ID / Password" security issue. So I figured >> - someone else must-a already been down this path - so I googled (and >> googled and googled) but found very little with some 'concrete answers' so >> to say. >> >> So as I see it there are a few - somewhat limited options - in this area: >> >> ZERO Security - >> Hard-Code the ID / PW in the API (YUCK - not maintainable, single >> server setup, etc) >> Accept ID / PW over command line (At least the script can maintain the >> ID / PW, allows for reuse over different servers) >> >> LIMITED Security >> Tuck the ID / PW into a simple text file which the OS PERMISSIONS will >> restrict - however ID / PW is in clear text >> >> SOMEWHAT More Security >> Create a utility to encrypt the ID / PW into a file - which then is >> under OS PERMISSIONS - that the application can pick up and decode >> >> So, I'd like to hear how other people have dealt with this "ID / PW" >> Security topic in the past, etc. >> >> Thanks-n-advance; >> Robert Molenda >> __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ >> >> > > __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ > -- If it were not for the gutter, my mind would be homeless! _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
