Hi Martin,
Thank you, my pleasure.
> Runtime option for password: IMHO this is a no-no because simple ps -ef
on Linux will show the commandline that was used for launching Eclipse,
including the plaintext passwrd. It's one of the things I've always
disliked about the old Eclipse Keyring.
The way I imagine this is going to work is that "-[eclipse.]password" will
not normally be used. The normal everyday functionality is covered by
password providers; the option is only to be used in situation where
encryption of the data is not really important. It mostly be used by
scripts, tests, and such, not for normal everyday processing.
> Password recovery questions: When would those ever be used? Aren't these
vulnerable to Brute Force Dictionary attacks?
The preferences page has a "Recover password" button. If user forgets the
password (or if Windows module malfunctions, say due to the standalone
computer being re-installed without password recovery disk) then this
option could be used to recover password. It works slightly differently
from a conventional password recovery - the memory cache is populated but
user is not given the password directly, rather encouraged to change it.
To make it work we have two strings ("answers") provided by the user. We
mush them up: "my street" and "1917" becomes "m7y1 9s1treet" and then a
crypto digest of the combo is created. This process increases password
strength even if original strings are dictionary words. The password is
encrypted with this mush up and stored in the secure storage. (Of course,
if answers are "a" and "1", no amount of processing is going to improve
password quality much :-).)
Creation of password recovery is optional. It has both pluses and minuses:
"+" it adds quite a bit of convenience;
"-" as you say, it somewhat increases vulnerability of encrypted
information to dictionary-based attacks
I think for a casual user "+" will outweigh the "-", but the important
part is that it is all optional.
> Password Provider Priorities: shouldn't the user be able to move up /
move down / enable / disable password providers by Preference rather than
just showing the fixed priorities?
Good point. I'll see if we can add this option in M7 (time permitting).
There is a way to programmatically specify preferred password provider via
IProviderHints, but this might be useful too.
Thanks,
Oleg
"Oberhuber, Martin" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
04/02/2008 05:49 PM
Please respond to
Equinox development mailing list <[email protected]>
To
"Equinox development mailing list" <[email protected]>
cc
Subject
RE: [equinox-dev] Secure Storage Javadoc Gotchas
Hi Oleg,
thanks for all this information. Couple of comments and further questions:
Runtime option for password: IMHO this is a no-no because simple ps -ef on
Linux will show the commandline that was used for launching Eclipse,
including the plaintext passwrd. It's one of the things I've always
disliked about the old Eclipse Keyring.
Runtime option for keyring location: I've always liked this one because it
allowed me to place my old Eclipse keyring into an NTFS encrypted folder
for added security, with rw access only for my user id - an option that
helps reducing the risk of "I copy your keyring and apply brute force
attacks to it" kinds of approaches.
Password recovery questions: When would those ever be used? Arent't these
vulnerable to Brute Force Dictionary attacks?
Trusted bundles: sounds interesting.
Password Provider Priorities: shouldn't the user be able to move up / move
down / enable / disable password providers by Preference rather than just
showing the fixed priorities?
[question added by oleg]: that's a bit of information which I actually
found in the docs ;-)
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
_______________________________________________
equinox-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev
