ASP/VBScript

[telophase]

Is there a simple one-way hash, salted or not, in VBScript/ASP similar to the ones in PHP to encrypt a string? Barring that, does anyone know of any decent scripts that do the same that I could steal use?

I may not even be able to do that much - this is for a survey this fall, and if I am allowed to to track the people who take it, to prevent them retaking the survey as a number did this past spring, I will need to encrypt their IDs. I may not be allowed to track them; I wasn't this spring. And in that case, we just have to deal with our data being messed up by the idiots people who overlook the "IF YOU AHVE ALREADY TAKEN THIS SURVEY, CLICK ON THIS LINK!!!" message. But I'm hoping that my encryption suggestion will be taken.

Comments

[thomasyan.livejournal.com]

How many students are we talking about?

What I did once for a course evaluation, was create a random (6-digit?) number each time the survey was taken. I asked the students to print out the page giving them their number, and I checked off their name when they handed in that sheet.

[telophase.livejournal.com]

Ideally, every student on campus, which is about 8000. :) In practice, last spring we got about 1400 responses, four of which we knew for sure were duplicates because the people complained in the comments (well, technically 7 were duplicates, because one of them announced it was the fourth time s/he'd taken it, but we had no way of knowing which of the others were bogus). And no way of knowing who took it multiple times and didn't complains.

I deleted the ones that said they were duplicated, the ones with things like "sdfsfsdfsd" in the comments, and the ones that were completely blank with no response whatsoever, but there's no telling how many went ahead and put in random ratings for the various services we were asking about, more than once.

If I can't track ID numbers, I'm thinking of a simple, plain page that says:


[small intro schpiel, as short as I can make it]

[thomasyan.livejournal.com]

I don't see how a one-way hash would help.

[telophase.livejournal.com]

Because the way PHP does it, you encrypt it one way, put that in the database. Then someone puts another number in. It hashes that, then you compare it to the one in the database. You can't pull out any identifying information because it doesn't work going the other way,[1] although each item in the database is (supposedly) unique and can be re-created from the same ID number to start with.

[1] I have no idea how or why. Math is hard! Let's go shopping! *vapid giggle*

[thomasyan.livejournal.com]

re-created from the same ID number

That's the part that worried me. It should be easy to figure out who each survey participant is: Simply get the names and IDs of all students (surely the registrar has this info), compute the hashes, and match up the hashes.

This is basically what they mean by a "dictionary attack" on UNIX passwords: If people are stupid enough to use words from the dictionary (like the Cornell CS Grad Director or Chairman, who used "tomato"), then simply hashing each word in the dictionary and comparing the hashes with people's hashed passwords (since that is how they are stored in UNIX) allows you to crack those bozos' accounts.

[telophase.livejournal.com]

Except that if you've got their ID numbers already, you don't need to do a damn thing with the library survey database - you need to start working on their usernames and passwords to get into anything else. (Usernames and ID numbers are separate here.)

I'm more concerned* with someone getting the library survey database and attempting to use it to recreate data. If they're already got the data, there's nothing they can do with the library survey - the ID numbers will not be connected to any other tables, so the only info you can possibly get would be that that student has taken the survey. Hardly on the level of being able to get into their grades or school financial accounts.

Anyway, that entire line of argument is moot, as it has been specifically cited to us as a problem with privacy and not security - we are not supposed to be collecting personal identifying data. One-way encryption would provide plenty of privacy and a bit of security.

* i.e., not much concerned at all, but enough not to have a table of unencrypted ID numbers cluttering up the place.

[thomasyan.livejournal.com]

Sorry, I wasn't clear. I didn't think security was a problem. I had privacy in mind, too (being able in principle to easily identify which student turned in a set of responses). I brought up the dictionary password attack because it works the same way.

[telophase.livejournal.com]

As I said, the only thing they could identify is that the student had, in fact, taken the survey, but none of their responses because I have no intention of hooking those tables together, if I'm allowed to do so.

It won't even compare the number the student types in with the university's database of ID numbers, because that would be way too difficult for me to set up, so if the student types in "GO FROGS", it'll accept that as their ID number (and if another student types in "GO FROGS" it'll kick 'em out, saying they've already taken it). There will be some abuse of that, but I think less than the number of problem responses right now from people who've taken the survet multiple times because they didn't see the link to skip it.

[isancho.livejournal.com]

I glanced at this briefly. It may have some useful tips.

http://www.15seconds.com/issue/000217.htm

Basically you could use MD5 SHA or SSHA for quick and easy hashing... If that link doesn't help, at least knowing the names of some hashing algorithms might help narrow down a google search?

[telophase.livejournal.com]

Thanks. I"ll take a better look a this when I'm not so exhausted that the sheer effort of staying upright tires me out.