[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Secure Storage Javadoc Gotchas


Hi Martin,
I opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=225386 for Javadocs.

Those are all good questions and will be included in the Help somewhere, probably as a separate article. At this point the area is under active development so the answers below should be taken as internal implementation details.

> How Secure is the default Secure Storage provided actually? It says "Java Encryption is used" ... what encryption does it use?

By default it asks JVM for a "PBEWithMD5AndDES" encryption which, according to Java documentation, is a 56-bit DES algorithm. User can change it from the preference page:




The behind-the-scene processing polls all providers included in the JVM to find compatible algorithms. This list is going to be different for different VMs and could include user-supplied providers.

("Gotcha": The modified value applies to new storages, not to the ones already created. At least in this release.)

As to the strength/weakness - *** I am not any kind of an expert on this, so take what I say as an opinion, rather than a fact. ***
 
The 56-bit DES algorithm is considered to be a "weak" encryption and presumably could be brute-force broken in a matter of days. There are stronger algorithms. However, from a practical side, password will usually be the weakest link: the dictionary-based approach has been rumored to break over 80% of passwords within 12 - 24 hours. (Numbers of course depends on hardware and are coming from Internet so should be taken with caution.)

This assumes that attacker can copy the file, take it home, and be willing to customize his tools to the format used by secure storage.

In my personal opinion, the 56-bit DES with a good password provides plenty of security for a casual user for non-financial information. If that is not sufficient, preferences can be used to switch to Triple DES or to a cryptographic service specific to user's installation.

 
> Where does the Password come from by default? What happens when a new password is generated, how and when is the user asked about the password?

I'll start from a simple picture and then add few details to make it more complete.

On Windows password is generated as a random lengthy string (300 characters or so) when secure storage is used for the first time. Then secure storage uses Windows APIs to encrypt it in a user-specific way. The Windows-encrypted password is stored in the secure storage itself. Only the person logged in the same Windows account could decrypt it.  On a subsequent runs, secure storage tries to decrypt the Windows-encrypted password and use the result to decrypt stored values.

If Windows module is used, the only prompt users ever sees is for the password recovery questions / answers (one time event).

On all other operating systems secure storage is going to prompt the user to enter the password when it is accessed for the first time in the current process.

That's the simple picture. What really happens is that there is a collection of password providers that are asked for a password. Two password providers are currently available: Windows-specific (which used Windows DPAPI which, I believe, normally uses Triple DES and works off the user's account information) and the "default" password provider that just prompts the user and uses MD5 digest as a password. Windows module has higher priority so it is used when available. We'd like to add password provider modules with integration for Mac (system keyring) and Linux (Gnome keyring?). Password provider modules with intergation to specific OSes is certainly a "help wanted" area.

The password provider modules should be the normal path. In addition, password can be specified when secure preference storage is opened via IProviderHints or via runtime option (name of which is being discussed, either "-password", or "-eclipse.password").


> How secure is the storage against malicious plugins running inside the same OSGi session? I'd suppose they can easily retrieve any information once the session has been opened by (somebody)?

You are correct, secure storage is open to all bundles. If a bundle is installed into your OSGi session, if can get anything and everything. And, by the way, If Windows integration is used, a person who can log into your Windows account can obtain all encrypted information.

The solution? With the current install process user has an option to say which bundles are trusted based on signing certificates. The non-trusted bundles are disabled.

(For context, we discussed a number of more advanced approaches that would accept that there are shades of grey between "trusted" and "non-trusted" bundles. The short summary: it is a lot of work :-). This is something I'd like to be able to spend more time on.)


> Are you aware of any other adopters, e.g. Platform Team/CVS such that we could share experiences? Would you mind helping us getting started?

Hopefully, CVS integration and Proxies (core.net) will switch to the secure storage in 3.4. I'll be very happy to help.


+ [question added by Oleg] Where secure storage is located? How is it shared between users and Eclipse instances?

By default, secure storage is located in the user's home directory. As such, the data in it could be shared between different running instances, but will stay isolated from user to user.

"Gotcha": the data stored gets overwritten after secure storage was modified; default save time is during Eclipse shutdown. As a result, modifications could be persisted only from one session at a time. (That's the picture for this release, might be improved in future.)

=====================================

Hope this helps. If you'd like, feel free to join Equinox security conference calls (http://www.eclipse.org/equinox/incubator/security/status.php).

Thanks,
Oleg




"Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

04/02/2008 09:48 AM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To
"Equinox development mailing list" <equinox-dev@xxxxxxxxxxx>
cc
Subject
[equinox-dev] Secure Storage Javadoc Gotchas





Hi Folks,
 
I'm impressed by the new Secure Storage features as per
http://download.eclipse.org/eclipse/downloads/drops/S-3.4M6-200803301350/eclipse-news-M6.html#equinox.security.storage
 
Trying to investigate these a little closer, I came across a few
gotchas that I wanted to mention but was just too lazy filing
individual bugzilla's for them - so here you go:
 
org.eclipse.equinox.security.secureStorage extension point docs
- missing @since information, missing link to PasswordProvider class
 
PasswordProvider Javadocs
- missing hyperlink to secureStorage extension point
- missing link to ISecurePreferences
 
ISecurePreferences Javadocs
- missing hyperlink to PasswordProvider
 
How Secure is the default Secure Storage provided actually?
It says "Java Encryption is used" ... what encryption does it
use? Where does the Password come from by default? What
happens when a new password is generated, how and when is
the user asked about the password? How secure is the storage
against malicious plugins running inside the same OSGi session?
I'd suppose they can easily retrieve any information once the
session has been opened by (somebody)?
 
FYI, we're considering migrating the RSE Remote Password
Support to secure preferences from our current keyring usage.
We've filed this bug for it:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=225320
 
Are you aware of any other adopters, e.g. Platform Team/CVS
such that we could share experiences? Would you mind helping
us getting started? - On our side, integration should be fairly
easy since only one impl class should be affected
(PasswordPersistenceManager). What we're not yet sure
about is whether we should migrate old passwords from Eclipse
Keyring to the new Secure Storage.
 
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 


From: equinox-dev-bounces@xxxxxxxxxxx [mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of Hampel, Michael
Sent:
Mittwoch, 02. April 2008 14:50
To:
equinox-dev@xxxxxxxxxxx
Subject:
[equinox-dev] p2 metadata generation


Hello,
 
can someone please tell me if it is possible to generate the needed p2 metadata for "pure" bundles(no eclipse plugins) in a local
directory and how I would do this?
 
thanx in advance for any help,
 
Michael_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev