HI Oleg,
thanks a lot again. It all looks great :-)
For the Password Recovery Dialog that the user is expected
to fill in, I'd propose adding a hint telling the user when and
where he can actually run the password recovery
("Note you can run password recovery from the Secure Storage
Preference Page").
And/Or add an F1 HelpContext to the dialog.
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Oleg Besedin
Sent: Donnerstag, 03. April 2008 18:00
To: Equinox development mailing list
Subject: RE: [equinox-dev] Secure Storage Javadoc Gotchas
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 <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
