On Mon, Aug 8, 2011 at 9:09 PM, 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.
Hmm... c'mon people, don't push, comment one at a time! Sigh, August, everybody is having his/her vacation I guess :-p > 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. What if a user password is edited, then saved, then open again, the save again. Is the password going to be preserved? Put another way, what do you store in the password fields in the GUI? Once it's digested you should not be re-digest the contents of the field unless it's changed. > 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. +1 > 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. No comment on this one, but I hope Christian will chime in as his code is affected. Afaik he wanted to use whatever Spring offers. > 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. The approach works for me > 3. Release schedule (fix for version) - up in the air. This is an important detail though. This work is probably warranting a GSIP, but if you want to commit on 2.1.x it most definitely needs one. > 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. Mumble mumble... can't make up my mind on this one. Let's move on :) > 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. I would see positively some sort of plugin allowing to provide the master password. With the default implementation of it just using a constant value. > 6. Alternative password store - the provider could even be a delegate > to external storage and retrieval of storeinfo passwords. Ah, storing just keys in the stores that would be used to lookup in the password store? Interesting indeed. Could be made a plugin again. Not sure how important this is though, I would be curious to hear from people playing with authorization more than me. > 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. Hoping that Christian will chime in soon :) > Missing functionality and other issues: > 1. Conversion tool - if the master password changes, the storeinfo > passwords will require re-encryption. This seems like a pretty big item. If I know the users they tend to consider security 5 minutes before going live, you decide to change the master password and boom, you have to reconfigure all users and stores. Ouch! > 2. Documentation on configuration options. This includes digest > options (and implications) and master password configuration. This is actually needed Cheers Andrea -- ------------------------------------------------------- Ing. Andrea Aime GeoSolutions S.A.S. Tech lead Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 962313 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.youtube.com/user/GeoSolutionsIT http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf ------------------------------------------------------- ------------------------------------------------------------------------------ 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
