Store JDBC connection password

[Bart Kummel]

Hi all,

I have a Swing application that is connecting to a database through JDBC. All users connect to the database using the same username. The JDBC URL, user, password an other settings are stored in a .properties file. I want the password to be encrypted. I know the best way to encrypt passwords is using one-way hashes. But as I have to provide a plain text password to the JDBC driver, I don't think that's an option in this case.

So I thought of some two-way encryption for storing the password in the .properties file. But than I have to securely store the encryption password. So how do I store the encryption password within the application?

There are lots of simple examples on password hashing out on the internet, but those aren't going to help me. There's also much documentation on symmetric and asymmetric encryption. But it's very hard for me, having no experience with encryption, to determine what is a really secure solution and how to implement it.

I would really appreciate it if someone could give me some directions or even some code samples.

Best regards,
Bart Kummel

[Jimmy Clark]

Jasypt is a Java library which allows the developer to add basic encryption capabilities to his/her projects with minimum effort. It is a good API, in my opinion, and easy to use. Check it out at:

http://www.jasypt.org/
[ May 20, 2008: Message edited by: James Clark ]

[Bart Kummel]

Thanks, James, but I already found this one. It looks simple indeed. But it still faces me with the problem that I end up with an encryption password that I have to store somewhere. I could "hide" it somewhere in my code, but I thin a hacker can get around that. The company I'm working for now is especially concerned about laptops that could be stolen by a competitor on purpose. So we have to make it really secure...

Best regards,
Bart Kummel

[Jimmy Clark]

..it still faces me with the problem that I end up with an encryption password that I have to store somewhere.

You don't have to worry about hiding the encrypted password. All you need to be concerned about is securing the password for the encryption key. This should certainly not be stored on a laptop. But, it does not have to be, so there is no issue.

All users connect to the database using the same username.

This does not sound very "secure" at all.
[ May 20, 2008: Message edited by: James Clark ]

[Bart Kummel]

Ok. Let's assume I am going to use the BasicTextEncryptor. I can make a little tool to encrypt the password, like this:

BasicTextEncryptor textEncryptor = new BasicTextEncryptor();
textEncryptor.setPassword(myEncryptionPassword);
 
String myEncryptedText = textEncryptor.encrypt(myText);

The value of myEncryptedText can than be stored in the configuration file, which is distributed with the program. Then, in the application that is running on the laptop, I read the configuration file and I have to decrypt the password before I pass it on to the JDBC driver, like this:

    
BasicTextEncryptor textEncryptor = new BasicTextEncryptor();
textEncryptor.setPassword(myEncryptionPassword);
 
String plainText = textEncryptor.decrypt(myEncryptedText);

In this case, I need the encryptionPassword in the application, or am I missing something?

[Ulf Dittmer]

Yes, you need to use the password in the application, but James' point is that it does not need to be stored - the user should enter it. If you want to avoid that then there's really no way out.

There are a number of security issues here. First is that all users have the same password (which I take to mean they also use the account). So the server really has no idea in who's logging in, and you can't selectively enable/disable accounts. That would be very handy if you're worried about compromised laptops.

Also, you really shouldn't open up a database for straight JDBC use over the internet. Client-side applications are inherently not trustworthy, and Java code is especially easy to manipulate. Have you considered a thin proxy server that takes requests from the client app (maybe over HTTP or raw TCP/IP) and forwards them to the DB?

[Pat Farrell]

You need to think through your usage case carefully. What are you trying to do, really.

As others have said, you should use protection where ever its needed, such as JDBC over the internet is really a bad idea. Use TLS which MySql and others support.

But the fundamental question is where is the password kept, really. It matters not a bit what you are protecting, it can be an enciphered file system, or secure access to a database, nearly anything. If you rely on a key/passphrase, where do you store it.

If you hide it in the source code, or in an obscure place, you are just using security by obscurity. SBO. This is between trivial to break and useless.

If you don't store it, you have to enter it every time the system is started. This may be only once a year or so, but it still requires human action every time you start it. In many cases, you don't have humans managing it 24x7, so this can mean you are down until someone types in the magic key.

There are assorted semi-useful approaches, such as storing the key in a USB thumb drive. but if the bad guy has the thumb drive, you are SOL.

There are very expensive solutions used in banking networks, hardware boxes that keep keys, do challenge response protocols, take two smart cards from two people to enable it, wipe all memory if the box is opened, etc. Most folks can't afford to need something like that, but they do exist.

[Jimmy Clark]

In this case, I need the encryptionPassword in the application, or am I missing something?

Bart, you are missing something.

