On 26/05/21 13:38, Colm O hEigeartaigh wrote:
Hi Francesco,
1. The docs
(https://syncope.apache.org/docs/2.1/getting-started.html#moving-forward)
state that the "secretKey" value is only needed if
adminPasswordAlgorithm or password.cipher.algorithm is "AES", implying
that it could be left blank if you are not using AES. However, I see
CipherAlgorithm.AES in the source code in several places (e.g.
./core/idrepo/logic/src/main/java/org/apache/syncope/core/logic/AccessTokenLogic.java),
which implies that secretKey should always be required. Which is
correct?
That's correct, docs need to be adjusted.
OK I can do this. Is it possible though to state exactly what
reversible encryption is used for in Syncope? This kind of information
might be needed for compliance purposes.
AES (the only CipherAlgorithm capable of reversible encryption) is used:
* (as any other CipherAlgorithm defined) for admin and User authentication
* (as any other CipherAlgorithm defined) for Binary Plain Attribute values
* in case cleartext version of user password is not available, during
propagation to External Resources - typically, when propagation is not
triggered as consequence of a REST operation
* for Linked Accounts' password values
* to securely store Access Token's cached authorities
* within DefaultPasswordRule and HaveIBeenPwnedPasswordRule, to check password
value against defined policies
secretKey is a random string, whose value is bootstrapped during Maven project
generation from archetype, and filtered by Maven into security.properties
If the provided value is less than 16 characters length, it gets padded before
usage at
https://github.com/apache/syncope/blob/master/core/spring/src/main/java/org/apache/syncope/core/spring/security/Encryptor.java#L151-L161
I think this implementation is a bit problematic. Because the
"secretKey" is alphanumeric there is no way for a customer to generate
a truely random AES key. It would be a lot better if we supported
storing the key in a hex or base-64 encoded form. Then we can just
tell customers they can create a random key via e.g. openssl rand -hex
32
Secondly, it would be more secure if we didn't specify any value by
default in security.properties, but used SecureRandom to generate a
value if none exists on start-up + write this out instead.
I think we can change things on master without worrying too much about breaking
existing deployments (but not on other branches).
I am not sure to figure out where to store the generate random value on startup
(in case it was not provided) so that next runs will find it.
anonymousKey is a random string, whose value is bootstrapped during Maven
project generation from archetype, and filtered by Maven into
security.properties
Together with anonynousUser (whose value is 'anonymous' by default), it is used
for non security-sensitive REST calls, as an alternative to leaving some
endpoints accessible without any authentication.
Again, should we instead leave it empty by default + generate a secure
value without having this hard-coded value?
Same thoughts as above.
Regards.
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/
