thanks,
Mike
Well, that all depends on how you look at things.
Most UNIX systems do not have a concept of usernames or passwords; all files
and processes are `protected' with some form of a user-id number, and
possibly a permission mask.
However, just because authentication is not handled by the kernel itself,
does not mean that it isn't performed at all, or that it is extranious. All
that it means is that authentication was left up to a system-defined way.
The trapdoor that makes this work is called the 'root' user, or the
super-user. A program is run by (or as) root, that expects some kind of input
and then provides some form of (hopefully restricted!) environment that is
suitable to the device that provided that input.
An example is your /bin/login program. When it is called (via your console
monitor or telnet server, or possibly others), it expects a username and
password that /bin/login will use to verify against a password store.
On many UNIX systems, this will be a flatfile database called /etc/passwd or
/etc/shadow, however on others it will be a NIS server, an LDAP server, an
SQL database, a RADIUS server, or even an NT domain server. It doesn't really
matter, so long as /bin/login trusts this password store, and that it
'becomes' the proper user-id and starts that environment (such as a shell).
As you probably already have noticed, /bin/login is not the only program that
performs authentication. Your FTP server probably also performs
authentication.
These programs (/bin/login included) are performing most of their
authentication internally. They're actually accessing that /etc/passwd or
LDAP server themselves (okay, an overdramitization. It's probably linked with
a library that's doing the actual work). There's a real good reason why they
do this, instead of just creating one program that does authentication, and
/bin/login would just "call" that program.
If *I* (being an arbitrary user on your system) have the ability to run this
program, it becomes much easier to make brute force attacks on your password
store. This would be "bad". This is just one example. Because I can think of
one, I should plan for it, and all the other cases I cannot think of. This is
a good first step in scrutinizing security.
Of course, you could protect your authentication program so that only certain
programs are allowed to run it. An example of one of these such-programs is
commonly referred to as PAM. PAM's quite good, but it's rather complicated,
and most users do not install it correctly (including Redhat it would
seem...)
Since only certain programs should be allowed to access your password stores
(and then should be very carefully written indeed! so as to not open up any
security problems) you need to be very careful about why you need to
authenticate a user.
So the question really is, do you want to "validate a user" in the system
password store? or your own?
If you wish to validate a user in your systems' password store, you should
investigate the format of your system's password store.
/etc/passwd
/etc/shadow (found often on linux/solaris systems)
/etc/pwd.db (found often on openbsd/freebsd systems)
/etc/spwd.db (shadow for the bsd's)
/etc/pwdb/... (a directory-based password database)
the list goes on...
You might want to look at some library functions that other people have
already written. In C these are:
getpwnam() getpwuid()
getspnam() getspuid() -- found on several broken shadow password
packages.
In JAVA, I'll admit to not knowing the exact classes that mimic the C library
functions I've listed, but I assume that (like the ones for C) are up to the
implimentor of the java classes.
HOWEVER, if you are looking to develop your own password store (which, by the
vagueness of your question, could just as easily be the case; and would
probably be much safer than pretending you know the first thing about
security), you might want to look into the crypt() function (semi-standard C
library), or other cryptographically safe algorithms. MD5 is a good one that
I happen to know is provided in many java kits.
So if I didn't answer your question, please rephrase it, and answer the
following:
Are you authenticating from the systems' password store?
If so, what kind of system+configuration?
If not, what kind of password store are you attempting to
create?