 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / Security / March 2004Best 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 >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. Yes I'm using a hash to store the users web password- with JAAS and form based authentication. I don't know how to get hold of this password in clear text so I can use it for Password Based Encryption, leaving me to use another password to form the key for encryption/decryption of other sensitive data, and it's that second password I need to protect. For the record I'm using JAAS DatabaseServerLoginModule from JBoss. Martin > >What is the best way to secure a password/secret key in this context? > [quoted text clipped - 7 lines] > Coaching, problem solving, economical contract programming. > See http://mindprod.com/jgloss/jgloss.html for The Java Glossary. >>What is the best way to secure a password/secret key in this context? > [quoted text clipped - 4 lines] > > -- 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 > >>What is the best way to secure a password/secret key in this context? > > [quoted text clipped - 18 lines] > 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 > Spot on, nobody. > [quoted text clipped - 26 lines] > > script -- which gets you back to your original problem (securely storing > > the password). > 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 Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.