No Wonder We Lose

If you use the Internet, then whether you know it or not, identity is one of your biggest issues. Whether you’re purchasing books online, reading your e-mail, checking on your account balance at the bank, paying your bills, or even just reading a news story, you will quickly find yourself tangled in a sticky web of identity issues, requiring you to strike a careful three-way balance between ease of use, security, and privacy. It’s not easy to get that balance right, and more often than not, we miss the mark.

But sometimes, we miss it worse than others. My latest entry for the Computer Security Hall of Shame comes from the Dartmouth College Office of Off-Campus Programs, which coordinates exchange programs for students at other universities, typically abroad.

First, a little background: When a student applies to go on an off-campus program, such as an LSA or FSP*, there is a requirement that (s)he obtain recommendations from one or more faculty members. These recommendations are intended to attest to the student’s work ethic and character, and until recently, faculty members wrote them by filling out a paper form provided by the Off-Campus Programs office. Recently, Off-Campus Programs set up a web site where faculty recommenders can sign on and answer the recommendation questions electronically. That’s fine with me, although I find it amusing that they thought it was important to limit each response to 4,000 characters of text; assuming an average of 5 characters per word, that comes out to about 800 words. Now, I don’t know about you, but I do not frequently write between three and four double-spaced pages of text in response to a simple question about the length and nature of my association with one of my students. But, that’s all right — somebody probably just had a little fun learning JavaScript.

In order to get recommendations using this system, students submit the names of professors to the web site, and a script generates an e-mail to each professor, containing information about how to sign in and fill out the recommendation form. The e-mail contains a URL, so that the instructor can go right to the web site. So far, so good.

I recently received one of these e-mails, on behalf of one of my former students. I followed the link to the web site, and was surprised to discover that I could fill out and submit his recommendation without any proof of my identity. The system recognized who I was, from some information encoded in the URL, but anybody could conceivably have clicked on that link — no password, no Kerberos token, no PKI certificate, nothing.

I was somewhat alarmed by this, but my curiousity was also piqued. Looking at the URL, I noticed a field named User_ID in the query section. Its contents were opaque, consisting of a string of sixty-eight digits and letters. With no letters after F in the alphabet, it was easy enough to infer that these were hexadecimal digits — so, presumably they’d encoded something interesting. Maybe it was some kind of confirmation code, generated by the system so that only the recipient of the e-mail could access the correct recommendation form. That would be kind of clever, since it’s well known that people don’t like to have to deal with passwords and identity tokens, even to protect their own best interests. What could it be?

I could see by inspection that it wasn’t just plain ASCII text — there were values like 1, 10, and 25, which do not code for characters you would ordinarily display to a user. Perhaps it’s compressed or encrypted, I thought — that could help insure that only the web server could interpret the results, and prevent random users from forging their own confirmation codes. I cranked out a few lines of Python to decode the bytes and try some common decompression algorithms, but found nothing conclusive.

And then, just on a whim, I tried something that had no right whatsoever to work. See, sometimes, programmers are lazy, and doing encryption correctly can be tricky. So occasionally, someone will try to obscure their data by scrambling it with a simple encoding, like adding a fixed value to each byte or applying the exclusive-OR operation. Since there are only 256 possible keys for such a transformation, it’s trivial to try it out — so I did. It amounted to six lines of code, and took a tiny fraction of a second to run. Sure enough, if you computed the XOR of each byte with 84 (that’s 54 in hexadecimal), out popped a plain text message.

My e-mail address.

So much for security. No confirmation numbers, no clever encoding, nothing. Just the e-mail address of the recommender.

Maybe you don’t think this is a big deal, but it offends my sensibilities. The way this system is written, it would be trivial for a student to forge recommendations for himself or another student,** or for one professor to write the recommendations in the name of some other professor. Even though I don’t consider either possibility terribly likely to occur, I think it’s pathetic that whoever implemented this system couldn’t have done something better. Dartmouth is positively swimming in clever security solutions — not to mention smart folks with bright ideas, from the PKI/Trust Lab to the Institute for Security Technology Studies and more — it’s raining soup, as the old saying goes, and all one must do to avert starvation is to bring a spoon.

Just because this whole nonsense kind of ticks me off, here for your pleasure is a form you can use to generate your own User ID for the Off-Campus Programs web recommendation system. You can also have the JavaScript code for this form, if you like. I neither endorse nor advise using this for anything other than personal amusement.

Enter your e-mail address, or a User ID to decode:

Result: (nothing computed yet)

And, yes, I did write to the Office of Off-Campus Programs to report the problem — so at least there is some hope it might get fixed someday. But I’m not holding my breath.

* A note for non-Dartmouth folk: LSA stands for Language Study Abroad, while FSP stands for Foreign Study Program. As the name suggests, an LSA is intended to give students intermediate to advanced training in a foreign language in situ. An FSP is generally not focused on language study per se, but usually takes place in a country other than the U.S.

** Imagine the following scenario: Alice submits a nickname similar to the name of her professor (Carol) to the recommendation system. Bob, meanwhile, adds that nickname to his account. Even if the system resolves names against the name directory, it’s Bob’s address that will be found, not Carol’s. Bob fills out a highly favourable recommendation for Alice, and Carol never hears of it … which is fortunate, since Carol really can’t stand Alice, and would like nothing better than to keep her from realizing her ambition to spend a term in Morocco.