| Summary: | Security issue: Secure Storage view shows passwords without asking for master | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Markus Keller <markus.kell.r> | ||||
| Component: | Security | Assignee: | Security Inbox <equinox.security-inbox> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | major | ||||||
| Priority: | P3 | CC: | daniel_megert, martinae, ob1.eclipse | ||||
| Version: | 3.4 | ||||||
| Target Milestone: | 3.4 M7 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Markus Keller
By design, secure storage tries to get away from a user-enterable password. In general, there might be or might be not a "master" password that user is aware of. So, we can not ask to re-enter "master" password and the choice becomes to show or not to show. Which is a question of finding balance of convenience vs. security. There is also bug the 227428 which might result in the subtantial changes to the view. >. Which is a question of finding balance of convenience vs.
>security.
Well, it's called *secure* store and not just store, right? ;-)
This bug needs to be fixed in a way you outlined yourself: either ask for the password again or don't allow to show the passwords.
See 227428 : I think I'll add a Debug-like preferences to the org.eclipse.equinox.security bundle and will create context menus (both modify actions and "show value" action) only if that property is set. By the way, the "Decrypt" command on the same menu has essentially the same effect. I can make those commands to show up only if specific debug option is set. But then by extension of the same logic a passer by can create a new debug launch configuration and enable those options and launch self-hosting session from the running session and get those actions back :-). Any opinions? > By design, secure storage tries to get away from a user-enterable password. That's very well appreciated for logins, but not for decrypting stored passwords. > In general, there might be or might be not a "master" password that user is > aware of. But there must be a master password somewhere. If it's the user's login password, then you should use the OS's password dialog to ask the user. If the secure store can really be used without any password, then we need a big scary warning message whenever a password is saved into such an insecure store. As you said in comment 4, the debug preference is also not a secure solution. It should just not be possible for a user to see decrypted passwords unless he entered the master password immediately before. And if there's no master password, the stored passwords should not be made available. Created attachment 96908 [details] Patch OK, convinced :-). For 3.4 this patch removes Show Value, Encrypt, and Decrypt commands. The Add/Remove commands are now only availabe if debug options are set (bug 227428). Long-term I'd like to see if we can find a way to put those commands back. The story I'd like to see hapenning is the secure storage being locked by a file present on a USB key or a smart card. To a degree USB key can be used today, but it is not yet the base path. Patch applied to CVS Head. Thanks for bringing this up. |