Best way to secure a password/secret key?

Hi,

I have a J2EE ecommerce application , and I want to encrypt the credit card
numbers, so I would expect to encrypt them in some way.

Trouble is however I encrypt them, it comes back to a password of some
sort - either it the key used to encrypt the card no, or the password
protects a private key.  I don't hard code the password in the code, as this
can be extracted quite easily.

What is the best way to secure a password/secret key in this context?

I am using JAAS for user authentication, and do not have access to their
password.

Thanks
Martin

On Thu, 4 Mar 2004 16:40:27 -0000, "Martin" <x@y.z> wrote or quoted :

>What is the best way to secure a password/secret key in this context?

the traditional way is not to store the literal or encrypted password,
just a digest of it.  You can then check the password by computing the
digest as seeing if it matches the digest on file.  See
http://mindprod.com/jgloss/digest.html

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

> 
>
>
> the traditional way is not to store the literal or encrypted password,
> just a digest of it.  You can then check the password by computing the
> digest as seeing if it matches the digest on file.  See
> http://mindprod.com/jgloss/digest.html
>
> --

He's looking for key storage, however (as opposed to authentication); a
digest can be used to verify knowledge of the correct password, but he
needs the actual password itself to derive a key for encryption/decryption.

At some point, this generally ends up "bubbling up" to storage of the
password (i.e., in a properties file or other configuration file).  You
would want to isolate this as much as possible, but there isn't a
one-size-fits-all solution.  WebLogic, for example, can encrypt the
passwords used for JDBC connections; this is based on a password entered
at startup of the application server.  To start it up without manually
entering the password requires hardcoding the password in the startup
script -- which gets you back to your original problem (securely storing
the password).

Spot on, nobody.

I need a similar "bootstrap" for JBoss (3.2.3)

Thanks
Martin
"nobody" <nobody@example.com> wrote in message
news:qPK2c.133282$Xp.568958@attbi_s54...
> 
>
> He's looking for key storage, however (as opposed to authentication); a
> digest can be used to verify knowledge of the correct password, but he
> needs the actual password itself to derive a key for
encryption/decryption.
>
> At some point, this generally ends up "bubbling up" to storage of the
> password (i.e., in a properties file or other configuration file).  You
> would want to isolate this as much as possible, but there isn't a
> one-size-fits-all solution.  WebLogic, for example, can encrypt the
> passwords used for JDBC connections; this is based on a password entered
> at startup of the application server.  To start it up without manually
> entering the password requires hardcoding the password in the startup
> script -- which gets you back to your original problem (securely storing
> the password).
>

I could set a system property from the command line, and read that in the
code, but how secure is that - presumably anyone could read it.

Am I chasing my tail?

Thanks
Martin

"Martin" <x@y.z> wrote in message
news:hL%2c.25980$gC2.8819@newsfe5-gui.server.ntli.net...
> Spot on, nobody.
>
> I need a similar "bootstrap" for JBoss (3.2.3)
>
> Thanks
> Martin
> "nobody" <nobody@example.com> wrote in message
> news:qPK2c.133282$Xp.568958@attbi_s54... 
> encryption/decryption. 
>
>

Martin wrote:
>
> Am I chasing my tail?

AFAIK, yes.

I'm just learning this stuff myself, but the only strategy I can imagine
is to try to mitigate the insecurity of a falliable password by using
another 'layer'. This is essentially what CA's do with their private
keys. Keep a master key on a tamper-resistant piece of hardware (e.g.
one of those $50 USB tokens) and use it to sign intermediate certs.
Those intermediate could be shorter duration and are more expendable
than the primary. The primary is held offline and can only be accessed
via interactive passwords submitted directly to the token. The
intermediate cert is then accessed by your application via a password
stored in a config file. The config file is protected via the OS's
permissions. Anyone who can get around the OS to read the config file
can access the intermediate cert, but not the primary.

I'd also like to see some 'best practices' for managing PKI.

Shane