The encrypted password for the JDBC connection is different that the password for the encryption key generator. These are two different passwords. They are not stored in the same location.

The encrypted password is decrypted and passed to database at runtime, in memory. The decrypted password is never exposed to human eyes and is never stored anywhere.

A hacker could not use the encrypted password to break into the database.
[ May 20, 2008: Message edited by: James Clark ]

[Bart Kummel]

@Ulf, Pat
I think I forgot to mention some essential information. The database is on the laptop too. Representatives of the company get a laptop with a read-only copy of the corporate database and a Java application to view that database. The database on the laptop is a MS SQL Server Express 2005 database and I use the JDBC driver shipped with that database.

@James
Yes, I understand that there are two passwords, the encrypted password and the encryption password. But I don't understand how the encrypted password could be decrypted without the encryption password. I read some theoretical articles about asymmetric encryption, I suppose it has to do something with that. But how do I implement this in Java?

Thank you all for your help so far!

Best regards,
Bart Kummel
[ May 20, 2008: Message edited by: Bart Kummel ]

[Pat Farrell]

OK. so logically the database is on a CD and you give it to people. You don't want bad guys to read it.

You will have humans who run some program to read the database, and so you can ask them for a password.

This is easy. You want to use a one way, asymetric hash. You use it as follows:

prompt user for password

calculate a HMAC

Compare HMAC just calculated to a HMAC that is in the program or database

If same, allow access

if not same, wait a while, then ask again, count failures, whine if large

Google for HMAC (hash message authentication code), they are easy to implement.

Next design question is do you use one level of password, or have some time based key.

Problem is, supposed employee gets CD and laptop, and is given key(s).
Employee takes CD home and copies data and program to desktop. They quits company.

So you may want to have a key retirement schedule, say once a quarter or once a month, you give out new keys, which is just the first level key, to see if you are allowed into the system. With that, you can then get the real key, and provide access.

[Jimmy Clark]

Bart, There are a couple of ways to code with the Jasypt API and you can different degrees of "security" depending upon your needs. You need to experiment and learn the API.

The good thing about this API is that you don't need to have a detailed understanding of HOW the encryption algorithms are working. The programmers of Jasypt have encapsulated this complexity and enable you to have a very secure encryption without having to know low-level details of how it works. You are free to study the details if you want. However, I sense that you have other things to worry about. The choice is yours.

At a high-level, you configure an EncryptorRegistry with a type of Encryptor. You configure the registry and Encryptor with a certain password. This is done at one place in the code. When you decrypt the encrypted password, you get an object from the registry. So you don't directly touch the encryption password ever again.

Below is an example of how the configuration is done for use with Hibernate.

StandardPBEStringEncryptor stringEncryptor = 
    new StandardPBEStringEncryptor();
stringEncryptor.setPassword(mode);
              
HibernatePBEEncryptorRegistry registry = 
     HibernatePBEEncryptorRegistry.getInstance();
                 
registry.registerPBEStringEncryptor("strongHibernateEncryptor", stringEncryptor);

The variable "mode" contains the encryption password.
[ May 20, 2008: Message edited by: James Clark ]

[Bart Kummel]

@Pat
The database is not distributed on CD. Every time a representative visits the company office, he can update his laptop database over the internal network. The laptop itself is pretty good "locked down". Representatives do not have rights they do not need. (For example, it is even not possible to connect a USB storage device.)

I understand the approach you are explaining with your bullet list. It's the approach that is advised all over the Internet for password encryption. The point is, I was not looking for a solution where my own program decides whether access is granted or not. I'm using a database connection, which needs a password. And I want to store that password in a safe way.

@James
Thanks for your explanation. Just to verify if I get it right: In your approach, you set the encryption password just once, right? In case of a web application that is started once and then runs 'for ever', this means we don't touch the encryption password ever again. But in case of a Swing application running on a laptop computer, that would mean setting the encryption password every time the application runs. Which could potentially be several times a day. Right?

[Jimmy Clark]

Thanks for your explanation. Just to verify if I get it right: In your approach, you set the encryption password just once, right?

I have done it a couple of ways. When doing it with a String encryptor and Hibernate, I assigned the encryption password just once. The other way I have done it is without Hibernate, and there was no encryption password. We use the default algorithms.

But in case of a Swing application running on a laptop computer, that would mean setting the encryption password every time the application runs. Which could potentially be several times a day. Right?

There are a few limitations that stem from this design. However, as I mentioned, there are ways to use this API without assigning a specific encryption password.
[ May 21, 2008: Message edited by: James Clark ]

