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. > 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. > 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? Thanks, Colm. > > -- > 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/ >
