I allow the customer to choose from amongst these choices. The key compiled in is not something that I would live with. A hard coded key can be easily derived from the binary. By Blowfish requiring a pwd I do mean that a key must be supplied. This is the same with all encryption mechanisms. I generally code the user id / password in the script file and allow the OS to protect it. Cheers Ben
_____ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Axton Sent: February 4, 2009 11:48 AM To: arslist@ARSLIST.ORG Subject: Re: Side Line API Question - User ID / Password Security ** You pass the username/pass at the command line in plain text where anyone can see it in the process list but you don't want to rely on the OS/filesystem security by storing an encrypted value in a text file? You store the username/password in an environment variable even though some operating systems allow non-root users to see process environment variables via ps? Blowfish requires a password? Maybe you mean, "some specific implementation uses a password as a key"? You can write your program and include the key in the source; it then gets compiled into the product. As long as no one has that key, the data is safe. You can allow the user to define the key in the config file. Endian Transformations: Store the key as plain text by encoding it in base64. Axton Grams On Tue, Feb 3, 2009 at 9:32 PM, Ben Chernys <ben.cher...@softwaretoolhouse.com> wrote: ** No matter what encryption you use you will need a key. Where do you get that key from? As an example, I use the server aliases a key for my licenses. Of course that means that I need to successfully sign on to the server to obtain that alias. The value that you will be encrypting must also be transformed to have at least a checksum and a random quantity in it. On the specific issue of ARS user and passwords I allow them to be specified by environment variables, in text files, and on the command line. I do not encrypt them at this time and rely on OS security. Some customers have raised some questions and I am also looking into this because of them but the issue has not prevented any sales. If your app needs to run on many client machines (as mine does) you cannot use any cpu ids or mac addresses etc as a key. The blowfish product requires a password. You can use this system but if you need to automate this you are also faced with the same problem of where to store this password. One possibility is a separate password management process but this is still faced with the same problem of full automation. I am thinking along the lines of the PuTTY agent for ssh keys here. Also remember the issues of endian transformations. Your keys need to work on different endian machines. If your password file is to be machine specific (client specific) you can use blowfish (I use an older des implementation) and something like the cpu id for a key. That means that the password file will not be transferable from machine to machine. This is unacceptable to me. Remember that you must decrypt them before each and every call to ARS. ARS itself encrypts them before putting them out over IP but they are still in memory in decrypted form. If you do find something please keep me in the loop. I think you will find encryption rather daunting a subject. Cheers Ben _____ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of LJ Longwing Sent: February 3, 2009 3:24 PM To: arslist@ARSLIST.ORG Subject: Re: Side Line API Question - User ID / Password Security ** :)...the point of storing them in a Remedy form was that Remedy would execute the script via filter run-process...that configuration obviously only works if your api program is being run by Remedy itself...:) _____ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Robert Molenda Sent: Tuesday, February 03, 2009 7:19 AM To: arslist@ARSLIST.ORG Subject: Re: Side Line API Question - User ID / Password Security ** 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! __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
