[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] Re: Client side security store (Peter Kriens)
- From: Peter Kriens <Peter.Kriens@xxxxxxxx>
- Date: Wed, 28 Sep 2005 08:58:57 +0200
- Delivered-to: firstname.lastname@example.org
- Organization: aQute
I am not that worried about the strength of the security :-) Usually
systems are compromised with user engineering. So my objection to the
Keystore API was not on implementation weakness. I do not like the
API and architecture. It was cumbersome to do simple things ...
jnic> First, I'm glad to see some great discussions staring up
jnic> around security and Eclipse in general. As Jeff pointed out,
jnic> much of the info that was started on the Equinox home has become
jnic> a little out of date.
jnic> Java has long contained APIs/SPIs for a "KeyStore" which
jnic> can contain X509 certificates as well. As Jeff and BJ point
jnic> out, some of the default implementations are pretty week and can
jnic> be compromised fairly easily. The IBM implementations in IBM
jnic> JRE's are "more" secure, in that they use real encryption. The
jnic> core Keystore APIs/SPIs are very flexible for providing your own
jnic> pluggable implementations and providers.
jnic> In addition Java 1.4. introduced the CertStore APIs/SPIs
jnic> which also provide a more robust mechanism for searching and
jnic> managing groups of "untrusted certificates and CRLs". (see
jnic> I have more experience with the Keystore APIs/SPIs than the
jnic> Certstore, so I won't say anymore about it, until I do.
jnic> I believe these APIs/SPIs can be built on to make Eclipse
jnic> a more secure application platform. I even like the idea of
jnic> possibly having the "default" Eclipse providers, be just
jnic> wrappers on top of the OS's store.
jnic> One of the biggest weaknesses of those APIs is the lack
jnic> of what is probably the most desired piece, a "secure"
jnic> repository for saving username/password combinations for
jnic> accessing remote services and sites. These aren't technically
jnic> "keys" or certificates, but they do act as a user's credentials
jnic> when accessing some remote services.
jnic> Lots of food for thought....
jnic> Jay R.
jnic> IBM Corp. , IBM Software Group
jnic> Workplace, Portal and Collaboration Software
jnic> Workplace Managed Client, Security
jnic> jsr@xxxxxxxxxx"Experience is something you don't get
jnic> until just after you need it." -- Anon
Peter Kriens Mob +33633746480
9C, Avenue St. Drézéry Tel +33467542167
34160 Beaulieu, France Tel +15123514821
AOL,Yahoo, Skype pkriens ICQ 255570717