|
From: Tomas G. <to...@pr...> - 2017-03-22 08:36:41
|
Hi,
We don't call it encryption, but obfuscation, since we don't claim the
purpose is to encrypt data so it can not be recovered.
That said, making it into user configurable encryption is a good idea, I
agree. Patches would be very welcome.
Regards,
Tomas
On 2017-03-21 18:45, Jaime Hablutzel Egoavil wrote:
> I'm looking that EJBCA is currently hardcoding the password encryption
> key in org.cesecore.util.StringTools:
>
> ...
> private static final char[] p =
> deobfuscate("*OBF:1m0r1kmo1ioe1ia01j8z17y41l0q1abo1abm1abg1abe1kyc17ya1j631i5y1ik01kjy1lxf*").toCharArray();
> ...
>
> But, why don't you allow it to be overrided from configuration files?,
> this way, encrypted auto-activation passwords would be more secure for
> the ones aware of the possibility to override the default encryption key.
>
> Finally and just for reference, take a look at the following similar
> mechanism (where users are even forced to change the encryption
> key/password) in a completely different
> framework, https://www.playframework.com/documentation/2.5.x/ApplicationSecret (the
> first paragraph suffices).
>
>
>
> --
> Jaime Hablutzel - RPC 994690880
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
>
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>
|