[Bart Kummel]

Hi James,

Could you please be so kind as to be a bit more specific about the ways yo use Jasypt without assigning a specific encryption password?

Best regards,
Bart Kummel

[Jimmy Clark]

What would you like to know?

[Nicholas Jordan]

Glancing at Jasypt, it looks promising. Without a way to store a pw somewhere that it can be brought up at runtime, the design would be weak. I am working on exactly the same problem, and what you are asking James is likely to become self-referential. I assume from the wording of your post you can grasp the potential, subtle but hidden risks therein.

Without any directed effort toward silly answers, what you are asking is how can code assign a password without assigning a password. The site states: Jasypt follows the RSA standards for password-based cryptography,; When they do that the letters RSA may be the gold you are digging James for. We assume what you are trying to do would be better if there were no way a user could recover the pw used by the database.

Let's classify this as a challenging research problem. We got to the point on one large installation where there was no point in having passwords. Physical keys actually, I had to design a system where the total lack of willingness to keep up with keys had to be insulated from myself. Not a lot of fun. If everyone is already using the same username and all you want to do is encipher the pw from routine curiosity seekers, then a simple data protection scheme such as DES or Crypt() may be sufficient. At least we are not using tamper proof schema vis-a-vis ten cent locks.

That can be a poor design.

RSA .... I have read so many of these I am blurring, whatever the public-key/private-key protocol is called, the keys can be stored remotely in a fashion that totally isolates them from whatever is on the laptops. Any protocol that does not use some sort of protected secret key-piece, but can isolate the keys totally would be - to put it mildly - an innovation in computer science.

In general, the idea of a Salesman leaving the laptop laying somewhere is not beyond the scope of the problem. That invites shuddering and insightful joking. Ok, what I do in that situation is not allow anything to be placed in on the laptop that would be of value beyond the immediate needs of that laptop.....

And here is where the problem raises from the chamber of silent risks: Assume 100 Sales ops for 1,000 days. That works out to xxxx hours machine exposed to undergrad computer science student home alone: A relative of some kind, bascially honest. Commutes to school and starts to work breaking the pw as an exercise but gets distracted. Salesman calls, "Honey, would you bring my laptop? I have an urgent, unexpected large order."

So far, so good. Riding in the vehicle happens to be a friend of the family,.......

Okay, so what do we do?

The only way to fix this problem is by an intelocking control mechanisim. That is well known in accounting.

Design the system such that it will operate with 20% of the system broken. You will have your solution.

[Jimmy Clark]

1. If an encrypted password is stored on the laptop. Something like:

afdsfj908434gajdklsgvasdHKJHUIGF3654238754873256SMNklcvnsdlkngvsdfa

1.b. There is other encrypted data. Something like:

dsafu3257ewyufgiosdja82359uetuidsj3259082u3098509284350824309

3248509324utgoiauert0934850968i34-t0yi8-er0q98t-0we89349833t8

2. Now let's say that the password is stored in a properties configuration parameter named:

sdfjadsio84

2.b. The other encrytped data is stored in the same properties file under the names:

djfodsi77

dsmnklfh2

3. Somewhere in the code, I don't know where, the code grabs the encrypted password, decrypts it and connects to a relational database. The application works fine.

4. The laptop is lossed and Joe Hack-a-Lot finds it and finds the properties file with the encrypted strings.

Question #1: How will he/she know which one is the database password?
Question #2: How will he/she know how to decrypt the password?

If you encrypt the database IP address or URL, how will he/she know where the database is located or which JDBC Driver is used?

Now say that the password and all the other JDBC data is stored in a class file. Joe Hack-a-Lot needs to decompile the entire application and sift through the muck only to find a bunch of enrypted Strings. Somethings like:

private String sdfjadsio84 "afdsfj908434gajdklsgvasdHKJHUIGF3654238754873256SMNklcvnsdlkngvsdfa";
 
 
private String djfodsi77 "dsafu3257ewyufgiosdja82359uetuidsj3259082u3098509284350824309";
 
private String sdfjadsio "843248509324utgoiauert0934850968i34-t0yi8-er0q98t-0we89349833t8";
 

[ May 21, 2008: Message edited by: James Clark ]

[Bart Kummel]

Well, if Joe succeeds in decompiling your proposed code, he will also find some statements like:

connection.setProperty("url", decrypt(djfodsi77));
connection.setProperty("userName", decrypt(sdfjadsio));
connection.setProperty("password", decrtpt(sdfjadsio84));

So I guess he won't have a hard time guessing which of the variables contains the password, the username and the URL. And if he manages to decompile the code, I think he will find the decryption password as well... This was the scenario I started out with when I decided to post the question here!

