[phplib] Re: Re[4]: [PHPLIB] LDAP auth & uid From: Kristian Koehntopp (kris <email protected>)
Date: 04/27/00

In netuse.lists.phplib you write:
>>> >>Do I have to assign each user a md5() userid or
>>> >>can I give it a simpler id (similar to the method used in /etc/passwd)?
>>> KK> Unique id is enough. It need not be md5.
>>> KK> User ids are not exposed to the outside and need not be unguessable.
>>> So, does this mean that the md5(uniqid($hash_secret)) - generated
>>> user_id is useless, and could be changed to simple numeric user id without any
>>> impact on security?

>R> Just guessing, but is there an issue with support for auto-increment
>R> fields on some databases that makes it reasonable to use the md5
>R> method to generate unique uid's?

>So why generate md5 uids if you have an unique auto-incremented field
>(say, uid) in your user database? Should it be more reasonable to
>store uids as simple integers?

Some time ago I have written an article for this list that
explains the difference between a Session ID as used in Session
and a User ID as used in Auth. If someone could repost that? It
will make things clearer for you.

Anyway, anything exposed to the client side must not be
predictable at all. Session ids of different sessions must not
be assigned consecutively and can therefore not be integers.

User ids as used in Auth are never exposed to the client side
and can in principle have any format, at least as long as you do
not ever use them yourself on the client side (PHPLIB doesn't).
PHPLIB traditionally uses md5 hashes here as well, for
simplicity of the table design (User relies on the fact that
uids can be used in place of sids) and to protect those of you
who chose to expose user ids to the client side.

>It's trivial aesthetics, but I guess that passing an integer
>uid to the GET query string (if needed) is more aesthetic way
>than using md5 hash crap there.

The ids visible in GET mode are not user ids, but session ids.
They must be allocated sparsely from a large id space, or a user
can trivially hijack foreign sessions by editing the GET url and
guessing ids of others sessions.

>For that purposes I
>use an alternative uid in my user table, register it as an auth[]
>element, and use it as an uid in forms and queries, but why that pain
>in the ass, if the user_id has not an impact on security, it should be
>only unique, but not unguessable?

In theory the uid is not even necessary, as the user name
already is unique. The id is just a normalization of the user
identification, which may be done differently in different
applications. To enable PHPLIB to be flexible in user
identification, it uses ids of a normalized format internally,
and you may modify the "username" part of the auth_users table
to your needs in your particular application.

For example, your application can drop the username field
completely and use given_name and family_name fields instead.
Without normalization to a user id, that change would trigger a
trail of changes throughout the whole library to accomodate the
different names and number of fields which compond the unique
user identification. Using a normalization mechanism in
Auth::auth_validatelogin(), PHPLIB confines such details to a
single function which you have to write for yourself (and the
login form in Auth::auth_loginform()) and requires no changes in
the library code to accomodate any authentication mechanism,
ever.

Kristian

---------------------------------------------------------------------
To unsubscribe, e-mail: phplib-unsubscribe <email protected>
For additional commands, e-mail: phplib-help <email protected>