Password connection parameters are stored in plain text.

Ah, thanks a lot for the patch. A few comments:

• all the users passwords in 1.6.x are stored in security/users.properties, and they are in plain text. Given that there is no UI to edit the users.properties, it is not possible to encrypt them. So you can hide the connection params, but you cannot hide the geoserver users ones. Is that acceptable to you?
• not all password parameters are called "password", in all JDBC datastores it's "passwd", not sure if there are any other variations (the connection param names are part of the GeoTools API, each datastore is free to call connection params what they want). Anyways, I guess this is something I can handle
• this contribution adds a new file, not sure I can accept it unless you sign the contribution agreement or you release the patch in the public domain (from which I can take it and relicense it to GPL + copyright assignment to TOPP). I'm going to CC the project leader, Chris, to hear what are the legal issues in this matter.

Finally, I really suggest you upgrade from 1.6.0-rc3 to 1.6.2, see: http://blog.geoserver.org/2008/03/07/geoserver-162-upgrade-security-release/

Chris, you opinion on the legal issues of a patch of this size is needed. Can we accept it as is?

I'd prefer a contributor agreement. But we can accept this as is. It's not super core, like it's easy to rip out out. The main thing is that any one making really core changes that aren't easily revertable in a single commit need contributor agreements, so if it came to anything it would be easy to remove.

Great information Andrea, we will definitely want to go with 1.6.2!
*I pushed up to my management the need for us to "sign the contribution agreement," as I do except that we will need to make future changes.
*I can make the simple change to look also for the "passwd" key used by JDBC when doing the encrypt in the XMLConfigWriter and then attach a new patch file to this issue if you'd like.
*The goeserver users passwords in security/users.properties, those will also need to be encrypted... a new issue/patch for that perhaps?

About the list of names to be encrypted, yeah, you can add passwd as well to this patch (or I can do it when merging the patch).
About the users.properties, yes, a separate issue is probably good. If you need to share part of the patch, make that issue depend on this one.

wonder if instead of guessing on parameter name we should have a specific DataAccessFactory.Param subclass to denote its a password, say DataAccessFactory.Password extends DataAccessFactory.Param

Gabriel, yes, that would look like a good idea.
Michael, what's the status of your work?

We already have the necessary infrastructure in geotools to void heuristically figuring out password parameters. Yet I'm moving the fix version to 1.7.1 since I won't have time to get this in for 1.6.5 and the geotools improvement is on 2.5.x anyway

This one has been rescheduled a number of times... pity cause there was a patch attached to it.
Maybe something we should consider for 2.0.x? We are breaking backwards compatibility with the storage format anyways, seems like we could make a custom XStream persister that knows to encrypt passwords if we give it enough metadata to recognize one?

Just a minor note about the patch, is uses sun.misc.BASE64Decoder and sun.misc.BASE64Encoder, we should use an external replacement for those (commons codecs does have one for example)

Right. Also, my concern is about the need to run java with the location of the keyfile as argument. Surely some people won't be able to do that (websphere, etc)
It seems to me like a contribution to the UI to indicate that will be needed?

catalog.xml is gone but users.properties has the same problem