[Nicholas Jordan]

Originally posted by Bart Kummel:
(...snip...)I started out with when I decided to post the question here!(...snip...)

Good, this is called iterative development.

So I guess he won't have a hard time guessing which of the variables contains the password, the username and the URL. And if he manages to decompile the code, I think he will find the decryption password as well... This was the scenario

Correct.

[Pat Farrell]

Originally posted by Bart Kummel:
@Pat
The database is not distributed on CD. .... The laptop itself is pretty good "locked down". Representatives do not have rights they do not need.

whether access is granted or not. I'm using a database connection, which needs a password. And I want to store that password in a safe way.

I know you were not literally using a CD, but the concepts are the same.
And you need to get a handle on some of the longer term issues.

There is no way that a laptop is locked down. Thats a best a dream.

The key is that you don't store a password. Can't be done safely.
If its fixed, it is subject to replay attacks, has no expiration date, etc.

So if you want to provide access, you want to use a human remembered password that is entered, and verified over the net. Setup a JSP/servlet with SSL/TLS, have the user log onto the webpage using a browser.

Make the password be exchanged, perhaps cut and pasted by hand, or have a client side code programmed to use a HTTPS client library such as the Apache one.

Fixed passwords don't work.
Putting the password someplace in the code is at best Security By Obscurity.

Its not good enough to keep anyone but your twelve year old sister out. Don't do it.

[Nicholas Jordan]

I'm glad to see Pat on this, Original Poster: You need to look at some unseen risks. I would be glad to just put it up but most people cannot deal with what is really happening when some situations occur. People just will not believe that someone would do something like that.

If I may suggest: All sales ops required to provide a short passage from a favorite work. Get an MD-5 or something, it will not be recoverable so have an easy route to 'get a new password' .... Store that MD-5 or HMAC on the device. Since we must assume that all sales ops are already using the password, enciphering the pw would provide an improvement in security.

Because of some heavy field experience, I will stop there. To see why, read the Feb 2005 Texas Monthly on the subject of Power. Read especially DA Ronnie Earl's burial plan.....

The day you can bust my signature is the day you will have some idea how to go about solving your challenge.

At that point I will advise you to do individual record locking and work on some way of having your sales reps each get an individual pw. There are reasons why.

Is there anyplace in the authorization chain you can install a hook that will do this?...

[Jimmy Clark]

And if he manages to decompile the code, I think he will find the decryption password as well...

There is no "decryption" password.

The encryption password used to configure the registry will not help him/her decrypt the encrypted strings. He/She will still need to decompile the Jasypt class libraries and search/decipher the decryption algorithm.
[ May 21, 2008: Message edited by: James Clark ]

[Nicholas Jordan]

Originally posted by James Clark:
There is no "decryption" password.

Uh, without reading the rest of your post - you just screwed up.

PS: Your sister wanted me to show you this:

public class studioStudio
{
    private static transient String afdsfj =
    "gfrgfnsfahetbqjbyyrlruggho9frtanebsbqvnesnrenfryccnqbbtyyN";
    public static void runLikeADog()
    {
        StringBuffer asdf = new StringBuffer(afdsfj.length());
        char offset = (char) 13;//
        int length = afdsfj.length();
        do
        {
            char c = (char) afdsfj.charAt(--length);
            if(c == ' '){continue;}
            c += offset;
            if(c > 'z'){c -= (char) 26;}
            asdf.append(c);
        }
        while(length > 0x0000);
        System.out.println(asdf.toString());
    }
}

[Nicholas Jordan]

Okay, what we're missing here is that for FIPS-127 the pw can be kept in a Password Store - the use of a strong password on laptops is pretty much pointless: (As stated). It is generally accepted practice the pw must be stored somewhere. Thus, the design of a Password Store.

This may be kept such as on a server or other protected machine. It is accepted practice the there must be someplace to store pw or it's game-over. Each sales op could be assigned a passphrase of their choosing, such that it is easy to remember. Then, unplugged from Central Point, only the passphrase is carried, and then only in the rep's fascination.

At bootup and logon, laptop dialsup a machine, which checks MD-5 or HMAC of what comes in. This negotiation occurs on a machine that may be observerved such as any central machine. If passphrases hashes, the pw is unloaded from the local store and sent up to JDBC driver. Secondary controls such as logon time and and enciphering the response from FIPS-127 along with common sense should provide sufficient controls: Title company handles it's part, Bank does the financials. This would improve over putting the pw in the clear.

