June 1st, 2004, 07:20 PM
Dealing with (or implementing) insecure software in your organization...
Recently we/I've been asked to roll out a software program, which a teacher has selected and had licenses bought, that makes students practice there grammar and vocabulary. So far so good.
The problem is, this software's security is total utter crap:
Each student must register him/herself with a username and password... which are then stored in cleartext textfiles named with a sequential id (0.txt, 1.txt, 2.txt...) on a shared directory which everyone must have read... AND modify access to!
Normally, this utterly insecure design can be mitigated to some extent by setting the shared directory permissions so that new files are given CREATOR OWNER full control and other users no access so that only the user that created the userfile (X.txt) through execution of the program, can re-access and modify that file...
HOWEVER, in this case, this isn't even possible because, if you follow their design, in order to authenticate a user that logs in, the program scans the whole folder for the user files (X.txt), opens each one and compares if the username/password the user gave it matches the one in that file, if it doesn't goes on to the next (Y.txt) file and so on untiles it matches or runs out of user files in the directory! And to make things worst, if it can't open one of the files, it gives up trying to match with the others too!
So now I'm stuck with this crappy program and a list of cleartext files which store usernames and passwords as well as the user's list of accomplished activities which can be read AND modified by anyone who manages to find the hidden share. It's not that I really give a damn if this program user accounts get messed up, modified or cheated, we have severly warned the teacher and direction about this, what I really worry about is these kids (and even more the teachers who might use it) using the same username and password than their windows domain username/password (and God knows where else they use these same credentials!).
We have contacted the maker of that software (a BS home "basement" company of one) about these issues, to which there answers was: "the program is like that by design, there's nothing that can be done, you're (we) are over reacting, many schools use it and nothing's ever happend"... URGH!!!!!!!
Anyways, for now like I said, the teacher and direction have been severly warned (inluding us showing them the e-mail of the acknoledgment and lack of care from the developper) about these issues, but they still want to accept the risk and go through with using this crap.
So my question to you, fellow admins, is what more can be done? How would you deal with this situation?
PS: I won't even mention the rest of the crap about having to install this product by hand on each machine...
Credit travels up, blame travels down -- The Boss