sebadob/rauthy

bug: Password reset has different password policy than the login itself

Closed this issue · 3 comments

kerkmann commented

A user can reset their password and use characters like " in the reset (for example sj3478Dhksdk&jhB'\"6(4b7TB). After redirecting the user to the login page hes unable to login with with password. The server response with a

Validation errors in fields:
	password: Validation error: [a-zA-Z0-9,.:/_-&?=~#!$'()*+%]+$ [{"value": String("sj3478Dhksdk&jhB'\"6(4b7TB")}]

This should be allowed in the authorize endpoint or disallowed in the set password endpoint. :)

sebadob commented

Thanks for spotting this.
It should be removed on /authorize because you can literally put anything inside it. I will also put some validation for the max length in so you could not DoS the backend with providing ultra long passwords for hashing.

  • 👍1
kerkmann commented

I think it's not only the max length. I think also special characters are making problems. ^^"

Nevermind, you removed the regex validation. :D

sebadob commented

Yes of course the special chars. The URL validation was simply wrong, there should be none at all, because the password is being validated programmatically against the password policy later on. And allowing special characters of any kind is not a problem either, because we can't end up with sql injections, since passwords will be hashed anyway and never returned in clear text.

I just updated rust on that host though and have to fix the new clippy now :D

  • 🎉1