Re: [equinox-dev] Secure Storage Javadoc Gotchas

[Oleg Besedin <obesedin@xxxxxxxxxx>]

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