My original question:
=
=I'd like your opinions/thoughts/comments/suggestion on the following setup:
=
=I have an new AlphaServer 1000A running DU4.0B. I am setting it up so that
=users can apply for accounts using a web form. After validating their
=information, useradd/pass/edquota records are appended to a file. (Pass
=sets the password.) The file will be run at scheduled times via cron
=(perhaps every 4 hours). Do you see any gotchas in this setup? I did
=create a rudimentary lock file on the file so that the web form and the
=cron job are not using it at the same time.
Thanks to (sorry if I missed anyone):
Matthew Calthrop
Pat Wilson
Michael Matthews
Tom Rioux
Kirk Rafferty
Sam Washburn
Costas A. Makris
Their comments [my comments in brackets]:
Matthew:
procedural comment: is it wise/advisable from a security point of view to
have user accounts automatically created without any human validation?
[we handle so many accounts that an automatic account creation process is
almost a must]
Pat:
You'll want to access-restrict the page so that bozos the world over won't
find it... I'd think you'd also want to run this from a secure server,
just on principle.
[impletmented ... soon anyway, as soon as I can get a Certificate for the
secure server]
You do encourage (or require) them to change passwords soon after, though,
yes? [Good suggestion]
Michael:
Can folks input their own account data into the cron job queue area,
bypassing the validation step? [The server writes to a file in a directory
owned by it, but not in document root. Users cannot read or write to the
file.]
Is there any bounds checking on the input? If a root cron job runs
it, can someone do some sneaky stuff (like putting |s or >s or
;commands in the input fields) to cause root to run a job?
[The CGI is written in C using lib cigc - it does this kind of checking.
The user input is just used to validate them - the input is compared to
existing files on the server. The information from the files is used to
add the account.]
Tom:
We also did this 1.5 years ago. Several additional thoughts:
1) use e-mail for all communications,
2) validate e-mail address in form before submitting the request,
3) disallow ip addresses outside of your domain,
4) we authenticate against a file of student's names and school id numbers
for currently enrolled students and a similar file for faculty and staff.
Our scripts also create a Windows NT account.
Our scripts also maintain a file of information on each student.
You may want to look at the NIS utilities located at
ftp.ce.utexas.edu:/unix/nis_utils/nis_utils.tar
Kirk: (summarized)
Unauthorized Accounts: What stops do you have in place to ensure the
janitor doesn't set him/herself up an account on your machine? It's
important to verify that the user actually has a valid need for that account.
[Not applicable in my situation - the janitor is allowed to get an acocunt
as are all employees]
Username spoofing: What stops me from requesting an account in my
coworkers name, whom I know hasn't requested one yet?
[Could be a problem, but you need to know the SS# and birthdate]
The more removed you are from the procedure for user setup (by automation),
the more checks you'll have to put in place to make sure the user a) has a
need for access, and b) is really who they say they are. Finally, it all
depends on how
paranoid you are, how large your organization is, and how important the
machine is.
[I guess that last sentence really sums it up]
Sam:
only thing i could think is maybe two users signing up simultaniously. you
might need to lock the file every time the cgi accesses it.
[implemented, but crudely (just creating a file with open/close, can anyone
give me insights on file locking?]
Costas:
I think this is a fantastic idea. Is it possible to give me a copy of your
scripts that does all these?
[I am hesitant. These scripts are still in infancy and probably need a lot
of work yet to make then secure and funtion properly 100% of the time.
Also, they are written in a manner that is specific to our implementation.]
Ellen Davis
Ellen.Davis_at_uc.edu
Received on Thu Jul 17 1997 - 23:15:33 NZST