You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-user@db.apache.org by David Van Couvering <da...@vancouvering.com> on 2007/06/16 01:14:36 UTC
User/password encryption and deployment
Let's say I want to deploy my application client with Java DB to 1000
different client machines.
If I understand things correctly, if you want to use encrypted
user/password, you have to install the IBM JCE on each of these client
machines and also go in and modify the java.security file in the
lib/security directory of your JRE (see
http://db.apache.org/derby/docs/10.2/adminguide/tadminapps811695.html)
This doesn't seem reasonable/feasible for large deployments, or am I
missing something?
Also, the page doesn't tell you where to get the IBM JCE, except "IBM
Developer Kit for the Java Platform 1.4 or later comes with IBM JCE".
Hm.
Thanks,
David
Re: User/password encryption and deployment
Posted by Kathey Marsden <km...@sbcglobal.net>.
David Van Couvering wrote:
> Let's say I want to deploy ... to 1000
> different client machines.
[snip]
Thrilled to see folks thinking about scalable deployment. Next step in
the thought process is scalable upgrade..
"Lets say we have a million derby deployments and I want to require all
of them to change their policy file...". #:)
Kathey
Re: User/password encryption and deployment
Posted by "Bernt M. Johnsen" <Be...@Sun.COM>.
>>>>>>>>>>>> David Van Couvering wrote (2007-06-17 18:14:38):
> Oh, I get it now, 10.3 will add support for SSL. But this will
> encrypt all network traffic. If you just want to encrypt the
> password, you have to use the existing password encryption
> functionality (either ENCRYPT or STRONG SUBSTITUTION), right?
If you want to encrypt the password, you use
ENCRYPTED_USER_AND_PASSWORD_SECURITY, but that's not supported by
Sun's JCE due to a too short DRDA DHS shared prime (just 256 bits).
An alternative is then to use STRONG_PASSWORD_SUBSTITUTE_SECURITY,
which sends a hashed password. (Hashing in this context is a kind of
one-way encryption. To verify the password, the server repeats the
hashing and compares hash values).
> And for 10.2, there is no SSL support, right?
Correct.
>
> David
>
> On 6/16/07, Andrew McIntyre <mc...@gmail.com> wrote:
> >On 6/15/07, Bill Shannon <bi...@sun.com> wrote:
> >>
> >> I think the idea is to protect the communication between the client
> >> and the server so that passwords aren't sent in the clear. None of
> >> the data being stored in the database is being encrypted, just the
> >> client/server communication.
> >>
> >> It *is* 2007. Isn't this pretty much standard by now?
> >
> >See the discussion in http://issues.apache.org/jira/browse/DERBY-65
> >
> >SSL is the recommended alternative to using the secure password
> >protocol defined by the DRDA specification. Bernt Johnsen worked on
> >this for 10.3, due out shortly, and it appears to be complete:
> >
> >https://issues.apache.org/jira/browse/DERBY-2108
> >
> >andrew
> >
--
Bernt Marius Johnsen, Database Technology Group,
Staff Engineer, Technical Lead Derby/Java DB
Sun Microsystems, Trondheim, Norway
Re: User/password encryption and deployment
Posted by Francois Orsini <fr...@gmail.com>.
Yes, you might want to use STRONG_PASSWORD_SUBSTITUTE_SECURITY (8) since it
does not actually send some encrypted password but a substitute based on
Hashing and computation with values (seeds) exchanged with the client and
the server. It works for Sun and IBM JRE's. Using SSL is duoable in 10.3 but
it is over-kill in my opinion if you don't need to encrypt *all* data
exchanged between a client and server. Some applications do not even need to
use SSL (or password encryption, but why not) if there already on a secure
private network (behind the firewall for instance), by using IPSEC
protocols.
On 6/17/07, David Van Couvering <da...@vancouvering.com> wrote:
>
> Oh, I get it now, 10.3 will add support for SSL. But this will
> encrypt all network traffic. If you just want to encrypt the
> password, you have to use the existing password encryption
> functionality (either ENCRYPT or STRONG SUBSTITUTION), right?
>
> And for 10.2, there is no SSL support, right?
>
> David
>
> On 6/16/07, Andrew McIntyre <mc...@gmail.com> wrote:
> > On 6/15/07, Bill Shannon <bi...@sun.com> wrote:
> > >
> > > I think the idea is to protect the communication between the client
> > > and the server so that passwords aren't sent in the clear. None of
> > > the data being stored in the database is being encrypted, just the
> > > client/server communication.
> > >
> > > It *is* 2007. Isn't this pretty much standard by now?
> >
> > See the discussion in http://issues.apache.org/jira/browse/DERBY-65
> >
> > SSL is the recommended alternative to using the secure password
> > protocol defined by the DRDA specification. Bernt Johnsen worked on
> > this for 10.3, due out shortly, and it appears to be complete:
> >
> > https://issues.apache.org/jira/browse/DERBY-2108
> >
> > andrew
> >
>
Re: User/password encryption and deployment
Posted by David Van Couvering <da...@vancouvering.com>.
Oh, I get it now, 10.3 will add support for SSL. But this will
encrypt all network traffic. If you just want to encrypt the
password, you have to use the existing password encryption
functionality (either ENCRYPT or STRONG SUBSTITUTION), right?
And for 10.2, there is no SSL support, right?
David
On 6/16/07, Andrew McIntyre <mc...@gmail.com> wrote:
> On 6/15/07, Bill Shannon <bi...@sun.com> wrote:
> >
> > I think the idea is to protect the communication between the client
> > and the server so that passwords aren't sent in the clear. None of
> > the data being stored in the database is being encrypted, just the
> > client/server communication.
> >
> > It *is* 2007. Isn't this pretty much standard by now?
>
> See the discussion in http://issues.apache.org/jira/browse/DERBY-65
>
> SSL is the recommended alternative to using the secure password
> protocol defined by the DRDA specification. Bernt Johnsen worked on
> this for 10.3, due out shortly, and it appears to be complete:
>
> https://issues.apache.org/jira/browse/DERBY-2108
>
> andrew
>
Re: User/password encryption and deployment
Posted by David Van Couvering <da...@vancouvering.com>.
Hi, Andrew. This is helpful, thanks. But my attempts to find out how
to "use" SSL/TLS is not clear. Is there a way to use this over any
old TCP socket connection? The closest thing I can find is STARTTLS,
which is what Bill was referring to, but this appears to require
cooperation within the network code. A regular old user of Derby
doesn't seem to have the power to make a connection happen over SSL
S when you say "SSL is the recommended alternative," exactly what do
you mean? How would you tell a user to *do* this?
Thanks,
David
On 6/16/07, Andrew McIntyre <mc...@gmail.com> wrote:
> On 6/15/07, Bill Shannon <bi...@sun.com> wrote:
> >
> > I think the idea is to protect the communication between the client
> > and the server so that passwords aren't sent in the clear. None of
> > the data being stored in the database is being encrypted, just the
> > client/server communication.
> >
> > It *is* 2007. Isn't this pretty much standard by now?
>
> See the discussion in http://issues.apache.org/jira/browse/DERBY-65
>
> SSL is the recommended alternative to using the secure password
> protocol defined by the DRDA specification. Bernt Johnsen worked on
> this for 10.3, due out shortly, and it appears to be complete:
>
> https://issues.apache.org/jira/browse/DERBY-2108
>
> andrew
>
Re: User/password encryption and deployment
Posted by Andrew McIntyre <mc...@gmail.com>.
On 6/15/07, Bill Shannon <bi...@sun.com> wrote:
>
> I think the idea is to protect the communication between the client
> and the server so that passwords aren't sent in the clear. None of
> the data being stored in the database is being encrypted, just the
> client/server communication.
>
> It *is* 2007. Isn't this pretty much standard by now?
See the discussion in http://issues.apache.org/jira/browse/DERBY-65
SSL is the recommended alternative to using the secure password
protocol defined by the DRDA specification. Bernt Johnsen worked on
this for 10.3, due out shortly, and it appears to be complete:
https://issues.apache.org/jira/browse/DERBY-2108
andrew
Re: User/password encryption and deployment
Posted by "Bernt M. Johnsen" <Be...@Sun.COM>.
>>>>>>>>>>>> Bernt M. Johnsen wrote (2007-06-16 18:43:51):
> >>>>>>>>>>>> derby@segel.com wrote (2007-06-16 07:53:55):
> > [...]
> > > There is, however small issue, if you choose
> > > ENCRYPTED_USER_AND_PASSWORD_SECURITY, newer Sun JCE's (from 1.4, I
> > > think) does not support the shared DHS value defined in the DRDA
> > > protocol. It's too weak. As an alternative solution for passsword
> > > protection, Francois implemented STRONG_PASSWORD_SUBSTITUTE_SECURITY.
> >
> > Define "too weak".
>
> "Too week" in the sense that the JCE throws an exception and says that
> it does not support it due to the "shortness" (sorry, I don't remember
> the exact details on a saturday after a few beers in the sun ;-).
Ok. From the Derby docs (EncryptionManager):
// The agreed public value for the Diffie-Hellman prime is 256 bits
// and hence the encrytion will work only if the jce provider supports a 256 bits prime
This is specified in the DRDA protocol, and thus can't be changed by
the Derby delevolpers. With Sun's JCE you get:
java.security.InvalidAlgorithmParameterException: Prime size must be multiple of 64, and can only range from 512 to 1024 (inclusive)
So, Sun's JCE supports primes in the range 512-1024 bits while the
DRDA protocol has specicied a prime of 256 bits.
--
Bernt Marius Johnsen, Database Technology Group,
Staff Engineer, Technical Lead Derby/Java DB
Sun Microsystems, Trondheim, Norway
Re: User/password encryption and deployment
Posted by "Bernt M. Johnsen" <Be...@Sun.COM>.
>>>>>>>>>>>> derby@segel.com wrote (2007-06-16 07:53:55):
> [...]
> > There is, however small issue, if you choose
> > ENCRYPTED_USER_AND_PASSWORD_SECURITY, newer Sun JCE's (from 1.4, I
> > think) does not support the shared DHS value defined in the DRDA
> > protocol. It's too weak. As an alternative solution for passsword
> > protection, Francois implemented STRONG_PASSWORD_SUBSTITUTE_SECURITY.
>
> Define "too weak".
"Too week" in the sense that the JCE throws an exception and says that
it does not support it due to the "shortness" (sorry, I don't remember
the exact details on a saturday after a few beers in the sun ;-).
> [...]
>
> Is Sun and/or the community going to support DRDA for Derby/JavaDB?
Derby use DRDA as the client/server protocol. I don't think there
exist any initaitives to change that.
--
Bernt Marius Johnsen, Database Technology Group,
Staff Engineer, Technical Lead Derby/Java DB
Sun Microsystems, Trondheim, Norway
Re: User/password encryption and deployment
Posted by Daniel John Debrunner <dj...@apache.org>.
Bernt M. Johnsen wrote:
>>>>>>>>>>>>> Michael Segel wrote (2007-06-16 00:23:56):
>> Which is why I'm a little suspect that the *only* way to do encryption on
>> the wire is to be forced to bring in IBM's JCE.
>
> You don't need the IBM JCE. Sun's JDK comes with and JCE which works
> just fine. The docs tries to tell you that if you use an old IBM
> environment, you need to install IBMS JCE searately.
That section (installing an IBM JCE) should be removed from the
documentation for 10.3 onwards since JDK 1.4 is the lowest supported JVM
level.
>
> There is, however small issue, if you choose
> ENCRYPTED_USER_AND_PASSWORD_SECURITY, newer Sun JCE's (from 1.4, I
> think) does not support the shared DHS value defined in the DRDA
> protocol. It's too weak. As an alternative solution for passsword
> protection, Francois implemented STRONG_PASSWORD_SUBSTITUTE_SECURITY.
This information would be great to add to the docs. Restating the
requirements in terms of a JCE that supports "the shared DHS value
defined in the DRDA protocol" (whatever the correct JCE term for that
is) and not specifically the IBM JCE. The documentation then should
state that this is not supported by some JCEs due to its weakness and an
alternative is to use STRONG_PASSWORD_SUBSTITUTE_SECURITY (and/or SSL?).
Dan.
RE: User/password encryption and deployment
Posted by de...@segel.com.
> -----Original Message-----
> From: Bernt.Johnsen@Sun.COM [mailto:Bernt.Johnsen@Sun.COM]
> Sent: Saturday, June 16, 2007 3:19 AM
> To: Derby Discussion; msegel@segel.com
> Subject: Re: User/password encryption and deployment
>
> >>>>>>>>>>>> Michael Segel wrote (2007-06-16 00:23:56):
> > Which is why I'm a little suspect that the *only* way to do encryption
> on
> > the wire is to be forced to bring in IBM's JCE.
>
> You don't need the IBM JCE. Sun's JDK comes with and JCE which works
> just fine. The docs tries to tell you that if you use an old IBM
> environment, you need to install IBMS JCE searately.
>
Ok, then the documentation needs to be updated. As written it is a *tad*
confusing.
> There is, however small issue, if you choose
> ENCRYPTED_USER_AND_PASSWORD_SECURITY, newer Sun JCE's (from 1.4, I
> think) does not support the shared DHS value defined in the DRDA
> protocol. It's too weak. As an alternative solution for passsword
> protection, Francois implemented STRONG_PASSWORD_SUBSTITUTE_SECURITY.
Define "too weak".
If you're talking about an encrypted database, then yes. If you're talking
about transport layer security, then maybe not.
Being a paranoid DBA, I'm all for strong security like some of the newer
features introduced IBM's IDS 11 (That's the old Informix database).
However, I'm also practical.
When applying security, you need to take a look at the entire system, use
case and potential threats.
It is interesting is that you have Sun's view of the world and IBM's. IBM is
"pushing" their DRDA in to all of their products and are writing their front
end tools/adaptors to this specification, such that RoR, Java, Python and I
think Perl will be able to use a common adaptor to touch all of their
databases. (Read DB2[i,z,luw], and IDS) Not sure how Cloudscape/Derby fits
in with their strategy since they're dropping support in 2008.
Is Sun and/or the community going to support DRDA for Derby/JavaDB?
Re: User/password encryption and deployment
Posted by "Bernt M. Johnsen" <Be...@Sun.COM>.
>>>>>>>>>>>> Michael Segel wrote (2007-06-16 00:23:56):
> Which is why I'm a little suspect that the *only* way to do encryption on
> the wire is to be forced to bring in IBM's JCE.
You don't need the IBM JCE. Sun's JDK comes with and JCE which works
just fine. The docs tries to tell you that if you use an old IBM
environment, you need to install IBMS JCE searately.
There is, however small issue, if you choose
ENCRYPTED_USER_AND_PASSWORD_SECURITY, newer Sun JCE's (from 1.4, I
think) does not support the shared DHS value defined in the DRDA
protocol. It's too weak. As an alternative solution for passsword
protection, Francois implemented STRONG_PASSWORD_SUBSTITUTE_SECURITY.
--
Bernt Marius Johnsen, Database Technology Group,
Staff Engineer, Technical Lead Derby/Java DB
Sun Microsystems, Trondheim, Norway
Re: User/password encryption and deployment
Posted by Bill Shannon <bi...@sun.com>.
derby@segel.com wrote:
> Just to follow up to my own post...
> http://db.apache.org/derby/docs/10.2/adminguide/tadminapps811695.html)
>
> Unless my tired eyes deceive me... (Its 12:30am and its been a long
> day...),
>
> This deals with encryption of the database and not encryption between the
> client and the database.
It certainly isn't clear...
It talks about an "encrypted user ID", whatever that is, and
"password security", all in the context of the network server.
That all sounds like it's trying to protect the password.
Then it goes on to talk about an "encrypted database". I can't
tell if they changed the subject in mid paragraph, or if these
things are somehow connected.
RE: User/password encryption and deployment
Posted by de...@segel.com.
Just to follow up to my own post...
http://db.apache.org/derby/docs/10.2/adminguide/tadminapps811695.html)
Unless my tired eyes deceive me... (Its 12:30am and its been a long
day...),
This deals with encryption of the database and not encryption between the
client and the database.
> -----Original Message-----
> From: Michael Segel [mailto:msegel@segel.com]
> Sent: Saturday, June 16, 2007 12:24 AM
> To: 'Derby Discussion'
> Subject: RE: User/password encryption and deployment
>
>
>
> > -----Original Message-----
> > From: Bill Shannon [mailto:bill.shannon@sun.com]
> > Sent: Saturday, June 16, 2007 12:04 AM
> > To: Derby Discussion
> > Subject: Re: User/password encryption and deployment
> >
> > derby@segel.com wrote:
> > > Maybe I am missing something but what exactly are you encrypting?
> > >
> > > SSL is transmission from client to server over the net.
> > >
> > > Derby is Cloudscape till 2008 when IBM cuts loose.
> > >
> > > So are you trying to use an encryption data type?
> > >
> > > And how strong of an encryption do you want?
> >
> > I think the idea is to protect the communication between the client
> > and the server so that passwords aren't sent in the clear. None of
> > the data being stored in the database is being encrypted, just the
> > client/server communication.
> >
> > It *is* 2007. Isn't this pretty much standard by now?
>
> Uhm well, one would think.
>
> Which is why I'm a little suspect that the *only* way to do encryption on
> the wire is to be forced to bring in IBM's JCE.
>
> I'll admit I haven't looked at this issue in depth, just trying to
> understand the use case and see if its beyond encrypting the session ...
>
>
>
>
>
RE: User/password encryption and deployment
Posted by Michael Segel <ms...@segel.com>.
> -----Original Message-----
> From: Bill Shannon [mailto:bill.shannon@sun.com]
> Sent: Saturday, June 16, 2007 12:04 AM
> To: Derby Discussion
> Subject: Re: User/password encryption and deployment
>
> derby@segel.com wrote:
> > Maybe I am missing something but what exactly are you encrypting?
> >
> > SSL is transmission from client to server over the net.
> >
> > Derby is Cloudscape till 2008 when IBM cuts loose.
> >
> > So are you trying to use an encryption data type?
> >
> > And how strong of an encryption do you want?
>
> I think the idea is to protect the communication between the client
> and the server so that passwords aren't sent in the clear. None of
> the data being stored in the database is being encrypted, just the
> client/server communication.
>
> It *is* 2007. Isn't this pretty much standard by now?
Uhm well, one would think.
Which is why I'm a little suspect that the *only* way to do encryption on
the wire is to be forced to bring in IBM's JCE.
I'll admit I haven't looked at this issue in depth, just trying to
understand the use case and see if its beyond encrypting the session ...
Re: User/password encryption and deployment
Posted by Bill Shannon <bi...@sun.com>.
derby@segel.com wrote:
> Maybe I am missing something but what exactly are you encrypting?
>
> SSL is transmission from client to server over the net.
>
> Derby is Cloudscape till 2008 when IBM cuts loose.
>
> So are you trying to use an encryption data type?
>
> And how strong of an encryption do you want?
I think the idea is to protect the communication between the client
and the server so that passwords aren't sent in the clear. None of
the data being stored in the database is being encrypted, just the
client/server communication.
It *is* 2007. Isn't this pretty much standard by now?
RE: User/password encryption and deployment
Posted by de...@segel.com.
Maybe I am missing something but what exactly are you encrypting?
SSL is transmission from client to server over the net.
Derby is Cloudscape till 2008 when IBM cuts loose.
So are you trying to use an encryption data type?
And how strong of an encryption do you want?
> -----Original Message-----
> From: david.vancouvering@gmail.com [mailto:david.vancouvering@gmail.com]
> On Behalf Of David Van Couvering
> Sent: Friday, June 15, 2007 7:24 PM
> To: Derby Discussion
> Subject: Re: User/password encryption and deployment
>
> Good questions, Bill. Yes, I would definitely want something that
> works with Sun JRE.
>
> I would think Derby over SSL is good enough. I don't know that
> STARTTLS is, and I don't know how you can configure Derby to work over
> SSL/TLS. Any pointers?
>
> Francois worked on this, maybe he can answer.
>
> Thanks,
>
> David
>
> On 6/15/07, Bill Shannon <bi...@sun.com> wrote:
> > David Van Couvering wrote:
> > > Let's say I want to deploy my application client with Java DB to 1000
> > > different client machines.
> > >
> > > If I understand things correctly, if you want to use encrypted
> > > user/password, you have to install the IBM JCE on each of these client
> > > machines and also go in and modify the java.security file in the
> > > lib/security directory of your JRE (see
> > > http://db.apache.org/derby/docs/10.2/adminguide/tadminapps811695.html)
> > >
> > > This doesn't seem reasonable/feasible for large deployments, or am I
> > > missing something?
> > >
> > > Also, the page doesn't tell you where to get the IBM JCE, except "IBM
> > > Developer Kit for the Java Platform 1.4 or later comes with IBM JCE".
> > > Hm.
> >
> > Wouldn't you want to support something that also works with Sun's JRE,
> > without modification of the JRE?
> >
> > Isn't username/password over SSL/TLS good enough?
> >
> > Does the derby network protocol support a "STARTTLS" equivalent command?
> >
> >
Re: User/password encryption and deployment
Posted by David Van Couvering <da...@vancouvering.com>.
Good questions, Bill. Yes, I would definitely want something that
works with Sun JRE.
I would think Derby over SSL is good enough. I don't know that
STARTTLS is, and I don't know how you can configure Derby to work over
SSL/TLS. Any pointers?
Francois worked on this, maybe he can answer.
Thanks,
David
On 6/15/07, Bill Shannon <bi...@sun.com> wrote:
> David Van Couvering wrote:
> > Let's say I want to deploy my application client with Java DB to 1000
> > different client machines.
> >
> > If I understand things correctly, if you want to use encrypted
> > user/password, you have to install the IBM JCE on each of these client
> > machines and also go in and modify the java.security file in the
> > lib/security directory of your JRE (see
> > http://db.apache.org/derby/docs/10.2/adminguide/tadminapps811695.html)
> >
> > This doesn't seem reasonable/feasible for large deployments, or am I
> > missing something?
> >
> > Also, the page doesn't tell you where to get the IBM JCE, except "IBM
> > Developer Kit for the Java Platform 1.4 or later comes with IBM JCE".
> > Hm.
>
> Wouldn't you want to support something that also works with Sun's JRE,
> without modification of the JRE?
>
> Isn't username/password over SSL/TLS good enough?
>
> Does the derby network protocol support a "STARTTLS" equivalent command?
>
>
Re: User/password encryption and deployment
Posted by Bill Shannon <bi...@sun.com>.
David Van Couvering wrote:
> Let's say I want to deploy my application client with Java DB to 1000
> different client machines.
>
> If I understand things correctly, if you want to use encrypted
> user/password, you have to install the IBM JCE on each of these client
> machines and also go in and modify the java.security file in the
> lib/security directory of your JRE (see
> http://db.apache.org/derby/docs/10.2/adminguide/tadminapps811695.html)
>
> This doesn't seem reasonable/feasible for large deployments, or am I
> missing something?
>
> Also, the page doesn't tell you where to get the IBM JCE, except "IBM
> Developer Kit for the Java Platform 1.4 or later comes with IBM JCE".
> Hm.
Wouldn't you want to support something that also works with Sun's JRE,
without modification of the JRE?
Isn't username/password over SSL/TLS good enough?
Does the derby network protocol support a "STARTTLS" equivalent command?