diff options
author | Nicholas Johnson <nick@nicksphere.ch> | 2022-05-23 00:00:00 +0000 |
---|---|---|
committer | Nicholas Johnson <nick@nicksphere.ch> | 2022-05-23 00:00:00 +0000 |
commit | 05fa3051e12acddfe320912a93e1927bcf1b64f6df2a14589594144df3b9f3e2 (patch) | |
tree | e2f767706bbef2caf24a3fd5ea9147f6866d3fef2c0e732f9b481932e87d67ea /content/entry/siue-eid-creation-and-maintenance-problems.md | |
parent | 44ef9882132619ead1f888778804893d848b7686a4833e038b67b263165eb933 (diff) | |
download | journal-05fa3051e12acddfe320912a93e1927bcf1b64f6df2a14589594144df3b9f3e2.tar.gz journal-05fa3051e12acddfe320912a93e1927bcf1b64f6df2a14589594144df3b9f3e2.zip |
Fix spelling errors
Diffstat (limited to 'content/entry/siue-eid-creation-and-maintenance-problems.md')
-rw-r--r-- | content/entry/siue-eid-creation-and-maintenance-problems.md | 12 |
1 files changed, 6 insertions, 6 deletions
diff --git a/content/entry/siue-eid-creation-and-maintenance-problems.md b/content/entry/siue-eid-creation-and-maintenance-problems.md index 4ed019d..9727274 100644 --- a/content/entry/siue-eid-creation-and-maintenance-problems.md +++ b/content/entry/siue-eid-creation-and-maintenance-problems.md @@ -28,7 +28,7 @@ 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[3] 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. +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[3] 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. @@ -43,11 +43,11 @@ Every 60 days, you are required to reset your password[4]. The NIST password pol 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. -# Autogenerated Password Patterns +# Auto-generated Password Patterns -If your password is reset using your security question, or you get your password generated for you at the helpdesk, 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 autogenerated by SIUe. They have patterns. If you obtain an autogenerated 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. +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 UI +# Annoying User Interface ## Looks Take a look at the creation and maintenance page[5]. 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. @@ -57,7 +57,7 @@ The date of birth on the "I want to get an e-ID" option and the "I have an e-ID The new password and confirm new password fields on the change password page[6] 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 webpages, 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/[7], the results were as expected. Every URL I checked had invalid HTML at the time of this writing: +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/[7], 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[8] (85 errors) * https://eid.siue.edu/am/get_e-ID[9] (16 errors) @@ -78,7 +78,7 @@ When it lets you change the secret phrase and answer, it literally shows you the # Denial of Service Vulnerability There is a denial of service vulnerability related to the change password form[14]. 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[15], 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 helpdesk 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 helpdesk 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. +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. Link(s): |