Hi everyone, Geoserver currently stores user and datastore connection passwords in plaintext. This is obviously a security issue.
I have opened http://jira.codehaus.org/browse/GEOS-4702 to address this. As Andrea noted, this needs to be discussed and digested (hehe, sorry) a bit. A quick overview of the goals of this issue/patch: 1) Enable password digesting for users.properties. Digesting is one-way encryption and does not support recovery. This needs to integrate with the existing spring security and should not effect any external use. Existing users' passwords will be digested automagically and new passwords handled without any changes to user interface. 2) Enable two-way encryption of datastore passwords (the passwords often need to be provided in plaintext to the external service/system). The upgrade should occur automagically without any changes to the credential users. A default, low-level security option should be provided with configurable options as well as a path to a custom provider replacement. 3) Support (or at least have a path to) 1 and 2 for whatever new subsystems come along that require this service. Here is a list of discussion items: 1. The current patch adds a new dependency - jasypt (http://www.jasypt.org/). Weighing in at a 169K, this library wraps the core security libraries and provides spring integration (and more). Christian's work (see 7 below) may also be using this. It may be possible that the 'lite' version of this library could suffice. Alternatively, the wrapper functionality and spring integration could be replaced. I am partial to reuse myself. 2. Upgrade path - Currently, the patch will upgrade automagically and attempt to every time. This is not a big hit for a small number of users/storeinfos, but could be for larger numbers (e.g. lots of shapefiles/tiffs). This is because all storeinfos need to be scanned to detect passwords and the code for this is somewhat inefficient. This relates to http://jira.codehaus.org/browse/GEOS-4701. An alternative could be to refactor the upgrade code somehow to be more efficient. 3. Release schedule (fix for version) - up in the air. 4. Default master password - currently, the default master password is in code. An (better) alternative would be to add it to the global configuration and generate a random one. This could potentially be a replacement for GEOS-4701 (presence of property, blank or otherwise, in config marks the upgrade) though I still think that the latter is warranted. 5. Other master password options - the master password has to come from somewhere. The earlier issue and patch (http://jira.codehaus.org/browse/GEOS-1793) used a file based keystore with optional password. The password, if present, would have to be provided (of course). The 'advanced' (marginally more secure than default password) option that is provided with the new patch is to allow provisioning by servlet context param (more hidden than being in global), system property, or environment variable (same). Jasypt also supports a boot-strapping feature (http://www.jasypt.org/webconfiguration.html) that would require more work. A security minded user could also create a custom provider (get the password from some other location or deliberately obfuscated code) that would not use the above approaches. No solution will be completely fool proof due to the problem space, but the current state of plaintext passwords is bad - separating the master password from the encrypted passwords is a major step up. 6. Alternative password store - the provider could even be a delegate to external storage and retrieval of storeinfo passwords. 7. Other work - http://jira.codehaus.org/browse/GEOS-4554. Christian's scope of work does not currently appear to address the storeinfo issue. My intention when I started this work was to not diminish, replace, or duplicate his efforts and I see them as fully compatible in intention if not implementation. Missing functionality and other issues: 1. Conversion tool - if the master password changes, the storeinfo passwords will require re-encryption. 2. Documentation on configuration options. This includes digest options (and implications) and master password configuration. 3. API/SPI improvement and doc Any and all discussion welcome. Thanks, -- Ian Schneider OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
