Our development team wishes to get rid of the default Servoy user and group security that is being stored in the servoy_repository db. This due to mandatory security requirements of one of our customers.
Under the Users on Servoy Admin page, a list of ALL users is displayed and we wish to eliminate it. Now, during the creation of a user in our software, we call the following piece of code:
This creates a user in the user table of servoy_repository db. We will change this such that the user will be created in the customer’s db. However, since we currently are depending on the servoy_repository db, we first wish to migrate the data from that db to the customer’s db so that we do not lose this data. However, the Servoy user password is encrypted in:
(1) an encryption type we do not know
(2) probably with an encryption key we do not know
My question now is, is there a way (i.e., with a plugin) to retrieve the decrypted password of a user?
Passwords in the repository DB are not encrypted but hashed.
Hashing is (by design) a one-way algorithm. So plain-text passwords are not recoverable.
Also, if you are planning to migrate your security, please consider the SvySecurity extension.
There was a recent webinar about this brand new extension
If you can’t reverse password why don’t you just modify and use your login solution to help you in your migration scenario:
In your authentication process you can check « Does my user exist in my new authentication source and is migrated? »
NO => use the login/password and whatever info that your user input for legacy authentication to create or update your user to new db and the next time it should be authenticated in your new process
YES => just authenticate him with your new authentication process
Or you send all your users an e-mail explaining the password system has been upgraded and include an activation link where the users can create a new password using your new password system and policies.
Thank you all for the response. I did not know the passwords stored in the repository db were hashed. It is indeed obvious we are unable to recover these passwords as plain text.
The easiest and safest way to implement our new password system, is to inform our customers to renew their passwords once this development becomes active.
I like Fabrice’s suggestion best. Once a user logs in with his password, you do have the password in real text. Then you can check if that user is already using your latest authentication mechanism. If not, you run some code that converts him automatically to that and remove that user from the security. Once all users have been auto migrated, you can turn off your migration process.