aspose file tools*
The moose likes Java in General and the fly likes Where to locate secret key? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Where to locate secret key?" Watch "Where to locate secret key?" New topic
Author

Where to locate secret key?

Edwin Dalorzo
Ranch Hand

Joined: Dec 31, 2004
Posts: 961
I am writing a small application that uses DES to cipher user passwords, after that I store the encrypted password into a database.

The application is desktop client/server application and I was wondering where should be a safe place to store the secret key used to encrypt the passwords.

Any thoughts regarding this issue?
Charles Lyons
Author
Ranch Hand

Joined: Mar 27, 2003
Posts: 836
System security depends on a number of factors - for example, I would argue that the Linux/Unix file system (on the desktop) has a better permissions system than Windows and is 'more secure' (at least more flexible) as a result. Then store the file in a directory accessible only to the user and the system administrators.

You could also use a "keystore" idea (not the RSA PKC type) which is a file encrypted by another password. Your application asks the user for a (memorable) password which then decrypts the file and releases the contained keys. However, this is additional work, even more encrypting and yet another password!

Another way would be for the user to have their own removable storage device which ensure the file is never left lying around.

However, I wonder if this is actually at all necessary in your example. If I'm correct, you're constructing a client which accepts a password and then sends the encrypted password to the server for verification. You can avoid all the hastle of storing keys by using message digests (AKA hashing) instead. This is an irreversible one-way process performed by both the client and server; it is cryptographically secure (or at least infeasible to break) and yet doesn't require encryption keys. The beauty is that it isn't actually encryption at all - but it might just serve your purpose exactly!

Try looking into java.security.MessageDigest and the MD5/SHA algorithms for more information - or post back with any problems of course!


Charles Lyons (SCJP 1.4, April 2003; SCJP 5, Dec 2006; SCWCD 1.4b, April 2004)
Author of OCEJWCD Study Companion for Oracle Exam 1Z0-899 (ISBN 0955160340 / Amazon Amazon UK )
Edwin Dalorzo
Ranch Hand

Joined: Dec 31, 2004
Posts: 961
Hi, comrade!

First of all, thanks for participating on this post.

Now, the thing is that this application will run, most probably under Windows. According to what you suggest, the end user may have access to the file where the secret key is stored, as long as no other users have access to it.

I have the hunch that this may not be exactly a good idea in this case. With the secret key the user may decrypt the password for database connection and with it he/she may decrypt other users' passwords. Even though the secret key was stored in an inaccessible place for other users, still the end user of the application would have access to it. And, ultimately, I was going to use the same secret key to encrypt all passwords.

I will research a bit about "keystore", but as far as I can understand from your post, since this alternative uses another password or secret key, at the end, I may find myself exactly where I started.

The server will not encrypt/decrypt the passwords. In rhis client/server application, the server is RDBMS, and the client handles all the application logic. I encrypt/decrypt the passwords in the client and send SQL commands to the server to store them.

I could store the key on the RDBMS, but then I couldn't decrypt the database connection password, which is actually stored in a properties file.

Maybe, MessageDigest could have been a better idea. I could have simply compared the digested password against the digest in the database.

Is that what you are actually suggesting?
[ May 08, 2006: Message edited by: Edwin Dalorzo ]
Charles Lyons
Author
Ranch Hand

Joined: Mar 27, 2003
Posts: 836
You could never have a "shared secure" file - the user running the application would have to have permissions to access the file or the OS would reject the application's attempt to access it - and you'd end up with a SecurityException at runtime! The only work around is for each user to have a different key.

In terms of digests, yes that's exactly what I'm saying: hash the password when it's first set and store the digest in the database. Then every time the client enters the password, hash that and compare the two values. This is almost the way all applications and servers do it. I say almost there because the drawback is that if you've got the possibility of an eavesdropper on the line (presumably the only reason that you'd actually be encrypting the passwords anyway), they can just as well intercept the digest and use that to authenticate themselves in the future... so you have actually achieved very little (except the password is stored hashed in the database preventing system administrators from viewing it). What often happens is the password is prepended with a "salt", which is some random code typically generated using the current timestamp. This is communicated between both client and server so they both have the same salt. Then both client and server separately merge the password and salt together in an identical manner and hash the result. The digest will be identical if the user's password (and salt) match the server's password (and salt). But the salts are different for each session, so even if an eavesdropper grabs the digest once, it can't use it again because the salt (and hence the digest) will be different on every request.

I find it a bit difficult to understand exactly what you're trying to achieve - I think you've got an application which uses a separate "user database" on a different machine containing login information in order to authenticate users to the client application. Am I correct? If this is the case, what is the requirement for encryption anyway (how secure does this need to be?) as I can see some problems with this design and the fact you're using an otherwise unencrypted network connection. You may in fact be better off using SSL so you can authenticate both client and server simultaneously, and then use plain-text (or hashed) passwords for the individual users. Do you have any more details about what exactly you're working on?
Edwin Dalorzo
Ranch Hand

Joined: Dec 31, 2004
Posts: 961
Now I am starting to understand. You are definitely right. Using encryption is not necessary in the application I am developing, actually it is completely worthless in the context that I am using it.

It will be enough if I use MessageDigest. I am going to change my approach inmediatelly.

Thanks a lot for help!
Charles Lyons
Author
Ranch Hand

Joined: Mar 27, 2003
Posts: 836
Using a digest will ensure that passwords are never stored in plain-text which is a good idea in case a rogue administrator tries to get a set of passwords to use in other applications (from experience, users typically use the same password for everything!). Hashing won't make your authentication application more secure, but it will add a level of security to your data storage!

Glad I could be of assistance. Good luck.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Where to locate secret key?
 
Similar Threads
JCE
Question about text encryption/decryption
how to encrypt the text
Enryption with Java
Suggestions on storing mail passwords safely