Security module saves password as unecrypted text

[PMitec]

Hi

I have today encountered an issue with the built-in security module of scriptcase. When updating a user’s record through the corresponding form, scriptcase will save the password as unencrypted clear text into the database.

This means that
a) the user can not log in again or change the password, since the app expects the encrypted password
b) everybody with viewing access to the table can now see the unencrypted password

This happened every time I updated a specific user - in this case myself - but it did not happen to any of the other users I tested this with by updating their records.
I have done this in the past and I know it happened before, but I am unsure if it hapened every time.

Logging out of the production environment did not fix the issue. Using the deployed version of the project (instead of the developement version under …/scriptcase/app/project) did not fix the issue. Changing the user who does the updating did not fix the issue.
Using incognito mode seems to fix the issue. Using a different PC seems to fix the issue.

I use the built-in version of the security module (with only a few cosmetic changes to the html) and version 9.13.018.

[Julio_Cesar]

This is a very serious issue.

Storing passwords in clear text, even temporarily or only under specific conditions, is a critical security problem. It affects both application integrity and user privacy, and it can create real exposure if anyone has access to the database table.

This is exactly the kind of situation that made me move away from it. When you lose control over something as fundamental as fixing a security-related bug yourself, and you have to wait for the vendor to identify, confirm, and patch it in a future release, that is a clear sign that the tool may not be the right choice for serious development.

You must have direct control over the authentication logic, password hashing, database writes, and debugging process. If something goes wrong (ex. in Laravel), you can inspect it, patch it, test it, and deploy a fix without being blocked by the internals of the tool.

[rperrett]

That is indeed quite serious. I am curious what the cause of this was/is. I have been using AI more to debug weird SC issues. I upload the deployed app to AI and tell it my problem. It is surprisingly good and debugging the compiled code and telling what is really going on.

[Ojuara]

Hello.
Perhaps Google Translate into my native language didn’t allow me to understand the real problem of this post, so if I answer something that isn’t exactly about the problem, I apologize. I also use Google to translate this answer into English.
Regarding the password field being saved in plain text, I believe that simply not displaying the password field on the screen is enough; it shouldn’t exist for editing in the form linked to the user table. If you want to change the password, create your own ‘control’ type application for this.
I don’t use any default applications generated by Scriptcase for security (none at all). In fact, I don’t use the default log, the default menu, or the default security module. All security aspects, involving users, applications, user groups, access permissions, everything was developed by me from scratch.
I use ARGON2ID encryption (considered the most difficult to break, calculated according to the resources of my server). Don’t trust the default applications; create your own and use them in all your projects. This way, you won’t have problems like the one in this post.

If I can help in any way, please let me know. I’ve been using “SC” since version 4 of 2009 and work with it every day with MySQL and Oracle on huge port-related projects. If I can be of any help, it will be a pleasure.