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___
>

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"

Reply via email to