[LANdb] Proposed login system

To continue the discussion we started before about all this.  [  Or at
least, some of you were involved before.  We've got a lot of new
subscribers since v0.80 -- Welcome.  ]


After going through this over and over, here's what I've come up with:

1) There are only two actual MySQL users - admin, who's the same admin
we've had all along; and 'superuser' (or something), who's the user that
every other user in the database connects as.  The idea is similar to
'sudo' - people are allowed to do certain things (as deemed necessary by
user admin), and LANdb actually does the authentication.
    Con's:
        -This can be a rather stupid thing to get into, if one isn't
careful.   You're taking security into your own hands, even though it's
already done for you in the engine. :)
    Pro's:
        - This is more of a big-environment solution.  It allows us to
customize very narrowly the user list, assigning permissions at will,
without modifications to mysql's user table, which requires the grant
option, which most administrators would be stingy to give out (and
rightly so).
        - On the same tangent, it allows us to add and remove users at
will- without having to have root/GRANT privilege on the DB, or without
having to email the admin and wait for results.
        - It makes my proposed login cookie system easier to implement
(more on that later).

    Feel free to write back with any other additions to either pile...

The layout goes something like this:
Superuser's password is stored, in plain text, in a file readable by the
web server's user only (perhaps it can be configured for another user
just for landb's scripts?).  Obviously, this makes it vulnerable to
attack from any other script on the machine.  However, it should be safe
to assume that you can grep through your cgi scripts to catch things
like 'open "their password file"' -- in other words, we unfortunately
become dependent on a sane environment.  That's the downside.

The good  part (aside from making user management a breeze) about this
is that it makes the login system work nicely.

2) Quick and dirty: you login with your username and password.
LANdb::DBLogin() creates the database handle ($dbh), and a login cookie,
stores your username, cookie, and a timestamp in nis.login.  The cookie
is created with Crypt.pm: we encrypt the password, localtime, and the
process id, and concatenate the three together.  The result is approx 40
encrypted chars.  No two cookies are ever the same (theoretically
anyway, due to localtime/proc id always being different), and the whole
thing would be damn near impossible to guess, even if you had the
password (and why would you want the cookie if you had the password?).
Problem: it takes about 2.5 seconds to encrypt all that on my 233 mmx.
If this was going to be something with 100 users or something, the load
of encrypting might be too much.

This login id and the username are then passed around in hidden tags,
rather than the username and password.  Obviously, much more secure.
But is it really worth all the trouble?  *Shrug*

As I mentioned above, the sudo system comes in handy here.  Since login
id's have to be deleted from nis.login upon logout (or on a pre-defined
timeout), the user must be granted DELETE on the table, which has
obvious consequences (logging out other people).  (Is there a way of
preventing more than one row at a time from being deleted?  This could
solve the problem.)  A way around this is to grant only the superuser
(and admin) delete on nis.login.

I haven't done much coding at all with this yet, so feel free to propose
new methods and big revisions...

John




--
# John Madden  weez@avenir.dhs.org ICQ: 2EB9EA
# Sys-Admin / Webmaster, Avenir Web: http://avenir.dhs.org
# LANdb: Network Admin Database --  COMP Mailing List: Linux & Windows
# The NAN Project: Neighborhood Networks -- Tech Support Database




-------------------------------------
LANdb - Network Management through SQL
To unsubscribe, send email to landb-request@avenir.dhs.org
	and put 'unsubscribe' in the subject line
Administrative contact: weez@avenir.dhs.org
-------------------------------------