Hi,
I have a use case where I am running my site in one AEM instance and it has 'n' number of users where we have some logic of creating our new property as cq:password inside the /home/users/{site}/{profile} and this password is encrypted using AEM crypto support so when I am packaging the user created in my 1 instance and importing it to the another then users are getting imported successfully but when user is trying to login with those user then while decrypting the password it is throwing exception as invalid padding which is basically due to the different master key which is used to generate that encrypted password. I have also read that the master key should always be same that means the key should be same from which encrypted password is generated otherwise while decrypting, it will not work. This key is under the /etc/key location and here it has master key property.
So if I am importing the key also from my old instance then it is working fine but in this case the existing user of my new instance will not work as now i have updated the master key of new instance from the old one. So i want to maintain both the keys as per the sites.
What is the best way to handle this scenario?
Thanks
Solved! Go to Solution.
Views
Replies
Total Likes
If you transfer the password, this affords no security benefit. After installing the package reset password to default one & then send notification to all users creation of new account in new environment and ask to reset their password.
Views
Replies
Total Likes
One way to get users from one machine to another is to write script using the UserManager API. See http://jackrabbit.apache.org/api/2.0/org/apache/jackrabbit/api/security/user/UserManager.html.
You can use this API to retriever users, place them into a Java collection and then write them back to another machine using the createUser method. You may have to further update the passwords using the JCR API. You will have to write custom Java logic (for AEM crypto support ) to handle your password issue.
Views
Replies
Total Likes
If you transfer the password, this affords no security benefit. After installing the package reset password to default one & then send notification to all users creation of new account in new environment and ask to reset their password.
Views
Replies
Total Likes
Hi,
Thanks for the help.
I just want to highlight few more things about this issue. This property is just a simple data which is not for user or user password. It is simply encrypted data added by us using CryptoSupport, when user sign-in in the site and user don't have any option to reset this property. As this property is encrypted through master key stored in /etc/key so it is also expecting the same key while decrypting this property but as we have moved it to another instance so this key is different for each instance so it is not working while decrypting. Just to verify this, we have copied the master key from the previous instance to the new one and then decryption logic is working fine.
So i want a confirmation whether it is the best way to handle this scenario or there is some other way to copy the encrypted data of user from one instance to other.
Thanks
Views
Replies
Total Likes
For now Only option has you specified is to replicate /etc/key/@master
Views
Replies
Total Likes
Thanks a lot.
Views
Replies
Total Likes
FWIW user passwords are not related at all to Granite CryptoSupport. Further the CryptoSupport master key is not used in the evaluation of passwords. Passwords are evaluated entirely based on the values in the rep:password property. Repeated SHA256 iterations along with a per-user random salt provide reasonable security. That said password hashes should of course be kept secret.
-Rob Ryan
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies