Note: keeping bug public so customer can follow. +++ This bug was initially created as a clone of Bug #233461 +++ Description of problem: URL: https://www.redhat.com/wapps/ugc/register.html - password rejection message does not state the allowed/disallowed characters nor the character max length limit. password rules seem strange as some non numeric non letter characters are accepted but others are not. recommend that we are more lenient in allowing these types of characters in passwords as it increases potential security. From customer: "If I enterred a password that was too short I got a nice little message telling me it had to be at least 6 characters long. If I entered one that long or longer that was rejected as invalid I was given no clue as to why or what characters were allowed or not. I'm guessing '<' was not a valid character but it would have been easier to figure out if there were a little popup or something that just explained the rules for passwords. I still find it weird that '<' seems bad but ':' seems good. Update from customer: "I created an account which has a password that includes the '[' character. This works fine on RHN but when trying to register a guest VM during firstboot now I discover that the character '[' is not accepted in the password field preventing registration." Things to look at: - acceptable password rules for SSO account creation - acceptable password rules for SSO account login - acceptable password rules for RHN Register account creation - acceptable password rules for RHN Register account login
update: only seems to be an issue with RHEL 5 system registrations. RHEL 4 registration client seems to accept the '[' character.
Just FYI, the reason the angle brackets are prohibited is to prevent cross-site scripting attacks.
I'm not lobbying for including angle brackets or anything else in particular. I would like to know what the "official" password rules are governing RHN and other related Red Hat logins. If they are public I haven't run across them yet. They appear to be inconsistently enforced in various places from my experience. Perhaps I should stick to the alphabet for now. It is scary to have a password change allowed by RHN and then not be able to login with it.
It isn't too surprising that the old clients aren't enforcing new rules. However, relaxing the rules would mean we'll never be able to move forward. Setting this to NEEDINFO to get the business to tell us whether they want to continue with the new rules, or revert to the old practice.
Moving everything to ON_DEV to get revisited for the "true up" release.
We ran into an example of this today. A old RHN user has an account with a password of 5 character length. - He can log into the rhn hosted website just fine - rhn_register on RHEL5 will fail tho and not allow login. He updated his password to 6 characters and rhn_register now works. Perhaps the rhn hosted website should detect < 6 char logins and "force" the user to change their password when they log in?
UserService and the wapps UI have rules, but only the UI enforces them :( . We must therefore enforce the rules in our UI as well, in order to keep bad data out of UserService, until such time as UserService does its own policing. The rules are that the password cannot contain the characters (space) < > " , and must be between 6 and 38 characters long TEST PLAN: ========= On both the user-details and the create-new-user pages in RHN: .../rhn/account/UserDetails.do .../rhn/users/CreateUser.do?account_type=into_org you should now see a note next to the "Desired Password" field describing the rules. The characters (space), <, >, and " should be rejected in the desired/confirm password fields, in order to match the rules in user-service. Please test the following combinations in those fields: 1) empty field EXPECTED: Error messages for desired/confirm, with "must be at least 6 characters" 2) less than 6 chars per field EXPECTED: Error messages for desired/confirm, with "must be at least 6 characters" 3) desired != confirm EXPECTED: Error message, desired must equal confirm 4) password starts with one of (space) < > " 5) repeat 4, ends with 6) repeat 4, contains 7) repeat 4, consists solely of 8) repeat 4-7, except with multiple instances of the forbidden characters EXPECTED: In all cases, error message for desired/confirm "are invalid" 9) password is > 38 characters EXPECTED: The form will stop accepting input at 38 characters
Sending rhn-common/src/main/java/com/redhat/rhn/common/validator/SchemaParser.java Sending rhn-common/src/main/java/com/redhat/rhn/frontend/struts/RhnValidationHelper.java Sending rhn-common/src/main/resources/com/redhat/rhn/frontend/action/user/validation/userCreateForm.xsd Sending rhn-common/src/main/resources/com/redhat/rhn/frontend/action/user/validation/userDetailsForm.xsd Sending rhn-common/src/main/resources/com/redhat/rhn/frontend/strings/jsp/StringResource_en_US.xml Adding rhn-web/src/main/java/com/redhat/rhn/frontend/action/user/UserForm.java Sending rhn-web/src/main/webapp/WEB-INF/pages/common/fragments/user/edit_user_table_rows.jspf Sending rhn-web/src/main/webapp/WEB-INF/pages/user/create/usercreate.jsp Sending rhn-web/src/main/webapp/WEB-INF/struts-config.xml Transmitting file data ......... Committed revision 118734.
I can't be Q Contact, I'm the one that did the code!
Massively Fails QA, tests 4-8 all fail. The pages in question will let you enter whatever special characters you wish, you just can't log in with your new password. Clearly we didn't get the update from dev.
Verified ggainey had to remove tomcat's working directory to get it to reload the new .xsd files. Extra step has been added to content doc.