password field for admin UI (not related to e107 users) - how to set md5 for it and only for it?

[Jimmi08]

Hi,
I have plugin with password field - similar like with user, you can generate safe password, show it...

But how to save it in md5 way, but not change core setting for password field?

Standard Admin UI is used. Is there a setting for this in the field configuration?

Thanks

[Deltik]

You can use UserHandler::HashPassword() to generate a password using a specific hashing method.

Documentation for reference:

---

Description

public UserHandler::HashPassword(string $password, string $login_name = '', $force = false): string|bool

• The HashPassword function accepts three parameters: $password, $login_name, and $force.
• It generates a hashed password string to be stored in a database, given a plaintext password and login name.
• The hashing method of the password can be forced using the $force parameter, otherwise, it uses the system's preferred hashing method.

Parameters

• password (string): The plaintext password as entered by the user.
• login_name (string): The string used to log in. This could be an email address. Its default value is empty.
• force (false, PASSWORD_E107_MD5, PASSWORD_E107_SALT, PASSWORD_E107_PHP): If set to one of those constants, it forces that particular type of password hashing method. The default value is false.

Return Values

• Returns a hashed string to be stored in the database upon successful execution.
• Returns false if an invalid hashing method is used.

Examples

$password = "secret";
$login_name = "email@example.com";
$force = PASSWORD_E107_SALT;

$encrypted_password = e107::getUserSession()->HashPassword($password, $login_name, $force);

echo $encrypted_password;

Notes

• If the $force parameter is not provided or set to false, the function will use the system's preferred hashing method.
• If $force is set to PASSWORD_E107_PHP but the password_verify() function is not available, it falls back to PASSWORD_E107_SALT.
• The function currently supports three types of password hashes: PASSWORD_E107_MD5, PASSWORD_E107_SALT, and PASSWORD_E107_PHP. If an unsupported hashing method is provided, the function will return false.

[Jimmi08]

Thanks for the great explanation. It should be added to the documentation too.

But when/where to use it with Admin UI? (I just remembered that custom page uses password field too, I will look there later).

I mean:

• is it possible to set in WriteParm()?
• or it should be set in beforeUpdate() or afterUpdate() method?
• or method type field should be used and its own functionality?

I will try and see, of course, but how should it work by default?

[Deltik]

I see that users_admin_ui::beforeUpdate() uses UserHandler::HashPassword(), so I would say mutate the password input in an override of e_admin_ui::beforeUpdate(). When rendering the form, leave the password blank to signify no changes, and update the password only if the password field is filled out.

[Moc]

Just an addition to Deltik's answer: I strongly recommend to NOT use PASSWORD_E107_MD5. Instead, use the default option (PHP).

[Jimmi08]

@Moc is a special case when the password field is used in other cms too. Now I need to maintain 2 ways of administration of admin accounts. And I am not able to change Nuke admin authentication. e107 users have to use e107 way, so using admin UI methods for changing value is correct way.

[Moc]

@Jimmi08 I understand but please note that md5 was never intended to be used as password encryption and it is therefore not safe. Strings that are MD5 hashed can be very easily be converted back into readable format, so it gives no level of protection at all. It's practically the same as storing passwords plaintext.

[Jimmi08]

@Moc I understand. And no password is safe if the attacker knows the login page and there is no other protection (Like blocking IP after some failed attempts) That CMS is the fork of PHPNuke, completely rewritten by some genius Czeck guy mainly because of security reasons a long time ago.

For me its safety is in:

• the code is not available anymore (or very outdated version, I already removed PHPbb stuff)
• separated tables for normal users and admins (so if they break the normal login page, the admin area is still safe)
• no published admin link (link to login to admin area) anywhere on pages. You need to know it if you want to log in - so no link like in the welcome message for boots, no forgotten password for admins. Only nick "God" - yeah, it is the nickname for the main admin with the possibility to manage admins.
• you can change the admin link anytime and to any file name as you wish. (I can see in logs how they try to use wp-login.php, admin.php etc)
• with this system, there was the need for a captcha or any other protection for twenty years.

The user part is a different topic. I already replaced the login system with e107 handlers. It means - still both tables for users but the login logic is the same (if e107 login fails - will all its checking and password type - then the user is not logged in UN either). And because you can't log in to e107 directly :) ha, more safe than e107 itself.

And, yes, it is outdated. I really like e107 Admin UI, so I did a plugin for managing this table. The only thing left is - password - but it is pretty cool to generate it, to show strength, and so on.

When I have time, I will look at the possibility of replacing md5() and login check. It shouldn't be so hard.

To close this topic - yes, you are right, I am aware of the risk, and with the information above I plan to fix it. Just to find time. The only question is safety and the next development of e107 itself.

This is the exact copy of UN form in e107 environment: