This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
There should be a common API in the Platform for securely persisting passwords and similar login credentials. Native keyrings should be used where possible for the best user experience: Gnome Keyring, KDE KWallet, Mac OS X Keychain, TBD on Windows (ideally whatever gets opened by fingerprint readers). If a native keyring is not available, passwords can be kept in a -rw------- file in the userdir encrypted by a master password, similar to Firefox or Thunderbird.
Various existing IDE features save passwords in the userdir in insecure ways, such as: glassfish.properties#sjsas.password config/Preferences/org/netbeans/modules/kenai/ui.properties#kenai.password config/Databases/Connections/jdbc_derby___*.xml#/connection/password/@value config/Preferences/org/netbeans/modules/uihandler.properties#Passwd Others avoid saving passwords even when it would be helpful, such as Hudson servers. Experimenting in patch branch: http://hg.netbeans.org/prototypes/rev/keyring-173413
The equivalent feature in Eclipse 3.4: http://update.eclipse.org/downloads/drops/R-3.4-200806172000/whatsnew3.4/eclipse-news-part3.html#equinox.security.storage Gnome support already implemented. Mac OS X support should be possible using http://developer.apple.com/mac/library/documentation/Security/Reference/keychainservices/Reference/reference.html The closest Windows equivalent to a keyring according to http://stackoverflow.com/questions/442923/windows-equivalent-of-os-x-keychain looks to be Pstore, but this is read-only as of Vista and deprecated. Seems as of W2k you are supposed to use CryptProtectData http://msdn.microsoft.com/en-us/library/aa380252(VS.85).aspx#data_encryption_and_decryption_functions and presumably store the result in an app-specific area such as NbPreferences.
Win32 support now implemented. Platform-independent fallback support in progress. In use by the Hudson integration so far.
Master password platform-independent fallback impl basically working, though it likely needs UI tuning. Mac Keychain support implemented.
Consider org.eclipse.core.runtime.compatibility.auth interoperability.
Please review this new API. Only seven simple methods in the API. No apichanges entries yet. Things that are implemented: 1. Storage of passwords in the Gnome keyring, for Gnome users (tested on Ubuntu). 2. Storage of passwords in the Mac OS X keychain, for Mac users. 3. Encryption of passwords using a login key, for Windows users. 4. Storage of passwords in the user directory protected by a configurable master password, for anyone who cannot use 1-3 (e.g. KDE users if no one writes a KWallet integration). 5. Use of keyring for Hudson server logins. 6. Use of keyring for NetBeans proxy settings. 7. Use of keyring for NetBeans internal HTTP authenticator (if anything is using this). 8. Use of keyring for exception reporter login. 9. Use of keyring for Kenai login.
Created attachment 92152 [details] Current patch
core-main #a6e54ff61f93
Integrated into 'main-golden', will be available in build *200912120559* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/a6e54ff61f93 User: Jesse Glick <jglick@netbeans.org> Log: Issue #173413: create common API for managing user passwords in a secure keyring.
Security question: 1) Keyring.read(key) is available for everyone 2a) master pwd dialog is displayed before a client's dialog is displayed => user doesn't know the reason who needs access to password or 2b) after opening keyring it is then opened for full IDE session => If I know keys used by important clients => someon can easily write in his plug-in the code to steal all passwords right?
Yes, of course. All NB modules are granted full permissions on the system; there is no applet-like security container. Regardless of any keyring API, module code can read your email, steal passwords from elsewhere in the JVM or other processes you ran, and so on. If you don't trust a module, don't run it. The goal of this API is to permit modules to persist passwords to disk more securely than the previous option, which was to store them in cleartext or using only obfuscation. (BTW for any problems you find, please open separate bugs blocking this one - do not reopen.)
ok. thanks
Created attachment 93743 [details] Kwallet support through qdbus I created KWallet support - it works by calling qdbus command which is installed by default with any kde (on linux - I don't know about solaris - but propably dbus is not there) and most propably is not widely available otherwise.
Jesse, what do you think about Adam's patch from February 1st?
(In reply to comment #14) > what do you think about Adam's patch from February 1st? Long since integrated; see bug #179839.
OK, thanks Jesse.