Feat: crypted password property

[achoqt]

Add a new property to provide a hashed password.

Currently, the password is readable in the bob file.

This feature enables one to input a hashed password using three possible hash algorithms (MD5, SHA-256, SHA-512).

In runtime, it will decrypt the password according to the selected hash algorithm.

See screenshot below:

• Testing:
  • generate a hashed password using MD5 or SHA-256, or SHA-512
  • enter the hashed password in one of the widgets which has the password property
  • select the hash algorithm you used to hash the password
  • run the .bob and test to enter the initial password

[sonarqubecloud]

Quality Gate failed

Failed conditions
16.5% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud

[achoqt]

Two checks failed.

• SonarCloud Code Analysis: duplication code.

Indeed, some lines are duplicated. I just added them the same way as in the existing code in the corresponding files.

• Lint:

I am not sure to understand the errors, and if I do need to fix them myself.

[georgweiss]

@achoqt, could you please provide some context here as to the need/requirements?

[achoqt]

Sometimes, we use password on action button to open expert GUI.
And the password is readable from the .bob file so far.

This PR would enable one to set a hashed password (using Md5, SHA-256 or SHA-512 hash algorithm), which would prevent the password from being accessible via the .bob file::

so to prevent the password from being version with the .bob file in github or any other version-control software.

[lcaouen]

@georgweiss
@achoqt works with me and is a member of the CEA team. This issue is an improvement we need for one of our projects.

[georgweiss]

Yes, I understand that a hashed password makes it more difficult to circumvent the protection. However, it is not very difficult to un-hash the password from the bob file, so in my view this feature does not in practice add any more protection. A user could also copy or edit the bob file and remove the password dialog altogether.

Ideally one would need some more robust authentication mechanism to protect OPIs.

[achoqt]

Regarding the point:

A user could also copy or edit the bob file and remove the password dialog altogether.

We have sometimes the case where the UNIX permissions allow the user to read the .bob file but not to write to it.

[achoqt]

Moreover the feature is retro-compatible, it will not break the widgets that already use passwords.