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?
Sorry, my fault here. I meant the PBEConfig interface here. Why not
have a default implementation. Code snippet
PBEConfig c = GeoserverExtensions.bean(PBEConfig.class);
if (c==null)
c= .... // use default impl with GeoserverExtensions.property(..)
Users can implement their own PBEConfig and inject it using spring.
This allows users to get their master password from wherever the want to.
>> 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.
Yep, I agree, there are many possibilities to attack. Perhaps I am
little bit paranoid since my "Applied IT Security" study, but I feel
uncomfortable using a weak 56 Bit DES instead an 128 Bit AES if I know
the danger in advance. At the end of the day, you should decide.
>
>> 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.
I was talking only about the encrypted store passwords. But again, I
will leave the decision up to you.
>
>> 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?
The overlapping area is password digesting. I stopped my work at the
first time I examined your patch. Your patch modifies GeoserverUserDao
which is gone after applying my patch. If we apply your patch, I have
to rework mine and have to rollback most of your work concerning
password digesting. Thats the reason why I proposed to make an
isolated patch for store passwords.
>
> Regards,
> -Ian
>
Anyways, we have to wait until Andrea has reviewed my patch.
Cheers
Christian
----------------------------------------------------------------
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
