Hi Ian, some additional comments. Your patch uses jasypt 1.7.x, I tried with the latest version 1.8, works.
The xpath expression with quotes "//entry[@key='passwd']" works for me on oracle jdk 1.6 64 Bit and ibm jdk 1.6 64 Bit. I plan to support http digest authentication, but this is not possible with digested passwords since the server needs the plaintext password for its calculations. An alternative is to encrypt user passwords if digest authentication is required. As a consequence, I need the master key too. Cheers Christian Zitat von Ian Schneider <ischnei...@opengeo.org>: > Hi Christian, > >> 1) >> I would use this concept for the master key >> http://www.jasypt.org/webconfiguration.html >> The default should be the GeoserverExtensiosns.getProperty mechanism, >> but it would be nice to have the possibility to inject the master key >> using Spring. > > The web configuration could be an option, though I don't think people > will want that as the default as it requires a login to bootstrap the > server with the master password. I'm not sure of the advantage of > injecting the password via Spring over the other configuration > options. Can you elaborate? > >> 2) >> I would prefer a md5/aes 128 encryption as default and would avoid DES >> which is not state of the art and could be broken by brute force today >> (only 56 Bit key length). > > This is the default and is configurable. Pluggable providers (bouncy > castle for instance) should be supported, too. Again, the primary goal > is to keep plaintext passwords from lying around. If an intruder has > physical access to the datastore files, there will be trouble beyond > the threat of brute force password cracking. For example, why use the > sqlserver password when you can just log in using the integrated > security? Or add a jar to the classpath that loads a component into > the spring context and grabs all of the decoded passwords from the > catalog. My point is, a determined intruder will be able to get the > password or access the systems somehow (spear-phishing?) - the goal is > to provide reasonable security. I agree that a default non-random > password is not reasonable security (will fix this) - this was left > over from when the system was enabled by default. > >> 3) Perhaps, there should be a possibility to turn this feature off >> after turning it on, not sure here. > > The feature is opt-in so anyone enabling it should know what they are > doing. Recovery of the digested user passwords is not possible by > design. > >> Proposal: >> Ian, do you see a possibility to reduce your patch to the encrpytion >> (PBE) feature. At the moment we cannot apply both patches >> simultaneously and I want a situation where we can continue work >> independently. >> >> Opinions ? > > For the moment, perhaps they should coexist, disabled by default? > > Regards, > -Ian > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. ------------------------------------------------------------------------------ Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
