Password storage (was Re: FTP & JSPC)

[Steve Loughran <st...@iseran.com>]

----- Original Message -----
From: "Roger Vaughn" <rv...@seaconinc.com>
To: <an...@jakarta.apache.org>
Sent: Tuesday, August 01, 2000 07:25
Subject: Re: FTP & JSPC


> Thanks for the comments.  Part of my goal in developing builds is that
they must
> be fully automatable.  I'm opposed to pop-up dialogs or even interactive
> command-line for that reason.  (The Microsoft signcode tool *really* bugs
me for
> this reason - it pops up a dialog for passwords.)  The environment
variable
> solution you suggest is slightly better - but in an automated environment
just
> moves the problem to a script file.
>
> Perhaps we need a password storage utility similar to way cvs login
handles things
> - encoding the passwords in a private file.  These could be read by Ant
using a
> standard mechanism - perhaps a new task to read a password and store it in
a
> property, or maybe a method in Task to read a password, so tasks that need
them
> can access them internally.  Then the tag for a task would only need to
include
> some sort of key for the password, rather than the password itself.

How about having your task include the password in a property in the command
line? This needs no extra code and you can keep the password out of
everywhere except your .history or equivalent?

To be honest, if you are using ftp or basic-auth HTTP then the pass is being
sent out in 'lightly massaged plaintext' anyway, so being vastly paranoid
about text encoding is probably overkill.

But if you are paranoid then the java.security.Keystore class is the place
to start -except it is a Java1.2 feature (and security changed again in
java1.3) . So doing sophisticated password protection is going to be tricky
across all ant supported platforms. Also I dont know how well the keystore
really encrypts stuff, especially in exported JVMs.

    -Steve

[Who only trusts all his important passwords to Bruce Schneiers Password
Safe app from counterpane.com, and then with a long passphrase]

Re: Password storage (was Re: FTP & JSPC)

[Roger Vaughn <rv...@seaconinc.com>]

Steve,

In an automated environment, this just moves the problem from the build.xml file
to whatever script, cron job, etc. you use to start the build.  It's not really
much of an improvement -- and in fact, the presence of passwords in .history
makes it kind of worse!

Honestly, in my environment, I'm not worried about theft of the passwords I'm
using.  This may not be the case for others, however.  Anyway, what I'm
considering at the moment is really only a small improvement - I'm not going for
a secure scheme, just a trivial encoding to block casual snoopers.  Anyone who
really wants these passwords is going to get them.

Thanks for the suggestion on Keystore.  Unfortunately, as you point out, the
Java security classes are probably unusable in this context because of the
differences between 1.1, 1.2, and 1.3.  Kinda hard to keep up with an unstable
standard....

Thanks!

roger

Steve Loughran wrote:

> How about having your task include the password in a property in the command
> line? This needs no extra code and you can keep the password out of
> everywhere except your .history or equivalent?

Re: Password storage (was Re: FTP & JSPC)

[Roger Vaughn <rv...@seaconinc.com>]

Peter Donald wrote:

> At 12:54  1/8/00 -0700, you wrote:
> >But if you are paranoid then the java.security.Keystore class is the place
> >to start -except it is a Java1.2 feature (and security changed again in
> >java1.3) . So doing sophisticated password protection is going to be tricky
> >across all ant supported platforms. Also I dont know how well the keystore
> >really encrypts stuff, especially in exported JVMs.
>
> It doesn't really encrypt anything. Most of it can be read via a hex editor
> and the other bit (private keys) are likely protected by same passwd as
> general keystore which can be easily found or alternatively you just do a
> brute forces search and brake it. Should take all of 40 mins in JKS
> .keystore files :/

Well, I also found that KeyStore requests (at least in 1.3) a password parameter
in order to retrieve a key.  And as I said a few posts back, supplying a
password to retrieve a password seems kinda silly....

I'm going ahead with the trivial base64 encoding, and it seems to be working out
well so far.  If you can trust your browser to send your passwords over the net
in this encoding (and it does), it should be fine for local storage.

roger

Re: Password storage (was Re: FTP & JSPC)

[Peter Donald <do...@mad.scientist.com>]

At 12:54  1/8/00 -0700, you wrote:
>But if you are paranoid then the java.security.Keystore class is the place
>to start -except it is a Java1.2 feature (and security changed again in
>java1.3) . So doing sophisticated password protection is going to be tricky
>across all ant supported platforms. Also I dont know how well the keystore
>really encrypts stuff, especially in exported JVMs.

It doesn't really encrypt anything. Most of it can be read via a hex editor
and the other bit (private keys) are likely protected by same passwd as
general keystore which can be easily found or alternatively you just do a
brute forces search and brake it. Should take all of 40 mins in JKS
.keystore files :/


Cheers,

Pete

*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power."          |
|       -Abraham Lincoln                               |
*------------------------------------------------------*