You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Daniel Fernández Garrido <df...@users.sourceforge.net> on 2007/11/22 12:03:14 UTC
Jasypt + ICrypt + ICryptFactory
Hello everyone,
I am about to release a new version (1.4) of Jasypt [http://www.jasypt.org],
and I am considering the addition of some wicket integration features for
improving wicket's encryption capabilities.
But I would first need to ask a couple of things :-)...
First, what I will do (have already done, in fact): I have added to jasypt
both an implentation of the org.apache.wicket.util.crypt.ICrypt and
org.apache.wicket.util.crypt.ICryptFactory interfaces. The idea is to use
JasyptFactory as the desired ICryptFactory implementation for the
application, like this:
------(CODE WHICH WOULD GO INTO OUR "WebApplication" CLASS)------
@Override
protected void init() {
super.init();
/*
* In the following code example we will create a Jasypt byte
* encryptor by hand, but in real world we can get it from Spring,
* configure it via Web PBE configuration... whatever we want to.
*/
StandardPBEByteEncryptor encryptor = new StandardPBEByteEncryptor();
encryptor.setAlgorithm("PBEWithMD5AndDES");
encryptor.setPassword("jasypt");
/*
* Create the Jasypt Crypt Factory with the desired encryptor,
* which will return org.jasypt.wicket.JasyptCrypt objects
implementing
* the org.apache.wicket.util.crypt.ICrypt interface.
*/
ICryptFactory jasyptCryptFactory = new JasyptCryptFactory(encryptor);
/*
* Set the Jasypt Crypt Factory into the application configuration.
*/
getSecuritySettings().setCryptFactory(jasyptCryptFactory);
}
------------
But the question here is... what is the real use of the ICryptFactory today
(1.3.0-rc1) in wicket? Is it "only" encrypting URLs? (I see
PasswordTextFields are not encrypted anymore)
And if so, would it be of real use/need? Of course, It would increase much
(as much as Java can) the security of the URLs' encryption but, would you
see any other uses?
If this is only used for encrypting URLs, and if I am not wrong, our
"WebApplication" class would also need something like this:
------(CODE WHICH WOULD GO INTO OUR "WebApplication" CLASS)------
@Override
protected IRequestCycleProcessor newRequestCycleProcessor() {
return new WebRequestCycleProcessor() {
@Override
protected IRequestCodingStrategy newRequestCodingStrategy() {
return new CryptedUrlWebRequestCodingStrategy(new
WebRequestCodingStrategy());
}
};
}
------------
Would this be correct/adequate?
And more important: can I consider wicket's ICrypt and ICryptFactory
interfaces *stable*? (at least until a stable 1.3.0 release). Have you got
any short-term plans for changing anything in this encryption
infrastructure?
And the last thing: the "setKey()" method in ICrypt is not usable in Jasypt,
as encryptor configuration and initialization is quite more complex and PBE
keys (encryption passwords) cannot be changed once an encryptor has already
been initialized (password is set on the jasypt encryptor, not the
wicket-friendly JasyptCrypt).
So, JasyptCrypt will always throw an exception if this method is called.
Currently in wicket, "setKey" is only called from
org.apache.wicket.util.crypt.ClassCryptFactory, which jasypt does not
extend, so this would not pose any problems for the future, but... could it
make sense that that "setKey" method were called by the developer anywhere
else? this would render jasypt integration quite complicated...
Sorry for the size of the message and the lot of questions :-)
Regards,
Daniel.
Re: Jasypt + ICrypt + ICryptFactory
Posted by Johan Compagner <jc...@gmail.com>.
Dont know for sure but didn't we also encrypt cookies (form data)
2007/11/22, Daniel Fernández Garrido <df...@users.sourceforge.net>:
> Hello everyone,
>
> I am about to release a new version (1.4) of Jasypt [http://www.jasypt.org],
> and I am considering the addition of some wicket integration features for
> improving wicket's encryption capabilities.
>
> But I would first need to ask a couple of things :-)...
>
>
> First, what I will do (have already done, in fact): I have added to jasypt
> both an implentation of the org.apache.wicket.util.crypt.ICrypt and
> org.apache.wicket.util.crypt.ICryptFactory interfaces. The idea is to use
> JasyptFactory as the desired ICryptFactory implementation for the
> application, like this:
>
>
> ------(CODE WHICH WOULD GO INTO OUR "WebApplication" CLASS)------
>
> @Override
> protected void init() {
>
> super.init();
>
> /*
> * In the following code example we will create a Jasypt byte
> * encryptor by hand, but in real world we can get it from Spring,
> * configure it via Web PBE configuration... whatever we want to.
> */
> StandardPBEByteEncryptor encryptor = new StandardPBEByteEncryptor();
> encryptor.setAlgorithm("PBEWithMD5AndDES");
> encryptor.setPassword("jasypt");
>
> /*
> * Create the Jasypt Crypt Factory with the desired encryptor,
> * which will return org.jasypt.wicket.JasyptCrypt objects
> implementing
> * the org.apache.wicket.util.crypt.ICrypt interface.
> */
> ICryptFactory jasyptCryptFactory = new JasyptCryptFactory(encryptor);
>
> /*
> * Set the Jasypt Crypt Factory into the application configuration.
> */
> getSecuritySettings().setCryptFactory(jasyptCryptFactory);
>
> }
>
> ------------
>
>
> But the question here is... what is the real use of the ICryptFactory today
> (1.3.0-rc1) in wicket? Is it "only" encrypting URLs? (I see
> PasswordTextFields are not encrypted anymore)
>
> And if so, would it be of real use/need? Of course, It would increase much
> (as much as Java can) the security of the URLs' encryption but, would you
> see any other uses?
>
>
> If this is only used for encrypting URLs, and if I am not wrong, our
> "WebApplication" class would also need something like this:
>
>
> ------(CODE WHICH WOULD GO INTO OUR "WebApplication" CLASS)------
>
> @Override
> protected IRequestCycleProcessor newRequestCycleProcessor() {
>
> return new WebRequestCycleProcessor() {
> @Override
> protected IRequestCodingStrategy newRequestCodingStrategy() {
> return new CryptedUrlWebRequestCodingStrategy(new
> WebRequestCodingStrategy());
> }
> };
>
> }
>
> ------------
>
> Would this be correct/adequate?
>
>
> And more important: can I consider wicket's ICrypt and ICryptFactory
> interfaces *stable*? (at least until a stable 1.3.0 release). Have you got
> any short-term plans for changing anything in this encryption
> infrastructure?
>
>
> And the last thing: the "setKey()" method in ICrypt is not usable in Jasypt,
> as encryptor configuration and initialization is quite more complex and PBE
> keys (encryption passwords) cannot be changed once an encryptor has already
> been initialized (password is set on the jasypt encryptor, not the
> wicket-friendly JasyptCrypt).
>
> So, JasyptCrypt will always throw an exception if this method is called.
> Currently in wicket, "setKey" is only called from
> org.apache.wicket.util.crypt.ClassCryptFactory, which jasypt does not
> extend, so this would not pose any problems for the future, but... could it
> make sense that that "setKey" method were called by the developer anywhere
> else? this would render jasypt integration quite complicated...
>
>
> Sorry for the size of the message and the lot of questions :-)
>
>
> Regards,
> Daniel.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Jasypt + ICrypt + ICryptFactory
Posted by Daniel Fernández Garrido <df...@users.sourceforge.net>.
Thank you for your answers. As you can see, I have already done the release.
Let's hope this is useful for someone :-)
Regards,
Daniel.
Eelco Hillenius wrote:
>> But the question here is... what is the real use of the ICryptFactory today
>> (1.3.0-rc1) in wicket? Is it "only" encrypting URLs? (I see
>> PasswordTextFields are not encrypted anymore)
>>
>
> Yep, I think we removed the other uses. I don't know exactly from the
> top of my head, but it is in the (recent) mail archives.
>
>
>> And if so, would it be of real use/need? Of course, It would increase much
>> (as much as Java can) the security of the URLs' encryption but, would you
>> see any other uses?
>>
>
> I can't really think of anything else besides that it is available as
> a nice utility class.
>
>
>> If this is only used for encrypting URLs, and if I am not wrong, our
>> "WebApplication" class would also need something like this:
>>
>>
>> ------(CODE WHICH WOULD GO INTO OUR "WebApplication" CLASS)------
>>
>> @Override
>> protected IRequestCycleProcessor newRequestCycleProcessor() {
>>
>> return new WebRequestCycleProcessor() {
>> @Override
>> protected IRequestCodingStrategy newRequestCodingStrategy() {
>> return new CryptedUrlWebRequestCodingStrategy(new
>> WebRequestCodingStrategy());
>> }
>> };
>>
>> }
>>
>
> Something like that yeah :-)
>
>
>
>> And more important: can I consider wicket's ICrypt and ICryptFactory
>> interfaces *stable*? (at least until a stable 1.3.0 release). Have you got
>> any short-term plans for changing anything in this encryption
>> infrastructure?
>>
>
> That's definitively a stable interface. I don't see us changing that
> any time soon. Btw, now that we are in RC mode, we won't be changing
> any of the API unless there are very pressing matters, in which case
> we'll have a vote about it. The idea is to enable users to just drop
> in new versions/ jars in RC/ finals without having to fix for API
> changes.
>
>
>> So, JasyptCrypt will always throw an exception if this method is called.
>> Currently in wicket, "setKey" is only called from
>> org.apache.wicket.util.crypt.ClassCryptFactory, which jasypt does not
>> extend, so this would not pose any problems for the future, but... could it
>> make sense that that "setKey" method were called by the developer anywhere
>> else? this would render jasypt integration quite complicated...
>>
>
> I guess we'll hear if that is a problem for someone :-)
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Jasypt + ICrypt + ICryptFactory
Posted by Eelco Hillenius <ee...@gmail.com>.
> But the question here is... what is the real use of the ICryptFactory today
> (1.3.0-rc1) in wicket? Is it "only" encrypting URLs? (I see
> PasswordTextFields are not encrypted anymore)
Yep, I think we removed the other uses. I don't know exactly from the
top of my head, but it is in the (recent) mail archives.
> And if so, would it be of real use/need? Of course, It would increase much
> (as much as Java can) the security of the URLs' encryption but, would you
> see any other uses?
I can't really think of anything else besides that it is available as
a nice utility class.
> If this is only used for encrypting URLs, and if I am not wrong, our
> "WebApplication" class would also need something like this:
>
>
> ------(CODE WHICH WOULD GO INTO OUR "WebApplication" CLASS)------
>
> @Override
> protected IRequestCycleProcessor newRequestCycleProcessor() {
>
> return new WebRequestCycleProcessor() {
> @Override
> protected IRequestCodingStrategy newRequestCodingStrategy() {
> return new CryptedUrlWebRequestCodingStrategy(new
> WebRequestCodingStrategy());
> }
> };
>
> }
Something like that yeah :-)
> And more important: can I consider wicket's ICrypt and ICryptFactory
> interfaces *stable*? (at least until a stable 1.3.0 release). Have you got
> any short-term plans for changing anything in this encryption
> infrastructure?
That's definitively a stable interface. I don't see us changing that
any time soon. Btw, now that we are in RC mode, we won't be changing
any of the API unless there are very pressing matters, in which case
we'll have a vote about it. The idea is to enable users to just drop
in new versions/ jars in RC/ finals without having to fix for API
changes.
> So, JasyptCrypt will always throw an exception if this method is called.
> Currently in wicket, "setKey" is only called from
> org.apache.wicket.util.crypt.ClassCryptFactory, which jasypt does not
> extend, so this would not pose any problems for the future, but... could it
> make sense that that "setKey" method were called by the developer anywhere
> else? this would render jasypt integration quite complicated...
I guess we'll hear if that is a problem for someone :-)
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org