SIUe e-ID Creation and Maintenance Problems

Arbitrary Password Rules

I’ll go over them one at a time. They are found at https://eid.siue.edu/am/change_password.

• The previous 6 passwords cannot be reused.

I don’t have much to say about this one. It only reduces the password space by 6, so it doesn’t make brute-forcing easier.

• A password must contain at least seven characters (letters or numbers) but no more than eight characters.

Cringe! The 2017 NIST guidelines say passwords must be at least 8 characters. SIUe seems to have gotten this advice backwards with a maximum of 8 character passwords.

• A password must contain at least five unique characters.

This goes against the 2017 NIST guideline against imposing composition rules for passwords. It also reduces the already small password space.

• A password must contain at least one letter (A-Z or a-z) and at least one number (0-9).

Again imposing an arbitrary composition rule that reduces the password space.

• A password must start with a letter or a number.

Do I even need to say it a third time?

• A password cannot contain any of the characters $&@=+"/[]:;|*,?<>~’ or a space.

Throw out the NIST guideline on using all printable ASCII characters and Unicode. In fact, it doesn’t support Unicode. I tried inserting a Unicode character only to get errors. From a security perspective, this rule is extremely concerning. I’m not sure what it’s trying to do, but some of the characters are used in SQL commands. Could this indicate a SQL injection vulnerability? Since SIUe has to update the password across multiple systems (Blackboard, Outlook, etc.), it could be due to a compatibility issue. This could also be a security concern.

I’m going to lump the last 4 together because the only thing I have to add is that they reduce the password space again and are composition rules.

• A password cannot be a person’s name, an e-ID or any word found in the dictionary.
• A password cannot be any of the following spelled backwards: a person’s name, an e-ID or any word found in the dictionary.
• A password cannot have a repeating pattern (e.g. ababab or abcdefg).
• A password cannot have a pattern like ‘ccNNNNNc’ where ‘c’ represents any character and ‘N’ represents any number. (These are National Insurance numbers and are widely known on the web.)

60 Day Reset

Every 60 days, you are required to reset your password. The NIST password policy guidelines say users shouldn’t be required to change their passwords regularly or arbitrarily. If an account is compromised, then it makes sense. But otherwise, you’ll just be making everyone increment the last digit in their password every time. Almost no one will create a completely different password when they can just change one character.

Furthermore, all these password rules make it much more difficult to analyze the number of possible passwords. To do that, you would need every e-ID and every word in “the dictionary”. Who knows what words are included even. I’m certain that even the administrators have no idea how big the password space is, but it’s definitely insufficient. This brings me to my next point.

Auto-generated Password Patterns

If your password is reset using your security question, or you get your password generated for you at the help desk, there seems to be patterns to the passwords. I’ve noticed after testing this out by resetting my password that the generator always seems to prefer 2 digits and 6 letters. The generator seems to prefer 3 letter sequences with a consonant followed by a vowel followed by another consonant. This makes it easy to pronounce. It always uses lowercase. I don’t think I have ever seen it use uppercase. This is why I do not recommend using passwords auto-generated by SIUe. They have patterns. If you obtain an auto-generated password, change it as soon as possible. Since the generator algorithm is closed off, there’s no way to know how secure it is. Your best bet is to generate a password yourself using a password manager and memorize that.

Annoying User Interface

Looks

Take a look at the creation and maintenance page. I myself am not great at designing graphical user interfaces, but this one is bad. There was a class I had where the professor went over how awful the creation and maintenance page was during the class, but I won’t mention who. Some things they noticed on the face of it: For some strange reason, the table has four columns, but the third and fourth column only have one item. The radio buttons get their own separate cells which look awful with the borders. Everything is at the top of the page, not centered. The gray background is very bland and it looks like not much thought was put into the color scheme. And it definitely isn’t going to look nice on mobile.

Input Ambiguity

The date of birth on the “I want to get an e-ID” option and the “I have an e-ID but I forgot my password” option have 3 separate input boxes! The day and month are dropdowns while the year is a text box. It doesn’t indicate how you should enter the year either, as 2 digits or 4 digits. It wants 4. But, if you enter 2, it gives you a generic error message saying the account information is not correct.

The new password and confirm new password fields on the change password page allow you to input in your browser 9 characters, but the server just rejects anything more than 8. It also has text above the input field saying it only allows 8 characters.

Invalid HTML

After seeing the poor quality of the subdomain’s web pages, I got curious and clicked view source. They were using XHTML 1.0 and the legacy windows-1252 character encoding. After checking all the pages reachable from the radio buttons with the HTML validator at https://validator.w3.org/, the results were as expected. Every URL I checked had invalid HTML at the time of this writing:

• https://eid.siue.edu/am/e-ID (85 errors)
• https://eid.siue.edu/am/get_e-ID (16 errors)
• https://eid.siue.edu/am/reset.pl (19 errors)
• https://eid.siue.edu/am/change_password (91 errors, 2 warnings)
• https://eid.siue.edu/am/bid_lookup (14 errors)

The landing page for the university at https://www.siue.edu also had invalid HTML yielding 13 errors from the validator. Other URLs under the SIUe domain also had errors. These errors are less severe than the creation and maintenance page but still deserve to be addressed. The HTML looks like it was written in an editor, not by a human.

Usability

After you submit the change password form, you are redirected to a webpage where you have the option to change your secret phrase. You can use the secret phrase to reset your password if you forget it. The problem is the secret phrase works the opposite way than you think it does. You don’t select a question and input the answer. You input both the question and answer manually. And then when you go to reset your password, it will give you the answer to the secret phrase and you have to come up with the question. If you think about it for a while, it’s not hard to see that some answers correspond to really only one question. So this is not a good scheme.

For example, “The Incredibles” is the hint. You can guess the question “What is your favorite movie?”. On the other hand, picking a question from a dropdown box and having a normal security question challenge setup would be a better scheme. If a student isn’t aware of how the system works, it might leak sensitive information about them to hackers, especially since they can define their own question and answer.

Data Stored in Plaintext

When it lets you change the secret phrase and answer, it literally shows you the existing secret phrase and answer. That means that the question to your secret phrase is not hashed and salted. SIUe has a big database of questions of ~13k active students. And don’t forget all past students’ questions and answers going back years are still in the system. And their answers to those questions are just sitting on a server somewhere ready for a data breach. This is pure negligence and should be fixed as soon as possible. There’s no reason to have personal questions and answers of students sitting on a server somewhere in plain text.

Denial of Service Vulnerability

There is a denial of service vulnerability related to the change password form. If you unsuccessfully reset your password more than 5 times, your ability to reset your password will be locked for 24 hours. This password reset attempt limit persists across browsing sessions and IP addresses. It must be stored on SIUe servers. That means anyone can use the people search feature, which I covered previously, to scrape for e-ID’s. Then, they can spam the password reset form with every e-ID scraped from the search feature. Since it’s only necessary to do this once every 24 hours per account, anyone can effectively break the password reset feature for all active students, faculty and staff with a simple Python script.

Of course, students can make a call to the help desk to get the password reset limit fixed so they have 5 more attempts within the 24 hours. But it’s possible to run this attack continuously with such high volume that even students who call the help desk and get a reset on the attempts cannot change their password. I’m not encouraging or condoning denial of servicing the change password feature. I’m only pointing the attack vector exists in the hope that it gets fixed.