r/java•
taligent

How would you secure confidential data ?

I am building a website that is potentially going to contain people's bank account details similar to say Mint.com.

One concern is that if someone compromises the server then they could create a Java program to use my libraries to decrypt the data from the DB.

What would you do in my position ? Is there any specific software that specialises in storing confidential data ?

Posted Jun 18, 2011, 11:52 AM UTC

014
elpablo•

If you're asking this question then you probably shouldn't be making a site like mint.com. You shouldn't ever be writing your own libraries for encryption/decryption.

Read up on encryption. Keep your private keys private...

17
taligentOP•

I understand encryption quite well thanks having worked on a top 5 e-commerce store. Difference for them is that they dedicated security teams and constantly monitored production servers. I don't.

Point still remains. If my production servers are compromised. Someone could write a Java app which calls the methods in the decryption JARs to decrypt the password stored in the DB. No ?

I was looking for a solution that didn't involve me encrypting and storing the details in the DB myself.

-7
ZoFreX•

Someone could write a Java app which calls the methods in the decryption JARs to decrypt the password stored in the DB. No ?

Yeah I'm pretty sure you shouldn't have your job.

17
atc•

I understand encryption quite well thanks having worked on a top 5 e-commerce store. Difference for them is that they dedicated security teams and constantly monitored production servers. I don't.

Right, that means sweet fuck all. Just 'cause you've fixed a few bugs for a "top 5 e-commerce store", doesn't mean you understand encryption. In fact, the two don't necessarily go hand-in-hand; you're just trying to be arrogant.

The fact that you have to ask this question means you either haven't bothered to look properly, or don't possess the skills to work out what knowledge you need to answer the question - or, put bluntly: you don't know what you're doing.

Anyone with half an ounce of experience here would know that they'd have to start with public/private keys. Secondly, if you've got half a god damn clue (which you don't) you'd probably already be aware of initiatives like PCIDSS which the industry is moving towards (and which says you can't store the details you're talking about unless you know what you're doing, which you don't).

Last and not least: please don't do what you're going to do. You'll save consumers, the legal system, the media and anyone else who gives a shit, a hell of a lot of time. Leave it to the professionals.

6
taligentOP•

AFAIK PCIDSS has nothing to do with this. I am not storing credit card details but rather online banking details.

And again you haven't actually provided any help at all.

The private key must exist on the server in order to decrypt the database field, right ? So how do I secure the private key ?

1
atc•

Please stop what you are doing. You haven't got a clue.

2
elpablo•

The decryption libraries plus the private key will allow access to the data. So as long as you keep your private key secure then you have nothing to worry about with people who have access to the encryption libraries/algorithm.

2
taligentOP•

How do I secure the private key ?

It needs to exist on the app server right ? If the app server is compromised how can I ensure that some hacker can't decrypt my DB.

1
Neebat•

The others are telling you the truth and it sounds very much like you lack the experience to be tackling this alone.

For what it's worth, as a non-expert, if I were tackling this problem, I'd not actually store the private key, but store the XOR of the private key with the user's plain-text password, (or other login credentials.) That would be the password that you never, ever ever store in the database as plain text, right? So without the user logging in, you couldn't even access the confidential data.

You still wouldn't be secure if the system were compromised at the root level, because there are several other ways they could get access to the data in a running process of an active user-session. But it's a start.

3
Nebu•

By that logic, if those "top 5 e-commerce stores" had be compromised, what would have stopped someone from writing "a Java app which calls the methods in the decryption" library (via JNI if necessary) to "decrypt the password stored in the DB"?

There's no real difference between your previous 5 scenarios and this one. So if you had an effective security design for those 5 scenarios, why can't you apply the same security design for this one?

Honestly, the question doesn't even have anything to do with Java per se.

2
taligentOP•

The difference between them and me is that they have dedicated staff for investigating intrusion attacks and hardware security devices. I won't have that luxury.

It has to do with Java in that I remember their being Java solutions that would manage confidential data that wasn't a DB and would provide OTP security between itself and the app server.

-1
TheGadgetCat•

In a plain text file.

9
rlee0001•

You shouldn't be using their financial data for anything except making it easier for them to checkout during subsequent transactions anyway right? In that case, why is this information even on the app server? The app server certainly isn't executing the transaction. It's just a front-end. The only thing you need to store there is the fact that you have the cc# on file and its last four digits (for identification of the card and/or card selection by the user).

The app server should be in a DMZ and should communicate with the middle tier through a very strict and minimal interface (e.g. http/xml-rpc or similar). The middle tier would treat the application server as "untrusted", establishing a trust boundary between them. Obviously you should have a firewall there with only port 80 open.

Use the STRIDE method to evaluate the security threat model of the cluster.

5
taligentOP•

Thank you so much for the help. Really appreciate it.

Will definitely take it on board. The issue in my case is that the app server needs to interact with remote servers so will be exposed to the wild.

I guess I will just have to look at this situation as more of a hardware issue rather than something the J2EE platform can help out with.

1