Nils' Lesestoff

“Wait a sec,” the Edutron Systems rep interrupted, cutting off the principal of River City High, “your students still use pencils and paper to take exams!?” The rep insincerely chuckled, adding “don’t tell me you’re still using slide rules to teach arithmetic!”

As shifty as the sales rep was, he did have a good point. It was 1993, after all, and the information superhighway was on the verge of explosive growth. If the principal knew one thing, it was that he – and most certainly, his students – did not want to be left in the dust. And if nothing else, Edutron Systems could help point River City High towards the onramp.

Edutron System’s flagship product was Classroom Assistant, which served as “an integrated digital notes organizer for today’s high-tech, on-the-go students.” Informally, it was referred to as the “digital Trapper Keeper” that “held a virtually unlimited number, each with a virtually unlimited number of pages.” In reality, Classroom Assistant was a glorified text editor that read and wrote files to the 3.5" floppy disk that each student was supposed to carry around.

To be fair, Classroom Assistant did have several other modules in addition to the in-class note taking module. Granted, none of them had anything to do with the “information superhighway,” but no one seemed to notice or care, as the software did run on a computer, which meant pretty much the same thing. The module that everyone was excited about, however, was for test taking.

The test taking module was designed with two key goals in mind. First and foremost, it made teachers’ lives easier by “digitizing” the entire process and, secondly, it reduced cheating by making sure each student had a different copy of the test.

To create a new test, all teachers would have to do was write up a bunch of questions and then “deploy” them to each of the classroom’s PCs. Because Classroom Assistant wasn’t a networked product, deploying the tests involved taking the 3.5" disk containing the test questions and then loading the disk into each computer.

Taking the “digital” tests was even easier. A student would simply select the appropriate test from the “test library”, run through the randomly selected questions, and then instantly see her results. She’d then raise her hand, and the teacher could then write down the test results as seen on the screen.

At least, that was the theory. It took all of one test for the students to find a flaw in the system: if one received an unsatisfactory score, he could simply retake the test. Classroom Assistant didn’t bother recording how many times each test was taken. Sure, retaking the test several times was time-consuming, but generally worth the effort.

On the second test, students found a slightly easier workaround: they could simply run a different test. Since the results screen did not indicate which test was taken, all one needed to do was open up the “Test Taking Tutorial” test and pass it with flying colors.

When the third test rolled around, yet another workaround was uncovered: the results screen displayed only the percentage of questions answered correctly and a list of incorrectly answered questions. So long as they were able to answer the first question correctly, they’d get an easy 100%.

By the time the fourth test rolled around, the teachers had finally figured out a workaround of their own: they required that students enter the last question’s answer in front of them to ensure that it was the right test and actually the last question. Of course, students were already prepared with a counter-workaround: they could simply CTRL-C to DOS, navigate to the appropriate test folder, and then type in the following at the prompt:

ECHO CCCCCCCCCCCCCCCCCCCCCCCCCCCCC > answer.key

This would overwrite the particular test’s answer key, ensuring that C was, in fact, always the correct answer. Some students even patched together a batch file that overwrote all answer keys for all tests.

Shortly thereafter, River City High moved back to the paper and pencil tests.

"I have been helping a guy with a project," seebs wrote, "I wasn't originally involved, but when the three-month project was six-months late, I got called in to start on the other half. I still remember the sick feeling in the pit of my stomach when the developer told me "all fields are varchar for simplicity...'"

"There's a database of users who can log in. Now, we all know that you always store the password encrypted, right? Perfect, it's stored as MD5. Here's the three relevant fields in the database:

username VARCHAR(32),
password VARCHAR(32),
password_md5 VARCHAR(32)

"...And yes," seebs continued, "the 'password' field holds the password in plaintext."

"Amazingly, the MD5 password is even calculated using a salt key. It's the MD5 hash of salt + name + password. The salt is the name of the company the project is for. Well, no. It's a misspelling of the name, with two typos out of six letters. Now, I'd have thought this might be intentional, except that two of the states a transaction can be in are CANCELED and CANCELLED_TX.

"The whole thing is like this. Several megabytes of code.