Skip Navigation

[Escalated to 2nd Tier] Toolset Forms sanitizes Password in user form

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Sun Mon Tue Wed Thu Fri Sat
- 10:00 – 13:00 10:00 – 13:00 10:00 – 13:00 10:00 – 13:00 10:00 – 13:00 -
- 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 -

Supporter timezone: Asia/Kolkata (GMT+05:30)

This topic contains 1 reply, has 2 voices.

Last updated by Minesh 7 months, 3 weeks ago.

Assisted by: Minesh.

Author
Posts
#2690259

Toolset Forms appears to sanitize the user submitted password in password reset forms (and possibly in add-new user forms).

AFAIK WordPress itself does NOT sanitize passwords, since out is hashed on insert.
And since the same steps work fine in WordPress admin screens, I think this is confirmed.

Steps to replicate the issue:
1. Create a new user edit form
2. Keep only the two password fields in the form (I used the classic editor for simplicity)
3. Insert the form in a page
4. Edit your own user's password using this form and make sure to use a double apostrophe like below

NewPassword"

5. Try to log in with this new password and see how you cannot log in anymore (wrong password).

Repeat the same in the WP Admin Edit User Interface and see that it works fine.

==> Perhaps there are other special characters that are causing the same
==> Perhaps the same happens when creating a new user
==> It is a very disruptive issue since a user password should always be left to user choice, and not allowing certain symbols is not "typical"

The issue can be replicated on a clean WP/Toolset Install with latest versions of software.

#2690276

Minesh
Supporter

Languages: English (English )

Timezone: Asia/Kolkata (GMT+05:30)

Hi Beda ,

Thanks for the report and I can confirm that the issue is there with add/Edit user form where password having single or double quote.

Perhaps there are other special characters that are causing the same
===>
I checked with single quote ` or/and double quote " I can see the issue. Not sure what other special characters are sanitizes.

However - I checked with following special characters !@#$%^&*() those are working fine.

I've escalated the issue to 2nd tier and I'll get in touch with you as soon as I've any news on this issue.