Home page logo

basics logo Security Basics mailing list archives

Re: Epithet
From: Jimi Thompson <jimit () myrealbox com>
Date: Wed, 10 Dec 2003 23:18:10 -0600

My point with this was that instead of devoting so much energy to assigning a random user id, you should probably be spending that energy in making sure that your authentication mechanism is secure. Once the authentication mechanism is secure against brute force dictionary attacks, which very few are, you can start working on your user naming schemes.
2 cents,


Meritt James wrote:

I found out over a decade ago that it does not work, especially when the
one doing th 'crqack' doesn't know what SHOULD be.  All systems are
equally obscure to those who do not know what "should" be, which makes
renaming,... effective only a small bit against those who know enough to
know what to expect but probably not enough to be dangerous.

Jimi Thompson wrote:

While I am never in favor of giving information to the "enemy", keep in
mind that "security by obscurity" is quite useless.  You can have the
most fabulous UID system on the planet, and I can still crack it  if
the  authentication mechanism can be brute forced.

2 cents,


SMiller () unimin com wrote:


I too have been doing this for a long time.  A few years ago I would not
have hesitated to suggest that the userid match the user's name as closely
as the system would allow.  However, I see far too many applications today
that automatically cache this value, even when the user has elected not to
cache the password (a practice BTW that I believe should barred by any sane
security policy)  So I guess my best advice is to evaluate the
administrative benefits of easy user identification by that string (also
consider how easy or difficult it might be to create and maintain a
separate table that would correlate a "random" id with user identity) with
the incremental risk from id-caching applications.  In no case would I
advise use of a unique and loaded value such as employee number as a user

"Specialists without spirit, sensualists without heart, this nullity
imagines that it has attained a level of civilization never before
achieved" - J. W. von Goethe

                    Steve.Kirby () seale
                    dair.com                 To:       security-basics () securityfocus com
                    12/02/2003 12:36         Fax to:
                    AM                       Subject:  Epithet

To the list:

We are currently developing a meta-directory project. One data element that
we may now be able to re-define, is that of a User's Identification (UID).

There are many 'schools of thought' about what should, or should not make
up a UID. Do you include all or part of a person's name, do you use
initials, what about an employee number (and what if they're a contractor
without one)? The permutations are endless.

Having worked for many years in administration of systems,  I tend to think
you should be able to derive who the user is - so you can ring them....
just as you log them off!  But is it necessary to identify the user easily?
Could a seemingly nonsensical code be used to preserve anonymity? Is a
jumbled UID a better deterrent against someone trying to forge an identity
into our systems because they wouldn't know how it was made up or verified?

The questions are almost endless, but I would be very interested to hear
from others about their experiences or thoughts. No names, no packdrills,
but examples of how UIDs are made up or UIDs you've come across would be
gratefully accepted.



or should that be GX78F2792?





  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]