easiest way to encrypt a CMP field?

[martin0]

I want to sensitive information in a database, like passwords. This data is represented as an attribute of an entity bean. What is the easiest way to saved it in an encrypted fashion, and what's the best way as far as security goes?

Thanks
Martin

[radl01]

Hi Martin,

the best way to keep your data save in the DB is to encryt or decrypt data using DB engine tools. Sybase SQL Anywhere do this for example.

Jan

[schmidts]

Regarding passwords, you can use one-way encryption (e.g. using MD5) and store only store/compare the results.

[martin0]

Thanks for the response so far.

My database is Postgresql 7.4.1, and as well as passwords (MD5 noted), I also want to store other data that I need read+write access.

I'm still gaining EJB knowledge - do ejbStore and ejbLoad play a part in this?

Thanks again
Martin

[schmidts]

Yes, guessing that PostgreSQL does not support transparent encryption on the database server side, you'd have to implement this in your application. EjbLoad() and ejbStore() could be the key in an implementation where you'd extend the default behaviour of CMP.
Check section 10.3.9 of the EJB 2.0 spec for details on ejbLoad/Store().
Of course you could always write some additional accessors that deal with encrytion/decryption of attributes.

[acoliver]

I'm not sure I think this is a good idea but you can go look here:

http://cvs.sourceforge.net/viewcvs.py/jboss/nukes/nukes/src/main/org/jboss/nukes/core/modules/user/UserModule.java?rev=1.29&view=markup

-Andy

[martin0]

Thanks Andrew - I'll take a look.

After a bit of research, my current thoughts are:
1) Use JAAS - I need this anyway
2) Use jboss DatabaseServerLoginModule
3) encrypt password with md5
4) (d)encrypt other data with Password-based encryption from JCE within ejbLoad/ejbStore

The only downside of 4) is that once I have created the secret key from the user's password, I have to keep that key in the users session so I can
(d)encrypt any data I need whilst they are logged in. This is okay so long as there's no memory dumps etc. I guess this is a normal scenario...

This way - no one, not even sysadmin can read the sensitive data - right?

I just need the source to DatabaseServerLoginModule so I can do md5 passwords - hopefully there's nothing in there to sink the plan.


Martin

[acoliver]

Hi Martin, most security experts tend to discourage "Security through Obscurity". Moreover, it doesn't take too many lines of code or too powerful of a machine to perform a dictionary or brute force crack these passwords. Meaning, if I've gotten to your password store, you're already wide open. I'll just query the database, grab the passwords (even encrypted) and write about a 30 line perl script that guesses until it gets it right. I'll just disassemble the class file, redeploy, capture what the user types.

I'd instead encrypt any remote EJB calls using the RMI+SSL, HTTP calls with SSL, etc. I'd put my datasource deinfitions in their own deploy directory with tight permissions. I'd put my authentication source somewhere locked down fairly tight. Prevent users from picking stupid passwords, etc. Heck, if you really want security don't use passwords :-). Ultimately, you want accountability, you need to know who did what and who had access to the information to leak it.

[martin0]

Thanks again Andrew!

Something for me to think about. I've realised I need to do some other work before I'm ready to embark on the security aspects. But I will be back to this, and might need to ask further questions then, but for now...

1) I do intend to use SSL with HTTP
2) I think the majority of my EJBs have local interfaces - so I guess that improves that aspect of security(?)
3) datasource defns in their own deploy dir?? - everything's within an ear, including the jbosscmp-jdbc.xml - I presume that's what you are talking about - how do I make that more secure, whilst still being accessible to jboss?
4) When you say authentication source - I guess you mean the db right? I agree that needs securing.
5) Good idea on password pattern enforcement
6) Don't see how to avoid passwords - ultimately even private keys have password. As far as I know, you ultimately store a key on disk, or a key/password in a users head. I thought the head was better than the disk ??

Martin

[mandrews-flarion]

on your point #6 ---

you can avoid passwords by using a so-called 'one-time-password' scheme. in that case, the user usually calculates a one-time-password using a trusted portable computing device such as a 'hardware token'. then, if an attacker gets access to a particular one-time-password, it will not be valid anymore since the user already used it.

mike