I agree that any solution should be extendible to allow eventual users to select their own balance of speed vs security. I'm also happy to see the user guide section has been added, and is straight-forward enough to be understood.
-- Mark On 13 August 2011 12:47, Jody Garnett <jody.garn...@gmail.com> wrote: > Perfectly understood; my real comment was that I would ask Mark to join the > conversation (and that there may be room for collaboration). > -- > Jody Garnett > > On Saturday, 13 August 2011 at 8:53 AM, Ian Schneider wrote: > > Hi Jody, > > Whatever mechanism is finally in place should allow for extension. > That is, if the default digest algorithm or provider is not > sufficient, it should be replaceable. > > BCrypt is just an algorithm and there is no implementation (provider) > in the SDK. BCrypt also incurs significant overhead with the benefit > of more secure passwords. The current situation is no security, so I'd > like to get this moving ASAP. > > Thanks, > -Ian > > On Tue, Aug 9, 2011 at 8:43 PM, Jody Garnett <jody.garn...@gmail.com> wrote: > > Hi Ian; we have hit this issue internally as well. Mark was directing us > towards the use of bcrypt. I will let him know about this email thread and > ask him to share his thoughts here. > Jody > > On Tue, Aug 9, 2011 at 5:09 AM, Ian Schneider <ischnei...@opengeo.org> > wrote: > > 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 > > > > -- > Ian Schneider > OpenGeo - http://opengeo.org > Enterprise support for open source geospatial. > > > ------------------------------------------------------------------------------ > FREE DOWNLOAD - uberSVN with Social Coding for Subversion. > Subversion made easy with a complete admin console. Easy > to use, easy to manage, easy to install, easy to extend. > Get a Free download of the new open ALM Subversion platform now. > http://p.sf.net/sfu/wandisco-dev2dev > _______________________________________________ > Geoserver-devel mailing list > Geoserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > > -- Mark Leslie Geospatial Software Architect LISAsoft ------------------------------------------------------------- Ph: +61 2 8570 5000 Fax: +61 2 8570 5099 Mob: +61 Suite 112, Jones Bay Wharf 19-21 Pirrama Rd Pyrmont NSW 2009 ------------------------------------------------------------- LISAsoft is part of the A2end Group of Companies http://www.ardec.com.au http://www.lisasoft.com http://www.terrapages.com ------------------------------------------------------------------------------ uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