[Jimmy Clark]

In the Jasypt documentation or API where is there any mention of "a decryption password"?

Regardless, my statement was a correction of the sentence of the poster quoting my previous sentence incorrectly. I never mention "decryption password" in my sentence. Because when configuring the Jasypt registry, there is no setting of a "decryption password." Hence, there is no "decryption" password.
[ May 21, 2008: Message edited by: James Clark ]

[Nicholas Jordan]

Originally posted by James Clark:
(...snip...)Hence, there is no "decryption" password.

( Other remarks noted. )

The 'subtleties' of the language suggest I obtain addional clarification of your basis. I have a clear vison of what I am saying, so also do you. Because we may reasonably assume there is real value on the line and this is not a student exercise in a constrained arena I advise that risk analysis should include basis for prior statements - which you have done.

Next in line is, as I hope you noted, I wrote a one-off code where I may have used plain language. That took me maybe ten minutes, it has the first pass run on some Meaningless Drivel replacing the original string. In cryptographic work, what I did is not even encipherment ~ let alone that I put up the code that I ran to get the shift.

If you are saying what I think you are saying, then you are designing an access control. This may have several approaches. If you wish to protect a password - given by the database - then my approach will work for a reasonable interpretation of your design. We normally have people who do not wish to learn computer science using the computer for it's intended purpose. I am learning from helping you, and in fact have already incorporated some design ideas.

The basis of my assertion is that encipherment is either secret-key or KeyPair. Identity Management is not encipherment. The site you cite states: "Jasypt is a java library which allows the developer to add basic encryption capabilities to his/her projects with minimum effort, and without the need of ... "

There are several keywords there that raise thorny issues for experienced workers. { :roll: }

Most professionals won't touch them, I am not a professional in this field and sought to leverage your efforts. When we have encryption capabilities and without the need of in the same sentence, that is a field I am an expert in.

What we need to do is put the pw in a PasswordStore.

[Bart Kummel]

Gentlemen,

It seems like I'm stuck in some academical discussion. I appreciate your willingness to help out, but honestly I don't think the last few post are of any practical use for my project. The long discussions about subtle differences in meanings of words are especially hard for me, since I'm not a native English speaker.

I think what I learned from the discussion is that I should not store a password on the laptop. The best thing would probably be to let the user type the password every time he starts the application.

Also someone suggested to use some webservice like construction for authentication, but that's not going to work. As you can understand, the reason for putting a copy of an entire database on the laptop is the requirement that it should be possible to use the application without any connection to the Internet or the company's network.

Anyway, thanks for you help. After all, you are saving me a lot of work, since I do not have to encrypt a password, but just passing on the password the user types.

Best regards,
Bart Kummel

[Jimmy Clark]

As you can understand, the reason for putting a copy of an entire database on the laptop is the requirement that it should be possible to use the application without any connection to the Internet or the company's network.

A copy of the database on each laptop? This does not sound very "secure" and it sounds expensive if you are using a commercial database.

After all, you are saving me a lot of work, since I do not have to encrypt a password, but just passing on the password the user types.

Will this be the password that the application uses to connect to the database?
[ May 22, 2008: Message edited by: James Clark ]

[Nicholas Jordan]

You are very welcome. There are some issues which were given detailed treatement but the idea of passwords and databases for a commercial work involves possible risks that have to be given this depth.

It seems like I'm stuck in some academical discussion. I appreciate your willingness to help out, but honestly I don't think the last few post are of any practical use for my project. The long discussions about subtle differences in meanings of words are especially hard for me, since I'm not a native English speaker.

That is intrinsic in Security. No problem,...

I think what I learned from the discussion is that I should not store a password on the laptop. The best thing would probably be to let the user type the password every time he starts the application.

Yes, yes, yes. I have been reading and thinking about what you said and reading some very advanced work on the matter. If you do nothing but have the user type in the pw each time then this was totally worth it for all of us.

Also someone suggested to use some webservice like construction for authentication, but that's not going to work. As you can understand, the reason for putting a copy of an entire database on the laptop is the requirement that it should be possible to use the application without any connection to the Internet or the company's network.

Good idea to consider, what matters is how valuable the information on the laptop is. I would not use an outside service, the idea is relenquishing physical control of information sight-unseen on the basis of what can be dreamed up for webpage design has possible justificaion .... but I do not do that.

Anyway, thanks for you help. After all, you are saving me a lot of work, since I do not have to encrypt a password, but just passing on the password the user types.

Yes, and pass it to a char[] - not a string then wipe the char[] then set the char[] to null,.... carry on at that point as usual.